-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Ajoute intégration Litteralis / MEL #874
Conversation
@johanricher J'ai commencé l'ADR et j'y ai mis la suite de mon analyse des données (pas terminé) : https://github.com/MTES-MCT/dialog/blob/feat/litteralis/docs/adr/010_litteralis.md |
9d61929
to
4d27174
Compare
5b1e42f
to
72a21ef
Compare
J'ai une première version fonctionnelle de l'intégration Il me reste du travail, notamment sur :
Quelques stats {
"Nombre total d'emprises dans Litteralis": 17419,
"Nombre d'emprises candidates à l'import": 1300,
"Filtre": "mesures ILIKE '%circulation interdite%' OR mesures ILIKE '%limitation de vitesse%'"
} |
72a21ef
to
d3cf137
Compare
@jjacquelinet @mmarchois Je chercher des idées sur la transformation des polygones litteralis en linéaires Litteralis fournit des polygones de ce type : En faisant une simple intersection avec les tronçons de la BD TOPO j'obtiens des linéaires "en peigne" de ce type : C'est parce qu'il y a des micro-portions des rues adjacentes qui sont incluses dans les polygones Des idées sur comment les exclure de façon "simple et robuste" ? Pour l'instant je n'ai pas trouvé. Intuitivement je voudrais comparer la longueur d'un tronçon à la "largeur locale du 'couloir' formé par le polygone" mais je n'ai pas encore trouvé comme calculer cette dernière grandeur |
52d719b
to
3d6be49
Compare
@florimondmanca première idée qui me vient : retirer les segments de longueur "trop petite" (à définir arbitrairement) lorsque l'intersection est d'ordre 3 ou plus ? Il faut parcourir l'ensemble des intersections du coup, et potentiellement créer un réseau routable (exemple : ce que fait pgrouting mais en php, pour chaque linéaire en peigne obtenu). |
Il me semble que la "largeur locale du 'couloir' formé par le polygone" est la longueur du peigne formé par exemple par la rue des Cerisiers, multipliée par 2. Cette grandeur est donc celle d'une rue perpendiculaire à la rue de la mairie, 'intersectée' avec le polygone. |
3d6be49
to
5e04c9d
Compare
Vive PostGIS... https://postgis.net/docs/ST_ApproximateMedialAxis.html Ça nécessite Edit : dommage on dirait que non
Le support Scalingo m'a confirmé que l'extension n'était pas dispo, mais se renseigne pour savoir si une solution alternative existe. |
5e04c9d
to
75a7f32
Compare
@jjacquelinet J'ai traité tes retours sur l'ADR |
@johanricher J'ai implémenté des correctifs sur les périodes / créneaux horaires Maintenant l'arrêté 24-A-0408 aura bien "du 22/09/2024 à 00h00 au 22/09/2024 à 23h59 (05h45-14h00)" dans DiaLog (auparavant "du 22/09/2024 à 04h00 au 22/09/2024 à 04h00 (06h45-15h00)" ce qui ne correspondait pas) (Je n'ai pas encore relancé l'import sur la review app donc tu ne l'y verras pas encore) |
@jjacquelinet Pour la review, si tu as besoin d'un tour d'horizon, n'hésite pas. La structure commence à être habituelle mais il y a quand même pas mal de choses... |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Je ne sais pas si ça vaut le coup de mettre des exemples d'output
en commentaires dans la fonction format
?
@florimondmanca ok, on voit ça demain après le point quotidien ? |
Procédure pour valider les données intégrées
À NOTER : des incohérences entre les noms de rue et le linéaire effectif sont prévisibles. Dans Litteralis la source de vérité est les polygones dessinés par les utilisateurs, les noms de rue proviennent d'un géocodage côté Litteralis, ce qui ne sera pas 100% fiable. |
Je relance l'intégration pour prendre en compte les dernières améliorations EDIT : c'est bon 🏁 |
Vous pouvez prendre des notes dans le pad : https://pad.incubateur.net/2IyW3VQRQxu7VC1ojcOeUg?both#MEL |
Résumé des problèmes sur 4 arrêtés analysés : 24-A-0327 :
24-A-0075 :
2024-085
|
Remarques à l'usage
|
Scalingo m'a informé ce matin qu'ils avaient mis le ticket en développement, sans me donner d'idée de date de dispo. Apparemment ça serait "simple" car c'est "juste une bibliothèque", en tout cas comparé à PgRouting : "J'ai trouvé plus d'éléments par rapport PgRouting : Il s'agit d'une extension complète (contrairement à postgis_sfcgalqui n'est qu'une bibliothèque). Cela nécessite donc plus de travail de notre côté pour l'ajouter et surtout la maintenir à jour." |
Merci @jjacquelinet Je vais merger, pour info tant que l'on n'éxécute pas l'intégration en pointant sur la prod, les données ne seront pas en prod (je dis ça pour l'amélioration des localisations, on peut attendre Scalingo avant de le faire). Je vais plancher sur l'exécution auto par GitHub Actions. |
Description
Cette PR ajoute une intégration avec l'API de l'outil Litteralis de Sogelink, le premier cas d'usage étant la MEL (Métropole Européenne de Lille)
L'architecture du code commence à être classique : l'intégration est découpée en 3 gros morceaux
Extractor
: requêtes à l'APITransformer
: conversion des données Litteralis en arrêtés DiaLogExecutor
: une classe qui coordonne le toutJ'ai ajouté une partie
Reporter
qui s'occupe de collecter les infos utiles pour la génération d'un rapport d'erreur (RETEX eudonet : #877 etc)TODO
// TODO
restantsLitteralisClient
TODO améliorations rapport
Améliorations à suivre
postgis_sfcgal
sera dispo sur Scalingo