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

[Eudonet] Dates et horaires des mesures pas intégrées #812

Open florimondmanca opened 6 months ago

florimondmanca commented 6 months ago

Comportement attendu

Lorsque des dates et/ou horaires sont présents dans les données d'une mesure sur Eudonet Paris, ils sont reflétés dans les données DiaLog

Comportement réel

Les dates et les horaires souvent présents dans le champ libre "Alinéa" ne sont pas intégrés

Les mesures ont toutes comme dates les dates de début et de fin de l'arrêté, qui sont donc souvent trop larges

Les seuls cas traités correctement sont les arrêtés mono-mesure sans horaires, où dates de l'arrêté = dates de la mesure

Pour reproduire

Traces et captures d'écran

Exemple de contenu du champ Alinéa : mesure 02/06/2023 de l'arrêté 2023T17333

Screenshot 2024-06-05 at 10-21-10 Eudonet XRM - GACS TEST

Contexte supplémentaire

Pistes de résolution

En attendant

On peut uniquement intégrer les arrêtés mono-mesure avec un Alinéa vide pour l'instant (ou ne contenant ni dates ni heures ni le mot "nuit").

Dans ce cas les dates de la mesure seront celles de l'arrêté, donc elles seront correctes.

On aura par contre probablement très peu d'arrêtés dans ce cas, mais ça sera déjà mieux que rien (actuellement on a tout retiré de Waze).

Intégration des dates et horaires

Les données de dates et mesures dans Eudonet sont dans un champ libre "Alinéa" (à vérifier si c'est vraiment systématique, en tout cas il n'y a aucun champ temporel structuré dans la table Mesure d'Eudonet)

Actuellement on a très peu de couverture des mesures (disons max 10-20% : seulement les arrêtés mono-mesure sans horaires)

Peut-on atteindre de 50% à 80% en ayant recours à un parsing automatique ?

Soit un parsing statistique / "machine learning", avec du NER pour identifier des entités "plage de date (début/fin)" et "plage horaire (début/fin)" ?

Soit un parsing "rule-based", qui peut peut-être fonctionner car les heures et dates ont un format standard ? Et utiliser la position des matchs dans le texte pour déterminer quelle date/heure et celle de début/fin.

spaCy est une librarie de NLP (natural language processing) en Python qui supporte à la fois le rule based matching et du NER

spaCy décrit les critères de choix rule-based / NER comme ça

Training a model is useful if you have some examples and you want your system to be able to generalize based on those examples. It works especially well if there are clues in the local context. For instance, if you’re trying to detect person or company names, your application may benefit from a statistical named entity recognition model. Rule-based systems are a good choice if there’s a more or less finite number of examples that you want to find in the data, or if there’s a very clear, structured pattern you can express with token rules or regular expressions. For instance, country names, IP addresses or URLs are things you might be able to handle well with a purely rule-based approach.

Ce serait mieux de pouvoir se passer de Python mais spaCy est très puissant donc ça peut aussi nous faire gagner du temps par rapport à une solution rule-based implémentée en PHP

mmarchois commented 6 months ago

Je me demande quelle stratégie adopter pour parser des champs libre. Ce sera structuré en fonction du bon vouloir du contributeur ... :exploding_head:

florimondmanca commented 6 months ago

Je pense que si c'était pas des dates ce serait très difficile à surmonter mais là y'a peut-êter un créneau, j'ai mis quelques idées dans le ticket

florimondmanca commented 6 months ago

Exemples

Résumé, proposition

Après analyse, les cas qui semblent "sûrs" sont:

(1) Dates sont à détecter en utilisant les formats suivants :

Pour les heures :

(2) On peut détecter une ambiguité en comparant le nombre de dates détectées avec le nombre d'occurrences d'un nombre entre 1 et 31 (jour) ou d'un nombre entre 2024 et disons 2030 (année)

Si on ne détecte pas de dates mais que ce type de tokens est présent, gros risque de mal-interprétation => ne pas intégrer la mesure

Si on détecte des dates et qu'en dehors des portions correspondantes il n'y a plus d'occurrence de jour, mois ou année, alors le risque de mal-interprétation est faible et on peut décider d'intégrer la mesure

Outils techniques

Regular expressions, principalement...

https://stackoverflow.com/a/24288407

Exemple 1

Arrêté 2023T17333, mesure 02/06/2023

Dates de l'arrêté : 19/07/2023, 02/10/2023

Cette disposition est applicable de 00h00 à 05h00 les nuits suivantes sauf pour la desserte locale :
- du 31 juillet 2023 au 01 août 2023 ;
- du 01 août 2023 au 02 août 2023 ;
et
- du 09 août 2023 au 10 août 2023 ;
- du 10 août 2023 au 11 août 2023.

Résultat attendu (idéal ; le regroupement des jours consécutifs n'est pas nécessaire) :

Exemple 2

Arrêté 2023T18032, mesure 03/07/2023

Dates de l'arrêté : du 04/09/2023 au 15/12/2023

Cette disposition est applicable de 08h00 à 17h00 du 04 septembre 2023 au 06 octobre 2023.

Résultat attendu:

Exemple 3

Arrêté 2023T10550, mesure 30/01/2023

Dates de l'arrêté : 09/02/2023 - 30/04/2024

Cette mesure s'applique les 9; 19 ; 20 ; 23 et 24 février 2023, et une journée de réserve le 26 février 2023.

Cas complexe, seuls les 24/02 et 26/02 sont épelés en entier, le 26 est ambigu ("journée de réserve").

Comment détecter la présence de dates autres que les dates épelées en entier (les 9, 19, 20 et 23 février) ? Présence de nombres entre 1 et 31 dans le texte ?

Résultat théoriquement attendu :

Exemple 4

Arrêté 2022T110159, mesure 20/12/2022 (3 mesures en tout)

Dates de l'arrêté : 09/01/2023 - 30/08/2024

NB : le "2022" dans l'identifiant arrêté et l'identifiant mesure ne reflètent pas le véritable contenu, qui est bien en janvier 2023

DATES P MESURE CIRCUL 16 AU 20 JANVIER 2023

Une déviation est instaurée :

- rue Fessart, 19ème arrondissement.
- rue Clavel,
- rue de Belleville
- avenue Simon Bolivar

Autre cas de format résumé "du JOUR au JOUR MOIS ANNEE" (au lieu de "du JOUR MOIS ANNEE au JOUR MOIS ANNNEE" : ici le MOIS et l'ANNEE sont partagés)

Résultat attendu

Exemple 5

Arrêté 2022T19745, mesure 02/12/2022

Dates de l'arrêté : 22/12/2022 - 23/12/2022

Les dispositions de l'arrêté n°89-10393 susvisé sont suspendues pendant la durée des travaux en ce qui concerne la portion de voie mentionnée au présent article.

Résultat attendu : utiliser les dates de l'arrêté

Exemple 6

Arrêté 2021T0488, mesure 01/02/2021

Dates de l'arrêté : 15/02/2021 - 17/02/2021

Une déviation de la ligne du Bus 88, passant par la rue Cauchy, est instaurée via la rue de la Convention, rue de Lourmel, avenue Félix Faure, jusqu'à la place Balard.

Résultat attendu : utiliser les dates de l'arrêté

Exemple 7

Arrêté 2022T19745, mesure 02/12/2022

Dates de l'arrêté : 22/12/2022 - 23/12/2022

Les dispositions de l'arrêté n°89-10393 susvisé sont suspendues pendant la durée des travaux en ce qui concerne la portion de voie mentionnée au présent article.

Résultat attendu : situation ambigue, warning : on laisse passer mais mieux vaut valider a posteriori

florimondmanca commented 6 months ago

@johanricher Que penses tu de modifier l'intégration Eudonet pour n'intégrer que les mesures sans "Alinéa" (champ vide), donc où on a de très bonnes raisons de penser que les dates de la mesure sont les dates de l'arrêté ?

En parallèle on vient de brainstormer avec @mmarchois une solution assez simple pour faire apparaître dans l'interface d'admin les problèmes rencontrés

Par exemple dès que ce système sera en place je pourrai faire en sorte que l'intégration Eudonet déclare avoir rencontré un problème lorsque l'Alinéa est non-vide

Pour l'instant par contre on n'aura probablement plus que très peu de données Eudonet inspectable dans DiaLog (les problèmes resteront visibles dans le log d'import stocké sur GitHub Actions)

Ça te semble ok ?

florimondmanca commented 6 months ago

Ou alors plutôt se concentrer sur cette interface de reporting car si on n'intègre plus nos données fausses on pourra très difficilement avoir sur la détection de problèmes pendant qu'en parallèle on crée le système de reporting... Je sais pas si je suis clair

johanricher commented 5 months ago

Que penses tu de modifier l'intégration Eudonet pour n'intégrer que les mesures sans "Alinéa" (champ vide), donc où on a de très bonnes raisons de penser que les dates de la mesure sont les dates de l'arrêté ?

Oui ça me paraît une mesure assez conservatrice, on pourra refaire un import et voir si parmi les arrêtés importés il reste des erreurs liées aux dates.

les problèmes resteront visibles dans le log d'import stocké sur GitHub Actions

Est-ce que tu peux me donner un lien vers un log dans Github Actions pour avoir un exemple ?