Open florimondmanca opened 5 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:
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
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
Regular expressions, principalement...
https://stackoverflow.com/a/24288407
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) :
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:
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 :
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
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é
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é
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
@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 ?
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
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 ?
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
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
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