search

MTES-MCT / dialog

Intégration de la réglementation de circulation dans les solutions numériques
https://dialog.beta.gouv.fr
GNU Affero General Public License v3.0
9 stars 1 forks source link

Intégrer les données Eudonet (Ville de Paris) dans DiaLog #343

Closed florimondmanca closed 10 months ago

florimondmanca commented 1 year ago

Contexte

La Ville de Paris produit ses arrêtés avec un outil interne appelé Eudonet, qui s'apparente à un CMS.

On considère ici que "données Eudonet" = arrêtés de la Ville de Paris disposant de restrictions de circulation.

Critères d'acceptation

Sur la base de l'exploration (voir ci-dessous) on se donne comme objectif d'intégrer une partie significative des données Eudonet dans DiaLog, c'est à dire :

Exploration

Pad dédié à l'exploration :

Implémentation

florimondmanca commented 1 year ago

Avec #348 on peut importer une petite partie des arrêtés temporaires et leurs localisations / mesures

Exemple : 6 arrêtés complets importés sur 50 arrêtés temporaires en vigueur requêtés

Pourquoi une petite partie seulement ?

Prochaine étape : regarder la BD TOPO

Peuton l'utiliser pour obtenir des coordonnées GPS d'endroits identifiés par des labels humains ? Ou d'endroits où les numéros de rue n'ont pas de sens ?

Faudra-t-il alors étendre notre modélisation des localisations ? Ou demander à la Ville de Paris de faire des modifs dans Eudonet ?

johanricher commented 1 year ago

Une synchro pour faire le point sur cette exploration pourrait être utile. Quelques réflexions et questionnements à la lecture des notes :

Beaucoup d'arrêtés n'ont pas de mesure du type que l'on supporte (ex : stationnement interdit)

A mon sens on pourrait restreindre les données qu'on intègre dans DiaLog au seul périmètre du produit actuel, c'est à dire arrêtés de circulation. Autrement dit les stationnements peuvent pour l'instant être considérés comme "nice to have".

Beaucoup de localisations sont formulées en termes "humains", pas directement exploitables par DiaLog à l'heure actuelle

Sait-on si ces localisations uniquement lisibles par un humain font l'objet d'un géocodage par ailleurs ? pour les rendre exploitables pour les besoins internes de la ville de Paris comme les afficher sur une carte, dans l'application Eudonet par exemple.

Quoi qu'il en soit, un géocodage pourrait être réalisé par DiaLog lors de l'intégration, mais il y a un risque qu'il puisse être incomplet voire imprécis.

Aucun géocodeur n'acceptera par exemple "section du Boulevard périphérique" mais il est de toute façon impossible de savoir à quelle localisation ça correspond et donc je ne comprends pas comment un tel arrêté pourrait être publié. Peut-on avoir des références d'arrêtés pour voir le contexte ?

endroits identifiés par des labels humains endroits où les numéros de rue n'ont pas de sens

C'est à dire ? Exemples ?

Prochaine étape : regarder la BD TOPO

Je ne saisis pas sur quel point le lien entre la BD TOPO et Eudonet se fait pour cette exploration.

Faudra-t-il alors étendre notre modélisation des localisations ? Ou demander à la Ville de Paris de faire des modifs dans Eudonet ?

Je ne saisis pas le sens de ces questions dans le contexte de l'exploration.

florimondmanca commented 1 year ago

@johanricher Je réponds à certains points, pour les autres il faudrait que je me replonge dans le sujet.

johanricher a écrit : Sait-on si ces localisations uniquement lisibles par un humain font l'objet d'un géocodage par ailleurs ? pour les rendre exploitables pour les besoins internes de la ville de Paris comme les afficher sur une carte, dans l'application Eudonet par exemple.

Si je me souviens bien, Eudonet n'a pas d'application cartographique et ne stocke pas de coordonnées

Dans le CR de la réunion du 16 mai 2023, on avait noté :

Pas de notion cartographique, c’est que du textuel

C'est d'ailleurs à mon sens une difficulté d'intégration majeure.

johanricher a écrit : Peut-on avoir des références d'arrêtés pour voir le contexte ?

Dans ce même CR on avait noté que

=> La Ville envoie un exemple de l’export Word

Je l'ai retrouvé dans mes mails, je l'ai mis sur le kdrive partagé : https://kdrive.infomaniak.com/app/office/184671/26604

johanricher a écrit : Je ne saisis pas sur quel point le lien entre la BD TOPO et Eudonet se fait pour cette exploration.

Je me demandais comment géolocaliser les localisations par leurs libellés en morceaux.

On ne connaît pas beaucoup mieux la BDTOPO qu'à l'époque. Mais j'imagine que l'idée floue était de "chercher" dans la BDTOPO en utilisant ces libellés "au cas par cas".

Evidemment c'est d'une part très vague et d'autre part prête le flanc à un connecteur d'une complexité potentiellement considérable.

johanricher a écrit : Je ne saisis pas le sens de ces questions dans le contexte de l'exploration.

Je pense que je voulais dire que puisqu'on était à l'époque (encore maintenant) limité à une rue avec éventuellement des N°, s'il y a des arrêtés dont la ou les localisations ne sont pas définies en ces termes, on devra faire évoluer le modèle de données de DiaLog.

Ce qui sera déjà nécessaire pour permettre de renseigner des localisations par intersections par exemple, je pense ?

johanricher commented 1 year ago

s'il y a des arrêtés dont la ou les localisations ne sont pas définies [par des adresses (au sens de la BAN)], on devra faire évoluer le modèle de données de DiaLog. Ce qui sera déjà nécessaire pour permettre de renseigner des localisations par intersections par exemple, je pense ?

Comme discuté sur #419, la gestion des intersections dans DiaLog nécessite qu'on utilise autre chose que l'API Adresse et la BAN seule, et donc des données supplémentaires (sans doute OSM et/ou BD TOPO) avec un système de géocodage qui reste non défini à ce stade.

Je ne sais pas si c'est ce point là qui nécessite une évolution du modèle de données. Si dans DiaLog les intersections sont des coordonnées (points) comme les autres, qu'est-ce qui nous empêche de les modéliser avec from_point: geometry et to_point: geometry ?

En revanche la note dans le ticket concernant sur le status d'un RegulationOrderRecord semble indiquer qu'on ne le modélise pas de la bonne façon, mais c'est un point qui n'a rien à voir avec les localisations. :)

Pour revenir à l'intégration des données Eudonet : elle dépend donc, ton commentaire le confirme, de la capacité de Dialog à géocoder des intersections.

Mais pas que, quand je vois l'exemple d'arrêté que tu partages :

Avenue de Saint-Mandé, 12ème arrondissement, au droit du N°22, au droit des n° 22-24 7 Avenue des Terroirs de France, 12ème arrondissement, au droit du N°10, 33

Aucun géocodeur ne serait capable de traiter de telles localisations. Un humain comme moi ne les comprend même pas.

Faisons donc attention à ne pas considérer que l'implémentation de ce ticket, si on décide de la lancer, ne dépend que de #419. Je me demande à quoi ressemblerait le résultat, les "won't do" et critères d'acceptation sont encore un peu flous.

florimondmanca commented 1 year ago

Je ne sais pas si c'est ce point là qui nécessite une évolution du modèle de données. Si dans DiaLog les intersections sont des coordonnées (points) comme les autres, qu'est-ce qui nous empêche de les modéliser avec from_point: geometry et to_point: geometry ?

Si l'on stocke ces données brutes pour l'export DATEX sans jamais vouloir les afficher, oui, ça suffira, on pourra réutiliser from_point et to_point.

Le jour où on ajoutera le support des intersections à l'UI, il faudra autre chose par contre, afin de distinguer si from/to_point fait référence à une maison ou à une intersection (l'UI ne sera pas la même et on voudra probablement stocker la rue intersectante correspondante). Mais ça concernerait #419 et pas ce ticket Eudonet stricto sensu.

johanricher commented 1 year ago

Oui le sujet de l'UI / UX serait à revoir une fois qu'on sera plus avancés dans le rapprochement des données existantes comme Eudonet avec Datex.

A ce sujet, je me demande par exemple si laisser l'utilisateur placer les localisations exactes de départ et d'arrivée directement sur une carte, avec un champ de recherche qui ne sert pas à les définir strictement mais qui sert en fait à aider l'utilisateur à dans un premier temps s'en rapprocher approximativement (en saisissant adresse, nom de voie, POI, intersection...) ne serait pas plus pratique.

johanricher commented 1 year ago

Des nouveaux résultats obtenus sur le PoC Eudonet (#450) ont été présentés par @florimondmanca pendant la réunion du 24/08 :

Il s'agit d'un échantillon réduit (base recettes Eudonet) mais les résultats sont prometteurs, on décide donc de les cranter en appliquant cette même méthode à la base de prod Eudonet, afin d'intégrer pour la première fois par ce moyen des restrictions de circulations (arrêtés) de la Ville de Paris dans les données Datex 2 publiées par DiaLog.

J'ai mis à jour ce ticket pour refléter les conditions pour cette première implémentation (critères d'acceptations). Les premières tâches, à détailler, consisteraient à :

Sur la base de cette première implé (donc une fois ce ticket fermé) on devrait ensuite :

Le déploiement du "connecteur" Eudonet pour automatiser tout ce processus pourrait aussi être décidé ensuite. Cependant, les explorations sur le géocodage et les données utilisées (BD TOPO, OSM...), pour appliquer une méthode similaire dans des contextes différents (données provenant d'autres agglomérations, réseau routier national, #456...) ne semblent pas encore assez mûres à ce stade.

florimondmanca commented 1 year ago 
Obtenir l’accès à la base de prod d’Eudonet
Traiter les données Eudonet
    Géooder les localisations (intersections comprises)
    Convertir au format Datex II
Intégrer les données dans DiaLog
    Base de données
    UI (lecture seule)
    API

Remarque, techniquement l'ordre serait plutôt :

En effet la conversion DATEX II est dans le sens BDD DiaLog -> DATEX II, on n'a rien dans le sens DATEX II -> BDD DiaLog.

florimondmanca commented 1 year ago

l'intégration des données Eudonet dans DiaLog devrait pouvoir être réalisé en local

La subtilité c'est que la base de données de prod (dialog.beta.gouv.fr), elle, n'est pas locale.

Il faudrait donc lancer cette intégration en étant connecté depuis le poste local à la base de prod. Ça se fait en modifiant temporairement DATABASE_URL dans le fichier .env.

Je précise que l'accès à la prod depuis un poste local n'est pas très "best practice", et qu'il faudra dans l'idéal ajouter les données à staging avant de le faire en prod...

johanricher commented 1 year ago

Quelle est la raison de la mise en pause ?

florimondmanca commented 1 year ago

La PR qui implémente le système d'import déclenché manuellement avec un Addok local a été mergée #452

Il n'y a pas de dev actif car on attend la réunion de point d'étape avec l'équipe Eudonet Paris (lundi prochain)

Je te laisse déplacer dans une autre colonne si besoin

johanricher commented 1 year ago

La réunion est une condition sine qua non pour avoir accès aux données Eudonet ?

florimondmanca commented 1 year ago

@johanricher La proposition qui a été acceptée par l'équipe Eudonet Paris était de faire le point et de clarifier la démarche et l'approche proposée pour l'ingestion des données de prod, oui. Ceci après qu'on nous a demandé "Pourquoi avez-vous besoin de l'API en production ?".

Je te TR le fil de mails au cas où tu n'étais pas encore sur la mailing list DiaLog

florimondmanca commented 1 year ago

Conclusion de la réunion de ce jour

Prochaines étapes

johanricher commented 1 year ago

Pour fermer ce ticket :

@MathieuFV Est-ce que tu peux passer en revue les critères d'acceptation et vérifier qu'ils sont remplis ? (je ne peux pas voir les arrêtés dans l'UI)

@florimondmanca Est-ce que tu as la possibilité de sortir une liste des éléments dans les données Eudonet, parmi ceux qui ont vocation à être intégrés dans DiaLog, ceux qui n'ont pas pu l'être à ce stade ? La liste serait par exemple qualifiée, par arrêté ou restriction, en fonction des problèmes rencontrés et à résoudre, et avec une notion de volumétrie. Cela permettra de détailler et prioriser les tickets pour poursuivre l'intégration, à la suite de :

Par ailleurs il me semble que le géocodage que nous arrivons à faire sur les points d'adresses présents dans les données Eudonet devrait être supprimé car les coordonnées géographiques correspondant à ces points sont déjà présentes dans les données Eudonet et il serait donc préférable de les utiliser à la place de notre géocodage. Tu confirmes ?

johanricher commented 1 year ago

Les numéros des arrêtés ne sont pas présents dans l'export Datex II, est-ce que c'est le comportement attendu ? Par exemple 2023T17750 dont le "regulationId" est "018b6c90-3c83-7e1c-aab3-3e43bfca2d49". (Par ailleurs, question subsidiaire sans lien avec Eudonet : l'URL de l'arrêté contient un identifiant très proche "018b6c90-3c83-7e1c-aab3-3e43bffe4d3a" de celui du regulationId correspondant, est-ce volontaire ?)

florimondmanca commented 1 year ago

les coordonnées géographiques correspondant à ces points sont déjà présentes dans les données Eudonet et il serait donc préférable de les utiliser à la place de notre géocodage. Tu confirmes ?

Oui il faudrait utiliser la donnée géographique d'Eudonet mais on ne la traite pas pour l'instant. On avait dit qu'on utilisait notre géocodage en attendant que leur donnée géographique soit dispo, ce qui est maintenant le cas. Mais ce n'est pas trivial car ils ne recopient pas les coordonnées dans la fiche Localisation, il faut faire le lien avec les fiches Adresse et Voie. Je pense que ça devrait être tracké dans un nouveau ticket.

Est-ce que tu as la possibilité de sortir une liste des éléments dans les données Eudonet, parmi celles qui ont vocation à être intégrées dans DiaLog, celles qui n'ont pas pu l'être à ce stade

Ok je me note ça dans ma todo.

(Par ailleurs, question subsidiaire sans lien avec Eudonet : l'URL de l'arrêté contient un identifiant très proche "018b6c90-3c83-7e1c-aab3-3e43bffe4d3a" de celui du regulationId correspondant, est-ce volontaire ?)

Oui c'est attendu bien que c'est une "technicalité" : l'URL de l'arrêté contient l'ID du regulationOrderRecord ("fiche arrêté"), tandis que le regulationId est l'ID du regulationOrder ("l'arrêté lui-même"). A priori rien n'empêcherait d'utiliser l'ID du regulationOrder dans l'URL...

florimondmanca commented 11 months ago

@johanricher Concernant les données qui ont vocation à être intégrées dans DiaLog mais ne le sont pas encore

Rappel des données intégrées

Données potentiellement intégrables

Arrêtés permanents

Il y 4317 arrêtés qui n'ont pas de date de fin

Le volume intégrable est moindre car tous ces arrêtés n'auront pas par exemple de mesures d'interdiction de circulation

À comparer avec 26 770 arrêtés qui ont une date de fin. La plupart du temps elle est dans le passé (arrêté temporaire passé). Par exemple seuls 370 arrêtés ont une date de fin après le 01/11/2023.

Localisation pas encore extraite

Pour l'une des raisons suivantes

Pas de début ou de fin

16 000 localisations de type "Une sections" sont dans ce cas (sur 187 000 localisations au total)

Dans beaucoup de ces cas, la voie de début et/ou de fin est indiquée dans un autre champ

Exemple : localisation 05/05/2023 (Rue du Chevaleret, Paris 13e) : le début et la fin sont indiqués ailleurs

Ou encore la localisation 03/03/2023 (Route de la Ferme, Paris 12e) : le début est indiqué ailleurs

On voit que dans ces 2 cas le nom de la voie ne peut pas être extrait directement, il faut retirer "le" / "la" (2e cas) voire retirer d'autres infos non-pertinentes (1er cas)

Des localisations d'autres types peuvent être concernés, par exemple "Une zone". Par exemple la localisation 03/06/2020 (Rue Charles Leroy, Paris 13e) dont la voie de début et de fin sont aussi indiqués en "complément de localisation".

Cela vaut-il le coup de faire un effort de parsing sur ces cas ? Peut-être.

"Porte sur" autre

Actuellement on traite "La totalité de la voie", "Une section", "Une zone", "Un axe"

Autres possibilités :

=> Aucun autre type n'aurait a priori vocation à être intégré

Autres mesures

La moitié des mesures (28 000) est "Interdiction de stationnement"

Un petit quart (11 460) est "Circulation interdite" (ce qu'on traite actuellement et exclusivement)

Le reste des mesures est en petite quantité

Screenshot from 2023-11-27 17-02-26

(Graphique obtenu en cliquant sur "Statistiques" dans le bouton Filtre de la colonne "Nom de la mesure" de la fiche "Mesures")

Parmi ce qu'on envisage ou pourrait envisager pour DiaLog, il y a :

johanricher commented 11 months ago

@florimondmanca Merci pour ce rapport détaillé. Tentons d'en extraire des choses qui peuvent être rattachées aux différents problèmes de géocodage qu'on veut traiter dans le chantier actuel (géocodage des voies entières, des sections de voies, des intersections...) voire d'identifier et de spécifier des nouveaux problèmes (tickets).

De ce que je comprends, en dehors des très nombreuses localisations qui concernent des restrictions de stationnements, il y a quand même beaucoup de localisations qui pourraient être traitées par différentes formes de géocodages. Donc une marge de progression intéressante qui nous permettra d'intégrer bien plus d'arrêtés de la ville de Paris. :+1:

"Pas de début ou de fin"

Est-ce que selon toi ce problème (trouver la localisation de "rue du chevaleret depuis la rue du loiret") correspond en fait à celui des intersections #419 ?

Le calcul d'une intersection (donc d'un point) pour définir le début d'une localisation, nous ramène lui-même au problème des sections de voie (mais avec une intersection comme début plutôt qu'un numéro).

Est-ce que j'oublie selon toi des cas à gérer en termes de géocodage ?

MathieuFV commented 11 months ago

Une observation, la ville de Paris dispose d'un fichier de ses emplacements de stationnement (ici). Sans que je sache s'il existe un lien possible entre ce fichier et les arrêtés que l'on a dans Eudonet, on aura tôt ou tard des sollicitations pour créer ce genre de lien, par exemple : Cette place de stationnement est dédiée à la livraison, mesure 20m de long sur 1.8 de large et n'est utilisable que du lundi au vendredi entre 06h et 08h.

Ce sera intéressant d'avoir cela en tête quand on s'attaquera (dans un avenir plus ou moins lointain) à l'intégration des règlementations de stationnement.

florimondmanca commented 11 months ago

Est-ce que selon toi ce problème (trouver la localisation de "rue du chevaleret depuis la rue du loiret") correspond en fait à celui des intersections https://github.com/MTES-MCT/dialog/issues/419 ?

Non ce problème est plutôt un problème de "propreté" des données côté Eudonet Paris

Par exemple on pourrait traiter :

Complément de localisation fin : "la rue Regnault.Cette disposition est applicable le samedi 25 juin 2022, de 06h00 à 21H00."

Mais il faudrait aller chercher dans le champ "Complément de localisation fin" plutôt que "Libellé voie fin", et extraire "Rue Regnault" à partir de la rue Regnault. Cette [...] (= faire du "parsing")

Si on fait ça ou quand la donnée est dans le champ qu'on traite actuellement ("Libellé de voie début" ou "Libellé de voie fin") alors on retombe dans un cas qu'on peut traiter avec notre Addok local

Par contre on peut interroger ce que devient cet Addok local au vu de ce qu'on apprend sur la BD TOPO. Veut-on traiter les intersections avec la BD TOPO, et si oui comment ? Ça c'est une question ouverte, en effet.