Mise à jour description du format irve statique

[stephane-pignal]

@thbar Document encours d'élaboration
Concerne le texte https://schema.data.gouv.fr/etalab/schema-irve-statique/2.2.0/documentation.html
Dernière issue mise à jour 20220906

Objectif : une meilleure compréhension de certains champs pour les producteurs ainsi qu'une montée en en qualité des données.

Constat : suite aux différentes entretiens Affirev, Avere, Gireve et à des retours producteurs, il est opportun d'apporter des précisions/modifications/ajouts sur la documentation du format IRVE statique.

Expliquer en préalable les concepts Station, Borne (granularité absente pour l'instant), Point de Charge (pdc) en s'inspirant avec son accord de la doc de Philippe Thomy

Propriété siren_amenageur
Rajouter "composée de 9 chiffres"
Permet d'éviter le confusion avec le n° de SIRET (13 chiffres)

Propriété id_station_itinerance
Mettre à jour le texte "Cet ID débute par FR suivi de 3 caractères délivrés par l'AFIREV, suivi de "P" pour "pool" qui veut dire "station" en anglais (https://afirev.fr/fr/informations-generales/)"
Suite à la disparition de l'AFIREV, l'AVERE va reprendre la gestion des identifiants (le lien Afirev ne sera bientôt plus valable)

[ptitfred]

J'imagine que tu avais déjà vu ceci qui semble faire (à sa façon) ce tu suggères dans ton exemple

S'agit-il de le reformuler pour le rendre plus explicite ?

[stephane-pignal]

Yep objectif de plus d'autonomie pour moins de support sur des erreurs de ce type

[ptitfred]

Yep objectif de plus d'autonomie pour moins de support sur des erreurs de ce type

Naïvement je trouve que ce message est déjà explicite (un exemple et une règle de format). Comment imagines-tu améliorer cela ?

[stephane-pignal]

Je te rejoins, cela devrait largement suffire.... mais non
Ces propositions de modifs sont issues du support côté producteurs où nous avons des profils d'interlocuteurs très divers. Par ex. ce matin, une personne qui s'occupe d'administration des ventes et de constituer le fichier csv.
Ma proposition serait "Le numero SIREN (9 chiffres) de l'aménageur issue de la base SIRENE des entreprises. Vous pouvez récupérer cet identifiant sur le site annuaire-entreprises.data.gouv.fr."

[Pierlou]

Je relance le sujet : l'idéal serait également d'ajouter une contrainte plus dure que la regex actuelle : "pattern": "^\\d{9}$", qui est trop permissive (à date, ~2k lignes du consolidé contiennent un SIREN qui n'existe pas).
Cela pourrait être fait via un custom check

[AurelienC]

Préciser que le séparateur dans le CSV doit être des virgules

[Pierlou]

Préciser que le séparateur dans le CSV doit être des virgules

Est-ce qu'il y a un champ dédié dans la standard Table Schema ? Au-delà de ça, pas convaincu que la virgule soit le meilleur choix, notamment à cause de la présence de la colonne coordonneesXY qui demande nativement la présence d'une virgule et devra donc être entre " pour éviter d'interférer

[johanricher]

Table Schema n’a aucune notion de séparateur, il travaille au niveau au-dessus, sur les données tabulaires et pas leur sérialisation CSV. En clair, un fichier tabulaire sera valide s'il respecte le schéma, quel que soit le séparateur utilisé et même quel que soit son format tant qu'il est supporté (.csv, .xlsx, .xls, .ods...).

Je pense qu'il faudrait préciser ça ici d'ailleurs : https://guides.data.gouv.fr/guides-open-data/guide-qualite/maitriser-les-schemas-de-donnees/creer-un-schema-de-donnees/focus-construire-un-schema-tableschema#format-de-fichier-csv

[AurelienC]

L'idée est de mettre cette "contrainte" (non vérfiée par Table Schema) dans le texte descriptif qui accompagne le schéma ; cela conforte ce que l'on demande déjà par ailleurs et que nous vérifierons dans la future consolidation par transport.data.gouv.fr.

Pour le choix de la virgule, il semble historique à IRVE et à d'autres schémas (trop jeune pour savoir :D)

[vdegove]

La partie :

Expliquer en préalable les concepts Station, Borne (granularité absente pour l'instant), Point de Charge (pdc) en s'inspirant avec son accord de la doc de Philippe Thomy

Est traitée par #70