Ajoute intégration Litteralis / MEL

[florimondmanca]

• Résout en partie Intégrer les données de la métropole européenne de Lille (MEL) #658
• Nécessite Retire contrainte de longueur sur RawGeoJSON.label #919

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

1. Extractor : requêtes à l'API
2. Transformer : conversion des données Litteralis en arrêtés DiaLog
3. Executor : une classe qui coordonne le tout

J'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

• Mettre à jour l'ADR https://github.com/MTES-MCT/dialog/blob/feat/litteralis/docs/adr/010_litteralis.md
• Traiter les // TODO restants
• Ajouter une doc d'utilisation
• Dates : ne requêter que les arrêtés dont la date de fin est dans le futur, supprimer ceux-ci lors de l'exécution pour récupérer les mises à jour (mais garder ceux qui sont devenus passés)
• Extraire un LitteralisClient
• Une commande pour récupérer les emprises d'un arrêté par identifiant ?

TODO améliorations rapport

• Nombre d'emprises effectivement importées
• Nombre d'arrêtés concernés (pas seulement le nb d'emprises), par ex : "1292 emprises (dans 140 arrêtés)"
• ShortURL de l'arrêté papier dans la description de l'arrêté DiaLog
• ShortURL de l'arrêté papier à côté du N°
• Sujets de créneaux horaires Ajoute intégration Litteralis / MEL #874 (comment)
  • Fuseau horaire des timeslots
  • Traiter le cas des dates de début/fin identiques à la même heure : interpréter comme "ce jour là de 00h00 à 23h59" ?

Améliorations à suivre

• Automatiser l'exécution sur GitHub Actions
• Traitement des géométries quand postgis_sfcgal sera dispo sur Scalingo

[florimondmanca]

@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

[florimondmanca]

J'ai une première version fonctionnelle de l'intégration

Il me reste du travail, notamment sur :

• Traitement des géométries (ce sont des polygônes qui "couvrent" la rue, il faut les transformer en linéaire en prenant l'intersection avec nos tronçons de route)
• Traitement des "jours et horaires"

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%'"
}

[florimondmanca]

@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

[jjacquelinet]

@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).

[jjacquelinet]

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

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.

[florimondmanca]

Vive PostGIS... https://postgis.net/docs/ST_ApproximateMedialAxis.html

Voir https://gis.stackexchange.com/questions/375297/postgis-functions-for-generating-centerline-from-polygon

Ça nécessite create extension postgis_sfcgal, à voir si le Postgis de Scalingo est compilé avec cette extension

Edit : dommage on dirait que non

dialog_bdto_7774=> create extension postgis_sfcgal;
ERROR:  could not open extension control file "/usr/share/postgresql/14/extension/postgis_sfcgal.control": No such file or directory

Le support Scalingo m'a confirmé que l'extension n'était pas dispo, mais se renseigne pour savoir si une solution alternative existe.

[florimondmanca]

La fonction ST_ApproximateMedialAxis() donne des résultats plutôt satisfaisants en plus

Scalingo m'annonce qu'avec les congés d'été, ils ne pourront pas implémenter postgis_sfcgal "avant plusieurs semaines".

[florimondmanca]

@jjacquelinet J'ai traité tes retours sur l'ADR

[florimondmanca]

@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)

[florimondmanca]

@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...

[jjacquelinet]

Je ne sais pas si ça vaut le coup de mettre des exemples d'output en commentaires dans la fonction format ?

[jjacquelinet]

@florimondmanca ok, on voit ça demain après le point quotidien ?

[florimondmanca]

Procédure pour valider les données intégrées

1. Se connecter à https://dialog-staging-pr874.osc-fr1.scalingo.io
2. Prendre quelques arrêtés au hasard
3. Ouvrir l'arrêté papier dans Sogelink
4. Comparer l'arrêté papier avec ce qui s'affiche dans l'interface DiaLog
5. Pour la géométrie : comparer les rues indiquées dans DiaLog et le linéaire qui peut être vu dans la carte, ou dans le DATEX https://dialog-staging-pr874.osc-fr1.scalingo.io/api/regulations.xml (Ctrl+F l'identifiant de l'arrêté)
6. Signaler toute incohérence / erreur

À 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.

[florimondmanca]

Je relance l'intégration pour prendre en compte les dernières améliorations

EDIT : c'est bon 🏁

[florimondmanca]

Vous pouvez prendre des notes dans le pad : https://pad.incubateur.net/2IyW3VQRQxu7VC1ojcOeUg?both#MEL

[florimondmanca]

Résumé des problèmes sur 4 arrêtés analysés :

24-A-0327 :

• Date de début erronée : 24/06/2024, aurait dû être 17/06/2024 (seule date qui figure sur cet arrêté permanent, c'est la date de publication)
  • TL;DR de ce qui suit : en fait il n'y a probablement pas de pb / on ne peut pas faire mieux
  • Après vérification, dans les données GeoJSON :
    • "arretedebut" => "2024-06-24T02:00:00Z"
    • "datecreation" => "2024-06-17T11:18:06.763Z"
  • Soit on considère que arretedebut est faux (pb de données sources)
  • Soit pour les arrêtés permanents il faut en fait traiter datecreation...
    • Dans le 24-A-0123, tout est au 11 mars 2024 (mais l'arrêté papier ne mentionne pas cette date : publié le 12/03 et signé le 08/03...)
    • Dans le 24-A-0091 on a le même pb. Signé le 29/02, publié le 01/03, arretedebut = 26/02, datecreation = 01/03...
    • Dans le 22-A-0304, pb aussi : Signé le 31/08, pas de date de publication, arretedebut = 15/09, datecreation = 05/09... Quelle date choisir ?
  • Soit il n'y a pas de problème car arretedebut représente bien l'entrée en vigueur de la réglementation... La doc Sogelink ne précise rien d'autre que "arretedebut : Date de début de l'arrêté". Par contre datecreation n'est pas une bonne idée : "datecreation : Date de création de l'acte dans le flux. Cette date pourra être utilisée pour réaliser une synchronisation du flux par batch par exemple." => Pas d'alternative à arretedebut

24-A-0075 :

• Les polygones sources sont décalés par rapport au linéaire BDTOPO donc on a une géométrie "hachée"

2024-085

• Les polygones sources sont faux, ils couvrent le tronçon concerné mais aussi tout le reste de la rue Victor Hugo et de la Rue Curie. On dirait des polygones automatiques...

[florimondmanca]

Remarques à l'usage

• Les filtres de recherche Améliorer les filtres de la vue liste #902 seraient quand même bien pratiques... Pour trouver un arrêté par identifiant, et voir au moins les arrêtés temporaires / permanents (on a perdu cette possibilité depuis Simplification de l'affichage des arrếtés #916)
• Un simple widget de recherche d'adresse sur la carto serait très pratique, j'ai dû aller chercher les rues sur OpenStreetMap. Correspond à Rechercher un lieu sur la carte #882 mais j'imagine le widget intégré à la carte et pas en dehors (on dirait qu'alors il servirait à filtrer des restrictions, là on veut juste centrer la carte sur un endroit)
  • => Rechercher un lieu sur la carte #882 (comment)
• Pour les localisations de type "données brutes geojson" la colonne "Localisations" de la liste est vide donc on a juste l'identifiant qui n'est pas très parlant. On pourrait afficher le label sous une forme tronquée

[florimondmanca]

@johanricher

On est toujours en attente d'une réponse du support de Scalingo pour l'activation de cette extention chez eux. @florimondmanca Peut-être les relancer ?

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."

[florimondmanca]

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.