Avia et Zunder absent

[Marc-marc-marc]

les bornes de Avia et Zunder sont absent de l'opendata, une idée pourquoi ?
il y en a par exemple à l'aire de la Porte des Landes-Est https://www.openstreetmap.org/way/705583806

[nlehuby]

non, aucune idée. Ici, on se contente de retraiter les données pour que ça matche plus facilement avec OSM, pas d'info sur leur production ou leur absence de production ...

[Marc-marc-marc]

ma question était plutôt sur

• des raisons interne à la logique du script : je viens de découvrir le fichier des bornes rejetée car localisation ou ref invalide, j'y trouve des coordonnées invalides dont la ref contient Avia (mais en inversant lat<>lon, ces coordonnées ne sont pas celle de cette borne)
• d'autres erreurs ne permettent pas de retrouver l'opérateur, pourrais-tu mettre toutes les infos opendata dans le fichier des erreurs ? il y a par exemple celle-ci à 100m mais j'ignore si c'est la bonne ref vu qu'il y a plus d'une station de recharge à cet endroit
  FR*PY1*P2762868172572606121,gireve-2,coordonnées non valides. Ce point de charge est ignoré et sa station ne sera pas présente dans l'analyse Osmose," [-0.85086 , 44.358871] "
• des raisons externe (toutes les bornes publiques doivent être déclarée ou il y a un critère ?)

[nlehuby]

ah pardon, je me disais aussi que la question était étrange 🤷‍♀️

En effet, le script élimine les données qui n'ont pas assez d'info pour être utilisées par l'analyse Osmose.
Il y a une petite synthèse des vérifications effectuées dans le readme du projet : https://github.com/Jungle-Bus/ref-EU-EVSE/tree/master

Le fichier https://raw.githubusercontent.com/Jungle-Bus/ref-EU-EVSE/refs/heads/gh-pages/opendata_errors.csv liste toutes les stations qui ont été rejetées et la raison.
Les deux premières colonnes permettent de retrouver les lignes concernées dans le fichier source.
Tu peux également remonter directement au fichier initial publié par le producteur en utilisant la colonne datagouv_dataset_id du fichier source. Par exemple, pour la source gireve-2, c'est 63dccb1307e9b2f213a5130c

Je ne vois pas d'inconvénient à ajouter des infos en plus dans ce fichier d'erreurs si ce n'est pas suffisant (en gardant en tête que ce n'est pas un fichier pour mapper, il sert surtout à débugger et à avoir des éléments si on veut faire des remontées aux producteurs). Qu'est-ce qui te semble manquant ?

[Marc-marc-marc]

je prend le cas de Zunder dans l'aire signalée ci-dessus.
si je prend l'opendata en json, que j'ouvre cela dans josm, je trouve la borne (et donc elle a des coordonées géographique valide pour josm)
si osmose ne la propose pas, c'est donc que la moulinette ici la rejette
je prend les coordonnées dans le json de l'opendata : [-0.849669 , 44.361165], je cherche dans le log des rejet, je vois "coordonnées invalides" mais cela ne dit pas si c'est cette borne ou une autre.
Si je cherche Zunder, je ne trouve rien dans le log des erreurs

Je pense qu'il faudrait donc :

• soit la ligne complète de l'opendata (ma préférence) précédé ou suivit de l'info de son exclusion
• soit à minima les infos suivante :
  datagouv_dataset_id
  datagouv_organization_or_owner
  date_maj=2024-09-05
  id_pdc_itinerance
  id_station_itinerance
  nom_enseigne
  nom_operateur
  cela permet dans mon cas soit de chercher Zunder et trouver où signaler le problème en pouvant donner l'id ou retrouver l'id dans le fichier brut de l'opendata pour pas juste dire "cela va pas à cet endroit"

[nlehuby]

ok, c'est plus clair.
L'id et le datagouv_organization_or_owner sont déjà remontés dans les deux premières colonnes, mais en l'occurrence cette aire accumule les problèmes ...

• Déjà, il y a des espaces en trop dans la colonne des coordonnées.
  • Mais c'est en effet une erreur qu'on peut détecter et corriger simplement, d'autant que la consolidation effectuée par transport.data.gouv.fr corrige maintenant ce type d'anomalie directement (ça sera réglé avec la PR Minor improvements #13)
• Ensuite, l'identifiant n'a pas un format valide (donc la station sera rejetée tout de même).
  • Là, le fichier qui reporte les erreurs devrait afficher l'identifiant tel quel, même s'il n'est pas valide. Je ferai une correction là-dessus.

[nlehuby]

ok, il y a eu plusieurs petites modifs qui ont été intégrées. Je pense que ça résout ton problème initial.

@Marc-marc-marc Est-ce que tu peux réessayer et me dire si c'est suffisant ou si tu veux toujours des colonnes en plus dans le fichier d'erreurs ?

[Marc-marc-marc]

merci, je vais tester la nouvelle version

[Marc-marc-marc]

la colonne avec les entêtes n'affiche pas les nouvelles entête :)
Et niveau utilisabilité, pas de Zunder dans la liste, il a fallu que j'ouvre le fichier json de l'opendata dans josm pour trouver que l'identifiant est ESZUN et trouver ainsi les infos (copie partielle pour garder l'utile)
datagouv_dataset_id=63dccb1307e9b2f213a5130c
datagouv_organization_or_owner=gireve-2
datagouv_resource_id=61387a4e-22f7-4662-b241-d5cac4dd91fd
id_pdc_itinerance=ESZUNEFR4002ER20;ESZUNEFR4002ER16;ESZUNEFR4002ER13;ESZUNEFR4002ER09;ESZUNEFR4002ER07;ESZUNEFR4002ER02;ESZUNEFR4002ER01;ESZUNEFR4002ER03;ESZUNEFR4002ER04;ESZUNEFR4002ER05;ESZUNEFR4002ER06;ESZUNEFR4002ER08;ESZUNEFR4002ER10;ESZUNEFR4002ER11;ESZUNEFR4002ER12;ESZUNEFR4002ER14;ESZUNEFR4002ER15;ESZUNEFR4002ER17;ESZUNEFR4002ER18;ESZUNEFR4002ER19
id_station_itinerance=ESZUNP8484368745747197865
nbre_pdc=26
nom_enseigne=Zunder
nom_operateur=Zunder | ES*ZUN

en reprenant la ref, on trouve alors dans le log 10x
ESZUNP8484368745747197865,gireve-2,le format de l'identifiant ref:EU:EVSE (id_station_itinerance) n'est pas valide. Ce point de charge est ignoré et sa station ne sera pas présente dans l'analyse Osmose,"iti: ESZUNP8484368745747197865, local: 1130505"
Je ne sais pas pq 10x alors qu'il y a 26 prises (et sans doute 13 bornes)
je ne vois pas non plus l'erreur de format de l'identifiant ref:EU:EVSE, si je décompose, cela donne :
ES code pays ; valide
ZUN Code d’identification de l’unité d’exploitation ; format valide
P station : valide
8484368745747197865 19 caractères ; format valide
est-ce que ce serrait parce que le caractère optionnel est attendu comme obligatoire ?

Le nom enseigne/opérateur me semble donc très utile dans le log et une meilleur info de pourquoi la ref est invalide

[guiohm]

Pour le moment, on valide explicitement les refs commençant par FR :
https://github.com/Jungle-Bus/ref-EU-EVSE/blob/master/group_opendata_by_station.py#L64

Bizarre qu l'AFIREV ait donné des refs non FR en France.

[Marc-marc-marc]

ce n'est pas nécessairement la France qui a donné le code espagnol :) c'est sans doute l'équivalent espagnol... et comme il s'étend hors Espagne, il me semble logique qu'il continue d'utilise "son" code y compris pays d'origine (mais peut-être faudrait-il demander upstream)

[Marc-marc-marc]

autre exemple de problème incompréhensible avec le niveau de log actuel 👍 FRFR1P8238777997472919619 est dans l'opendata mais présent ni dans https://raw.githubusercontent.com/Jungle-Bus/ref-EU-EVSE/gh-pages/opendata_stations.csv ni dans https://raw.githubusercontent.com/Jungle-Bus/ref-EU-EVSE/gh-pages/opendata_errors.csv

[guiohm]

Curieux, c'est bien présent en sortie dans la version qui tourne sur mon repo :
https://guiohm.github.io/ref-EU-EVSE/

[guiohm]

C'est probablement du au fait que les données varient d'un jour à l'autre.
Ce repo https://github.com/BastienGauthier/clean_french_irve/ consolide dans un fichier 'robuste' ces variations.
Je proposerai peut-être quelque chose similaire ici si ça ne se stabilise pas.

[guiohm]

Voir cette PR #22

[guiohm]

Pour les logs, j'ai une grosse PR à proposer, mais je dois d'abord finaliser quelques points.