[Epic] Questionnements divers sur le schéma

[thbar]

Je regroupe ici différents points qui sont tirés de retours utilisateurs ou implémenteurs, et qui vont nécessiter des améliorations ou de la documentation, ou du schéma, ou les deux etc.

Je pourrai en extraire des sous-tickets au fur et à mesure, mais j'ai ressenti le besoin de regrouper tout ça pour y voir un peu clair, avec un peu de hauteur.

Notion d'altitude

Il existe des cas où on va avoir, à la même latitude et longitude, mais sur des altitudes différentes (étages) plusieurs stations.

Le schéma ne donne ni le moyen de préciser une altitude optionnelle (coordonnée Z), ni ne fournit de recommandations claires sur le fait de regrouper ou pas ces N étages en une seule station ou une par étage.

Précisions à apporter sur ce qui constitue une station

Il y a parfois un flou sur la définition d'une station (dans le schéma et/ou dans le fichier consolidé en réel), donc on va souhaiter, à défaut peut-être de faire évoluer cette notion, de simplement la préciser.

On peut imaginer qu'il y aie une souplesse organisationnelle qui laisserait l'entité définir ses stations ou pas, etc.

En tout cas il y a parfois des ambiguïtés remontées, et ça devra être traité.

Questionnements autour de nbre_pdc

Sur notre territoire, si je fais la somme du champ « nbr_pdc » je n’obtiens pas le nombre réel de point de charge mais le nombre de point en itinérance car notre prestataire nous dit que c’est ainsi que cela doit être rempli, ce que je ne doute pas.
Cependant, comment fait une personne lambda pour savoir combien il y a de borne (physique) et de point de charge (physique) ? Est-ce que cette information est dans la table ou pas du tout ?

Cette question (Métropole de Rouen Normandie) amène différentes remarques.

1. Il va être nécessaire d'expliciter et de clarifier le fait que la notion de borne n'apparaît pas dans ce schéma (pour différentes raisons tout à fait valables). On ne peut pas compter les "bornes" à l'aide de ce fichier.
2. nbre_pdc compte le nombre réel de points de charge "pour une station donnée" présents dans le fichier, qu'ils soit (actuellement) en itinérance, ou pas.
3. Une ligne du fichier correspond actuellement à "1 point de charge" au sens AFIREV du terme.
4. nbre_pdc doit correspondre au nombre de PDC dans le fichier ayant le même identifiant de station (mais attention, il y a un point à éclaircir aussi concernant la définition de la station, car deux sous-définitions pourraient être en conflit, je reviendrai dessus ultérieurement)
5. Se pose la question de "est-ce qu'on veut, en fait, en terme d'information voyageur, les PDC non itinérant", dans ces fichiers, et quelle est la proportion actuelle de PDC dont l'identifiant PDC itinérance est à "non renseigné" ?

Actuellement, en tout état de cause, nbre_pdc doit être égal au nombre de PDC avec ou sans itinérance, mais rattaché à la même station (voir colonne qui identifie la station). C'est donc une donnée quelque part redondante (qu'on peut garder pour des questions de contrôle), mais pas une donnée qui apporte une valeur autre.

Notion de borne physique

Je dégage ce point : il faut être plus clair sur le fait qu'en aucun cas, ce format dans son état actuel ne permet de comptabiliser les "bornes" physiques sur le terrain.

Voir:

• Demande de rajout d'une granularité Borne dans le schéma irve-statique #59

Clarifications sur la notion de station et son identification

Voir discussion avec PowerDot en interne.

Traçabilité dans la consolidation

Il pourrait être pertinent d'ajouter des colonnes (ou de les documenter de façon "officielle"), absentes de la plupart des ressources, et ajoutées par les consolidations statiques et dynamiques.

Voir par exemple:

• Concentrateur IRVE dynamique national transport-site#3839 qui intègre de façon optionnelle une notion d' "origine" pour pouvoir retracer la source

[thbar]

(je vais éditer la description ci-dessus plusieurs fois)

[thbar]

On a fait avec @stephane-pignal une première analyse en partant du fichier consolidé ici https://transport.data.gouv.fr/datasets/fichier-consolide-des-bornes-de-recharge-pour-vehicules-electriques avec une simple filtre dans LibreOffice sur id_pdc_itinerance "empty" ou "Non Concerné".

On compte 110 lignes environ (soit 1 pour 1000 sur la totalité du fichier) - ça semble effectivement très minoritaire.

On va souhaiter malgré tout aller vérifier dans les fichiers en entrée (en s'appuyant sur le code déjà existant côté transport pour le suivi de validation des jeux individuels).

[thbar]

Question : si on supprime la possibilité de publier des points de charge "sans itinérance", prive-t-on des entités de la possibilité technique de prouver qu'elles ont droit à la prime AFIREV ?

[stephane-pignal]

Merci @thbar pour ce récap

Concernant les éventuelles précisions à apporter sur ce qui constitue une station, il me parait pertinent d'en parler au préalable avec l'AFIREV (historique)

Concernant le nb de pdc, confirmes)tu qu'en tout état de cause il comprend à la fois le nombre réel de points de charge pour une station donnée en itinérance ou pas? Je n'ai pas cette info.

[thbar]

Concernant les éventuelles précisions à apporter sur ce qui constitue une station, il me parait pertinent d'en parler au préalable avec l'AFIREV (historique)

Bonne idée ! Je ne connais pas les interlocuteurs, mais on gagnera à se rapprocher d'eux de façon générale je pense.

Concernant le nb de pdc, confirmes)tu qu'en tout état de cause il comprend à la fois le nombre réel de points de charge pour une station donnée en itinérance ou pas? Je n'ai pas cette info.

La documentation actuelle (https://schema.data.gouv.fr/etalab/schema-irve-statique/2.3.1/documentation.html#propriete-nbre-pdc) donne:

Le nombre de points de recharge sur la station.

sans précisé itinérance ou pas.

Pour moi cela veut dire qu'on comptabilise autant les pdc non itinérants, que ceux en itinérance.

[thbar]

Retours de Métropole Rouen Normandie:

Comme convenu voici un petit récapitulatif sur les IRVE à la suite de notre réunion. Nous aurions besoin de :

Télécharger le schéma datagouv avec toutes les colonnes remplies (objectif qui est rempli actuellement)
Connaître le nombre de borne (au sens patrimoine mobilier) sur notre territoire, pour l’Observatoire des mobilités, mais aussi pour faire des retours aux élus, qui pensent « nombre de bornes / nombre de places » plutôt que « nombre de point de recharge ».

Comme le nombre de borne n’est pas renseigné, nous avons ajouté cette colonne à notre fichier interne grâce à Nicolas Foubert qui refait les calculs à partir du fichier de Bouygues.

Nous avons bien compris que chaque ligne correspond à un point de charge, mais il nous semblerait intéressant de faire changer la structure de la table en retirant le champ « nb_pdc » qui doit actuellement contenir le nombre total de point de charge sur la station. En effet, cela porte à confusion car des réutilisateurs (comme nous), peuvent penser qu’il faut sommer cette colonne pour avoir le nombre de point de charge total pour un territoire donné, alors qu’il suffit de compter le nombre de ligne dans le fichier. Si le retrait de ce champ n’est pas possible car trop contraignant, il faudrait au moins rajouter dans la documentation qu’il ne faut surtout pas sommer cette colonne pour avoir le total des points de charge.

Il serait également intéressant d’ajouter un champ « id_borne » qui pourrait contenir l’identifiant de la borne qui contient les points de charges. De notre côté c’est ce que fait Nicolas manuellement en mettant l’identifiant du point de charge avec B1 ou B2 en dernier pour bien différencier le nombre de borne. Si cela était normalisé, cela éviterait à notre collègue de le faire à la main à chaque fois et cela éviterait les mauvaises interprétations du nombre de point charge total.

Nous avons bien compris que cela n’est pas si simple puisqu’apparemment les bornes n’ont pas toutes un identifiant unique et que cela risque de poser des problèmes aux fournisseurs.

[jmaupetit]

✍️ notes de réunion croisée TDG/QualiCharge sur l'évolution des schémas IRVE.

Disclaimer: ces notes sont rendues publiques mais ne relèvent en aucun cas de décisions prises, nous sommes encore en réflexion conjointe sur ces évolutions.

Evolution schéma IRVE

IRVE Statique

nbre_pdc

Doit disparaitre et être calculé dynamiquement en fonction du nombre de lignes soumises ?

👉 peut disparaitre

code_insee_commune

Doit devenir obligatoire ?

👉 facile pour les clients qualicharge, moins pour les autres acteurs clients de la consolidation (il faut explorer les données pour savoir)
Peut être enforced pour l'API QualiCharge et pas dans le schema.

nom_operateur

Doit devenir un identifiant obligatoire ?

👉 Doit-on aller vers un ID opérateur / aménageur ? Idem : peut être enforced pour l'API QualiCharge et pas dans le schema.

implantation_station

L'avère a une déclinaison de valeurs possibles plus étendue. Doit-on converger vers ce modèle ?

👉 il faut analyser le jeu de données consolidées non validé, non dédoublonné pour évaluer les valeurs à ajouter à notre Enum.

puissance_nominale

Doit-on évoluer vers des catégories ? Comme l'avère ?

👉 la consolidation doit déduire la catégorie

type_alimentation

Nouveau champ pour distinguer AC de DC. Si 22+ on est en DC ?

👉 Peut être que l'on peut déduire le type d'alimentation en fonction des types de prise disponibles (ET+T2 = AC / Combo+Chademo = DC)

tarification

Peut-on commencer à faire évoluer le schéma vers un prix au kWh ?

👉 se renseigner sur ce qui est déjà prévu juridiquement. Nous n'y sommes pas encore.

telephone_operateur

Nous vérifions le numéro soumis qui doit respecter la RFC 3966 ?

👉 doit passer la validation Pydantic. Il faudrait encore une fois évaluer la dispersion sur la consolidation brute.

num_pdl

Nous imposons une string de 14 chiffres, mais rien n'est imposé dans le schéma. Ce numéro nous permettrait de faire le lien avec les courbes de charge Enedis.

Champs supplémentaires des jeux de données Gireve

👉 sont-ces champs des données secondaires ?

id_pdc_regroupement

ex. FR * IZF * EFAST * 185 * 1 * 1

ACNominalPower

DCNominalPower

AC_DC_category

regroupement géographique

region, regionId, departement, departementId

[stephane-pignal]

1. Ce n'est pas simple de se positionner lorsqu'on ne dispose pas de l'historique des champs.
2. Cela me parait pertinent de corroborer avec le réel même si ce n'est que représentatif à l'instant T.

La ressource csv consolidée du 20240816 comporte 107776 lignes

nbre_pdc >peut disparaître

code_insee_commune >pas obligatoire dans le schéma (nb.vide=46,7K 43%). Dans l'absolu ce serait mieux qu'il soit obligatoire mais l'impact me parait trop fort

nom_operateur >pas obligatoire dans le schéma (nb.vide 9,3K 9%). Parait intéressant de la rendre obligatoire, notamment avec la volonté d'améliorer le qualitatif qui va impliquer la gouvernance des données (qui envoie pour qui) et des régles d'éditorialisation sur les doublons

implantation_station > en phase, mérite une analyse approfondie qui devrait aboutir à une évolution des valeurs possibles. L'historique de ce champ serait bien utile. Dans la ressource du jour (seules 100 lignes sont vides), on retrouve "Voirie", "Parking public", "Parking privé à usage public", "Parking privé réservé à la clientèle". Aucun
"Station dédiée à la recharge rapide" et surtout un grand nb de lignes avec n'importe quoi du style "Intermarché Brout le Zouc" ou bien une référence

puissance_nominale >pas d'avis sur la question. Se coordonner avec l'AVERE me parait la bonne idée, s'ils ont eu une bonne idée !

type_alimentation >pas compétent sur cette question, je vous fais entièrement confiance

tarification > à mon avis on va tout droit vers la nécessité de renseigner ce champ (gros enjeu à court terme). En effet bien se renseigner techniquement & politiquement avant de le faire évoluer

telephone_operateur >il me parait pertinent de "durcir" ce champ

num_pdl >là aussi l'historique serait utile, est-il possible qu'un point de recharge en France n'est pas de PDL Enerdis. Le mieux me parait de se caler avec Enedis sachant qu'ils oublieront forcément de nous prévenir le jour où ils vont changer la nomenclature !

Champs supplémentaires des jeux de données Gireve >pas compétent à ce stade

3 remarques me viennent :

• le consolidé actuel comporte des pdc locaux souvent isolés et renseignés à la mano, comment ne pas trop durcir le schéma afin de ne pas les perdre ?
• côté support, comment va t on rendre intelligible le dela entre les schémas (par ex. obligatoire seulement pour QC)
• L'AVERE a absorbé AFIREV qui fixait les identifiants nomenclaturés franco-français. Il y a actuellement des négos au niveau européen, donc il va y avoir aussi une modification de ce côté là.

[AurelienC]

Idée : contraindre le formatage du numéro de téléphone pour harmoniser les valeurs de la colonne, par ex.
[0-9]{10}