search

datagouv / schema.data.gouv.fr

Schémas de données ouvertes sur des formats réglementaires ou non
https://schema.data.gouv.fr
MIT License
41 stars 27 forks source link

Identifiant national dans les schémas #135

Open NicolasBerthelot opened 3 years ago

NicolasBerthelot commented 3 years ago

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 :

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 commented 3 years ago

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

MaelREBOUX commented 3 years ago

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 commented 3 years ago

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

MaelREBOUX commented 3 years ago

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 commented 7 months ago

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":

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