Identifiant national dans les schémas

[NicolasBerthelot]

Suite à nos différents travaux sur différentes bases nationales, l'équipe de transport.data.gouv.fr réinterroge le champ "identifiant national" présent dans la plupart des schémas nationaux proposés sur schema.data.gouv.fr.

Pourquoi sont-ils utiles ?

Les identifiants nationaux sont utiles pour les réutilisateurs pour suivre la mise-à-jour des fichiers. En effet si des informations changent sur une borne de recharge ou un parking et que l'identifiant est stable, un utilisateur peut reporter le changement dans sa base. Cela n'est d'ailleurs qu'utile qu'à partir du moment où il a construit des informations dérivées à partir de cet élément. S'il ne fait qu'afficher les données, disposer d'un identifiant n'est pas vraiment utile.
Pour le producteur des données, l'identifiant national n'est pas vraiment utile.
En revanche, il est utile pour l'agrégateur des données pour mettre à jour les données de la base nationale.

Problèmes posés

Le principal problème posé par l'identifiant national est liée à sa production. Il est généralement déterminé par un organisme national comme transport.data.gouv.fr pour les parkings, les aires de covoiturage ou par l'AFIREV pour les bornes de recharge. Or, ce champ "id" est considéré comme un champ obligatoire. Les fichiers qui n'ont pas des identifiants complets et conformes sont considérés invalides par le validateur Validata. Plusieurs conséquences :

• cela peut être déceptif pour les producteurs de données
• cela empêcherait une consolidation automatique des fichiers qui ne contiendraient pas d'identifiants nationaux
• cela empêche l'utilisation de nouvelles manières collaboratives que nous développons actuellement à transport.data.gouv.fr

Aujourd'hui le problème peut être contourné en laissant le producteur de données définir par lui-même les identifiants nationaux car la recette pour les constituer est relativement simple. Mais cela suppose généralement que le producteur soit le seul à produire des données sur son territoire.

Solutions proposées

Pour pouvoir assurer le suivi des mises à jour de manière fluide il faudrait alors rendre obligatoire la fourniture d'un identifiant local id_local pour permettre à l'agrégateur national de faire le suivi des mises à jour locales.

Pour le champ identifiant national id : deux options :

1. Retirer le champ id
   Une des solutions simple serait de retirer le champ id des schémas nationaux. Cet identifiant ne serait ajouté qu'a posteriori par l'agrégateur national. Le champ id serait livré dans la base nationale et pourrait être documenté dans une documentation associée au jeu de données.

2. Rendre optionnel le champ id
   L'autre solution est de rendre optionnel le champ id des schémas nationaux. Cela a pour avantage de permettre aux fichiers qui n'en contiennent pas d'être validés.

[abulte]

@jdesboeufs curieux d'avoir ton avis là-dessus

[MaelREBOUX]

Bonjour,

Je suis le coordinateur-animateur du groupe de travail voies-adresses du groupe SIG Topo de l'AITF --> https://github.com/aitf-sig-topo/

Nous sommes confrontés à l'absence d'identifiant national sur le sujet des voies et des adresses et nous prônons depuis 2016 la création d'un système de "guichet" d'attribution / gestion des identifiants nationaux.

Nos réflexions sont consignées dans notre document de spécification visant à diffuser des données voies-adresses locales. Nous avons en effet commis 2 (petits) chapitres sur le sujet dans le cadre de nos discussions générales.
Tout le détail du format BAL est dans le document v 1.2 fraîchement révisé et téléchargeable ici :
https://aitf-sig-topo.github.io/voies-adresses/#format-bal

Nous n'avons pas retenu de diffuser un id_local car il y a une énorme disparité dans les capacités des SI(G) des collectivités locales à créer et surtout maintenir des identifiants uniques stables. Pour des bonnes et des mauvaises raisons. Mais ce n'est pas le sujet mais une réalité à prendre en compte.

Pour compenser nous avons imaginé une clé d'interopérabilité que chacun pourrait reconstruire mais elle nécessite un identifiant de voie qui est géré par un organisme tiers qui impose ses contraintes et son rythme, impactant négativement toute la chaîne.

Etalab a quelques mois (années ?) de recul sur l'agrégation de fichiers locaux afin de constituer un fichier national et nous arrivons toujours à la conclusion qu'il nous faut un "guichet neutre" sur lequel les collectivités locales viendraient déclarer la création / modification / suppression d'une voie ou d'une adresse. D'autres réutilisateurs des données voies-adresses des collectivités locales souhaitent également avec impatience la mise en place d'un tel identifiant afin de synchroniser / mettre à jour plus rapidement et efficacement leur SI internes.

C'est un chantier majeur dans le cadre de la mise en place d'un vrai référentiel voies-adresses et nous comptons le lancer début 2021.

Tout reste à imaginer mais, selon moi, les principes à l’œuvre pour les voies-adresses devraient avoir un recouvrement assez fort avec vos préoccupations sur les données transports. Alors : conjuguons nos efforts ?

[camillemonchicourt]

Je m'interroge sur un sujet similaire et j'avais imaginé :

• un "id_local" informatif permettant de retrouver l'objet dans sa base de données source
• un UUID de référence, idéalement généré dans la base de données source par le producteur (avec PostgreSQL ou autre c'est très simple) qui serait celui utilisé pour la traçabilité et le partage de l'objet dans différentes bases de données.

[MaelREBOUX]

UUID de référence, idéalement généré dans la base de données

à arbitrer... vite !
et rédiger un mous operandi pour faire ça correctement, en système très hétérogènes...

[thbar]

Nous sommes confrontés à l'absence d'identifiant national sur le sujet des voies et des adresses et nous prônons depuis 2016 la création d'un système de "guichet" d'attribution / gestion des identifiants nationaux

Je "poke":

• @cyrilmorin avec qui je travaille sur un référentiel d'arrêts national épaulé par http://transport.data.gouv.fr
• @fchabouis qui a un sujet analogue sur la cuisinière

Un petit "workshop" commun sur le sujet serait sûrement pertinent !