Format de l'identifiant bâtiment #24
Comments
fe51
added
help wanted
|
Bonjour à tous, |
|
bonjour et merci pour cette contribution. Nous travaillons actuellements a lier les identifiants produits (GTIN de GS1), des identifiants d'action de mise ne oeuvre (à imaginer) et des identifiant de position dans l'Ouvrage (actuellement des GLN ou sGLN de GS1). Le Bat ID devrait pouvoir nous service de racine à notre position de l'ouvrage. bien à vous |
|
J'imagine qu'il a été discuté de considérer les documents du "Groupe de travail Identificateurs de Ressource Uniques" du CNIG, qui citent "Implementation of Identifiers using URIs in INSPIRE" ; ainsi que les spécifications Inspire concernant les bâtiments ? Autre argument en défaveur des UUID: en présence d'un UUID, il est tentant de le promouvoir comme clé primaire dans un SGBD ; cela grève les performances car l'indexation ne peut se faire sur un UUID, les éléments n'étant pas ordonnés/ordonnable. Question, l'id doit-il être doté d'une clé de contrôle ? My 2 cents, |
|
Merci de remonter ce nanoID, qui m'a l'air de combler le principal défaut des UUID, à savoir la capacité à noter ça à la main et comparer à l'oeil des UUID. ça me plaît beaucoup en fait. et quelques exemples de code généré
Avec des En descendant à 13 caractères sur cet encodage, ça fait ~ 5000 ans pour atteindre le 1% de proba de recouvrement, ce qui me parait suffisant. De toute façons, un client générant un id localement va rencontrer une erreur de clé en remontant cela dans la base nationale. J'imagine qu'il y aura toujours une instance nationale qui assurera des règles de consistance comme l'interdiction de doublons géographiques exacts, ou des bâtiments recouverts majoritairement, ce qui arrivera inévitable en frontière de commune avec des batiment à cheval entre deux collectivités codifiantes. La question de préfixer avec des codes géographiques de département remontera au CNIG, par exemple un |
|
Bonjour à tous, @NicolasPyIGN, je trouve l'idée d'une clé de contrôle intéressante dans le cadre d'une clé qui a vocation à être copiée/transférée à la main. Cependant, cela n'a d'intérêt que si le système qui reçoit la recopie a implémenté le système de vérification. Pour ce qui est de son utilisation en tant que clé primaire : ce ne sera pas le cas. En interne, nous avons une clé primaire classique, en entier auto-incrementé. @haubourg Je pense que l'utilisation combinée entre majuscule et minuscule est un facteur de confusion dans le cas d'une recopie manuelle. Je suis prêt à parier que la casse ne sera pas respectée dans une proportion non négligebable de cas. Il semble plus robuste d'allonger légèrement l'id et de rester en majuscule. Je suis complètement en phase avec votre remarque sur les départements. |
Bonjour et bienvenu sur le projet !
J'ai du mal à imaginer un référentiel national des batiments qui ne lève pas des anomalies de ce type ;-) Si grâce au NanoId, on sait générer un identifiant pseudo unique de manière décentralisée, ça n'empêche pas que sur le fond on veut éviter qu'une logique de création décentralisée n'aboutisse pas à décrire des objets métiers identiques deux fois avec des id différents. Ces contrôles peuvent être réalisés à froid bien sûr, pas forcément à la volée au moment de la remontée vers la base centrale.
c'est classique sur une appli informatique oui, mais une contrainte d'unicité sur la clé d'intéropérabilité / identifiant public est impérative malgré tout. Les systèmes d'information décisionnels vont eux utiliser cette clé comme une clé primaire.
C'est possible oui. Et c'est bien plus confortable de ne taper que des minuscules :) |
|
Bonjour, et merci pour ces contributions que je lis avec intérêt ! |
|
Bonjour @GT-CNIG-DDU, |
|
@haubourg Tout à fait, l'identifiant sera bien unique. |
|
Bonjour, est-ce qu'il est envisagé qu'une partie du format de l'ID fasse référence à des données réelles comme c'est le cas pour le n° fiscal logement : |
|
Bonjour @SylvainBessonneau, |
|
Bonjour à tous Merci d'avance de vos réponses Bien à vous |
|
Bonjour @RollandMELET, J'ai lu le "Guide sur les identifiants de ressource uniques" du GT IRU mais n'y ai pas trouvé de contre-indication. A côté de quoi passons nous ? Y a-t-il un format en particulier qui nous rendrait conforme à la directive INSPIRE ? Merci pour votre éclairage. |
|
Pour moi il faut surtout s'assurer au sein des acteurs français pour avoir
un espace de nommage stable des uri sur le long terme. On ne doit pas
casser un client inspire si on décide de renommer le domaine du RNB.
Cela supposera aussi de remettre à plat ce que l'on remonte comme lot de
donnees de référence des batiments à l'europe. Pour l'instant c'est la
bdtopo dans les faits et les bâtiments du cadastre dans le code de
l'environnement 😅
(Ok c'est censé converger )
Le lun. 27 févr. 2023, 17:14, pe-beta ***@***.***> a écrit :
… Bonjour @RollandMELET <https://github.com/RollandMELET>,
Je dois avouer ne pas encore être familier avec la directive INSPIRE.
Les informations du RNB liées à un identifiant/bâtiment seront accessibles
via une API. L'URL d'un bâtiment sera de type
https://rnb.data.gouv.fr/chemin/a/definir/**IDENTIFIANT-DU-BATIMENT** (le
domaine est encore à définir)
En ce sens, selon moi, nous fabriquons bien une URI.
J'ai lu la documentation envoyées par @NicolasPyIGN
<https://github.com/NicolasPyIGN> mais n'y ai pas trouvé de
contre-indication. A côté de quoi passons nous ? Y a-t-il un format en
particulier qui nous rendrait conforme à la directive INSPIRE ? Merci pour
votre éclairage.
—
Reply to this email directly, view it on GitHub
<#24 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAMN5HLEQM4GKOP2OT4UYTLWZTHGRANCNFSM6AAAAAAVF5JPIY>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
Bonsoir à tous, Tout d'abord, merci pour vos nombreux retours.
|
de l'extérieur, un des plus gros problèmes est de savoir où sont les données associées à un ouvrage. |
|
Bonjour,
|
L'usage dans un identifiant de données administratives qui peuvent être amenées à changer (redécoupage de départemets par exemple), est à proscrire. Il est sans doute plus adapté de préfixer le nanoID envisagé avec la localisation géographique à une résolution à définir. Cela permet de segmenter les bâtiments géographiquement sur leur seul nanoID. |
L'usage du tiret '-' est à décourager, en effet le double-clic sur un ID qui contient des '-' conduit à la sélection d'une sous-partie dudit identifiant. Ce souci n'est par contre pas rencontré avec l'usage du souligné '_', même si ce dernier présente le désavantage d'être peu visible si le curseur est positionné dessus. |
|
Super intéressant @NicolasPyIGN , merci pour le lien. @M4thi3u34 ça peut t'intéresser, le pdf de présentation de la situation d'id des batiments et des problématiques d'adressage est intéressante, un pays fédéral c'est encore plus compliqué! En revanche le dépôt à l'air à l'arrêt depuis 2 ans. Je ne suis pas certain que la proposition d'aller vers un GeoHash plus intelligent ait passé le cap de la proposition comme le laisse entendre ce doc : https://buildingid.pnnl.gov/pdf/20200412-UBID_Partner_Interview_Summary.pdf. Je trouve l'idée élégante de pouvoir regénérer l'id depuis une géométrie, ou regénérer une bbox depuis une géométrie. C'est - en rapide - un encodage d'une bbox minimale alignée sur l'axe nord-sud, doublée d'une notion d'extension spatiale lisible par un humain, donc on peut faire des opérations spatiales dessus directement et avoir une idée de la taille de l'étendue en lisant l'ID Après, ça reste un encodage signifiant. c'est contre ma religion, forgée sous les coups des morsures de hordes d'identifiants enragés de trop de sens. |
|
Bonjour, L’addition des éléments de lieu et de date suivie d’un numéro d’ordre chronologique permet d’obtenir un identifiant unique pour désigner un objet sans ambiguïté. C’est cette méthode qui est utilisée pour former les identifiants cités en exemple à notre discussion, et ceux donnés aux Permis de Construire, pour se rapprocher encore un peu plus du sujet qui nous intéresse. L’utilisation de la chaine de caractères composant le code géographique d’une commune à l’intérieur de l’identifiant du bâtiment ne pose, à mon avis, pas plus de problème que l’utilisation de n’importe quelle autre chaine de caractères. L’important est que la chaine totale résultante reste unique et utilisée seulement pour ce qu’elle est, c'est-à-dire pour désigner un objet. L’avantage de cette méthode est qu’elle est facilement compréhensible à ses utilisateurs et qu’elle laisse à l’autorité locale compétente une relative autonomie pour la numérotation des bâtiments de son territoire.
Cette méthode ne s’oppose pas à la création d’un identifiant national au moment de l’intégration de la base locale à la base nationale des bâtiments. |
|
Bonjour, En lisant tous les échanges et après réflexion, pourquoi ne pas tout simplement utiliser un ID dont la structure serait proche de celle utilisée pour les plaques d'immatriculation ? Donc un ID de type : AB456FV Pour rappel, plus de 31 millions de voitures sont en circulation actuellement et aucune n'a (normalement) le même numéro. Et si l'on reprend les critères évoqués par Félix :
Bien entendu il pourrait y avoir les critiques suivantes : A) Le risque de collision est élevé. C'est vrai mais : Or :
Donc pourquoi ne pas générer les 500 millions d'ID, d'attribuer de manière aléatoire (sans remise) les 30 millions d'ID (correspondant aux 30 millions de bâtiments actuels) et laisser un stock de plus de 470 millions d'ID pour les futurs bâtiments à venir. Pour rappel, sur les 150 dernières années, le nombre de bâtiments produits annuellement (dans les faits plutôt des adresses) est proche de 170 000 (et 100 000 sur les 10 dernières années). Donc à ce rythme il faudrait plus de 2000 ans pour écouler le stock d'ID généré. Les ID auront alors bien vécu :-) Au niveau local, rien n’empêchera alors à une commune de sélectionner un ID de manière aléatoire parmi le stock disponible (l'ID étant alors supprimé du stock une fois validé). Dans ce cas un outil, comme le SIV pour les plaques d'immatriculation , pourrait alors être utilisé. Comme mentionné la base serait centralisée. Mais dans la pratique, l'ID sera généré très probablement par une administration publique (le service foncier d'une commune) lors de l'attribution du permis de construire par exemple ou suite à la vérification de la fin de travaux. Donc se sont des acteurs qui pourraient parfaitement être, au quotidien, connectés à l'outil d'attribution centralisé des ID. A moins que l'on estime que n'importe qui pourra générer l'ID mais même dans ce cas l'ID devra être remonté quelque part --> une base centralisée. |
|
Bonjour, merci pour ce commentaire qui apporte entre autre un potentiel de simplicité d'usage. Une première réaction, Pour résumer, au dela de raccourcir l'ID (7 caractères dans le cas de l'immatriculation), ce qui le rend clairement plus exploitable par des humains, c'est également le fait d'avoir un enchainement 2 lettres - 3 chiffres - 2lettres, qui facilite probablement encore plus l'usage par des humains. Proposé ainsi, cela semble être une solution plus (et a qualité équivalente au regard d'un "cahier des charges", le plus simple le mieux). Dès lors, dans quelle mesure ce format d'ID poserait problème ?
--> In fine, (à la rigueur peut importe l'acteur, la commune étant bien entendu un parfait exemple), cela imposerait donc pour piocher dans le stock, d'être capable à tout instant de recourir à un service de distribution ID (versus, je peux générer un NANO ID localement selon les règles établies) qui doit toujours être opérationnel (et gérer les mauvais usages/massif ou autre). Est ce que cela doit être vu comme un point d'attention ? En terme de stock, 500 millions, dans les usages, cela semble OK. Il n'est pas impossible car généré au plus tôt soient des ID de batiment qui ne voient pas le jour, il semble qu'on reste safe à 500 Millions, on peut toujours imaginer un format un peu différent que le SIV embarquant davantage de lettre et prendre le large. Preneur d'avis sur ces points ! |
|
En parallèle de la suite des discussions, pour faire suite à la réunion du GT CNIG le 10 Mars 2023, CR ici , De nombreux éléments de réflexions présents dans cette discussions comme lors de la dernière réunion semblent faire pencher vers un ID non signifiant. Nous aurions souhaité avoir votre avis à travers un sondage afin d'aider le Groupe de Travail à arbitrer sur ce point. Dans la cadre du Référentiel National des Bâtiments, l'ID doit-il être signifiant ? 🚀 Répondez en commentant avec cet émoticone de fusée si vous considérez que l'ID doit être signifiant 🎉 Répondez en commentant avec cet émoticone de "fête" si vous considérez que l'ID NE doit PAS être signifiant Merci bcp pour vos retours. |
|
Pour être moins manichéen il manque à mon avis les propositions : "l'ID peut être signifiant" et "sans opinion". Je complète en proposant d'écouter les territoires car in fine on leur demandera très probablement de prendre en charge une part de la gestion des ID, et in fine c'est eux qui s'en serviront pour leur gestion métier interne. Les territoires sont habitués pour différentes thématiques à identifier les objets par un type, une date et un numéro d'ordre. C'est efficace et compréhensible par un humain. C'est pourquoi j'adhère à la proposition de @Geo-Toulouse du type |
Comme dit en séance, le préfixe par code insee de commune va vite engendrer des batiments héritant de code insee ayant changé. La règle la plus importante est la stabilité des identifiants dans le temps. Hors on résistera difficilement à la tentation de la recodification pour garder une signifiance , comme la base adresse recodifie les adresses lorsques les code de rue RIVOIR changent en amont. Le seul compromis qui serait un peu plus stable serait un préfixe par code département, mais cela induira malgré tout les mêmes soucis. Bref, pour m'être fait mangé plus d'une fois par les identifiants signifiants, je replaide contre :=) |
|
Côté Enedis, nous plaidons également pour un identifiant non signifiant - ce qui est la base pour un référentiel d'objets - surtout aussi transverse. A noter que cela est très largement partagé dans la sphère des urbanistes SI. Voir par exemple de ce document de 2013 : |
|
Bonjour à tous, La méthode SIV proposée par JVURBS est intéressante car elle permet d’attribuer un identifiant pris dans un ensemble prédéterminé ce qui annule tout risque de collision et réduit considérablement la longueur des identifiants. Cependant, cette méthode suppose une organisation nationale avec un système central d’attribution qui doit rester accessible à tous. Cette contrainte d’un dispositif central était déjà nécessaire pour l'attribution du NanoID s'il devait être construit de manière spécifique pour respecter toutes les règles énoncées à notre discussion. Avec ces méthodes SIV ou NanoID, la numérotation du stock pourra se faire sans problème au niveau national (quand il sera construit et validé dans sa consistance…). La numérotation du flux devra se faire ensuite par une autorité locale à nommer, avec la condition que cette autorité soit reconnue nationalement et bien délimitée dans sa zone de compétence pour éviter les trous ou les doublons à la numérotation. Comme indiqué par JVURBS, cette autorité locale sera très certainement la Commune ou l’EPCI qui la représente car c’est déjà à ce niveau que se situe les compétences en matière d’adressage et d’instruction des Permis de Construire. D’un point de vue pratique, toutes les communes ne seront pas en mesure de se connecter à un système centralisé pour récupérer des identifiants nationaux au fur et à mesure de leurs besoins. Par ailleurs un EPCI pourrait vouloir différentier la numérotation des identifiants de ses communes ou même vouloir gérer ses propres identifiants pour les mettre en relation avec les autres tables de son système d'information. C’est en quoi je pense que la solution à retenir demanderait à reposer sur une organisation territoriale définie sur les deux niveaux du local et du national, comme c’est déjà le cas pour la BAN. En l’occurrence, il pourrait être créé des Bases de Données Locales des Bâtiments (BDLB) où les Communes ou leur EPCI seraient autonomes à leur gestion en respectant une structure et une procédure nationale qui se termine par l’obligation de publier leur BDLB en opendata. Les BDLB seraient ensuite moissonnées et agrégées au niveau national pour constituer la BDNB où il serait toujours possible d’ajouter une immatriculation nationale aux bâtiments. En ce qui concerne le vote Signifiant/NonSignifiant, je choisirais moi aussi une position intermédiaire en disant que "l'ID peut être signifiant pour partie"' ou que "l'ID est non signifiant sur sa zone d'attribution" Georges Monnot |
|
A la suite vote, et les divers échanges dans cette issue, ainsi qu'en séance, la non signifiance semble recueillir un argumentaire plus fourni et davantage d'échos auprès des divers acteurs. Je vous propose ici d'essayer de discuter sur le format en tant qu'ID non signifiant. Les deux options aujourd'hui envisagées, sont :
L'avantage principale du NanoID est qu'il est possible de le produire de façon tout à fait décentralisée (donc sans accès à internet ou le besoin d 'avoir un service live centralisée live de génération d'ID pour recourir à une attributions d'IDs et introduit peu de complexité dans le processus de génération à l'usage) avec un faible risque de collision (qui est gérable à l'intégration). Son inconvénient principal est qu'il est moins lisible que l'ID format "plaque d'immatriculation". Est ce concrètement bloquant ? Est il vraiment moins lisible ? Nous sommes preneurs de vos avis et éléments de réflexion sur ces points afin de préparer au mieux la prochaine séance CNIG du 5 mai (nous prendrons une première décision quant au format dans le but de l'expérimenter et d'obtenir des retours terrain) Merci d'avance pour vos contributions :) |
|
Commentaire reçu ce jour par email à l'équipe Bat-ID : "j’ai une préférence pour le Nanao ID, du fait de sa généralisation décentralisée. Dans tout les cas, l’Id sera toujours accompagné d’autres informations (coordonnées géographiques, adresse sémantique) qui permettront si nécessaire de vérifier les cohérences). La stabilité de l’ID dans le temps est un facteur essentiel de succès." |
|
Bonjour, De mon côté (encore une fois) le choix dépendra du problème que l'on voudra minimiser : Si on veut un ID pour un usage en base de données et via des requêtage (donc par machine) sans grande intervention humaine --> Alors Nano ID Si par contre on pense que le facteur humain (transfert à l'oral d'un ID, partage de l'info par mail, besoin de retenir facilement un ID) est important (et potentiellement limitant) alors format "plaque d'immatriculation". PS : question subsidiaire ? |
|
Bonjour, Je m'exprime ici en tant que représentant d'une entité qui est productrice de données locales et contributrice à une BD / un référentiel supra agrégeant des données. Sur ce postulat voici nos propositions / préoccupations :
Sur ce dernier point il me semble que la prise en compte des travaux sur les URI INSPIRE est possible. Mais ces travaux étaient très théoriques et entretemps les avancées concrètes sur le linked data sont à prendre en compte. C'est même essentiel je pense. |
|
Complètement en phase avec @MaelREBOUX de mon coté.
Alors j'étais sur la même ligne avant de tester en vrai sur des applications de gestion opérationnelle. Sur les égouts de Paris. Il y a un rejet fort de la part des utilisateurs sur l'impossibilité de noter ou comparer à l'oeil un UUID complet. La structure et la longueur ont été rejetées par l'ensemble des utilisateurs qui ont demandé le retour d'un entier incrémenté (même si la clé technique restait l'UUID). Je trouve le NanoId comparable à l'oeil. L'UUID ça demande l'habitude de regarde les derniers chiffres, ce que les developpers ont l'habitude de faire avec les commit git, mais pas les utilisateurs |
|
Sinon 100% en phase avec @MaelREBOUX |
|
Découverte dans mes RSS du jour, sans que je ne les ai creusés:
|
|
@fe51 on doit pouvoir fermer ici ? |
La mise en oeuvre du Référentiel National des Bâtiments (RNB) implique de générer un identifiant pour chaque bâtiment.
Les différentes réflexions sur ce sujet, entre autre via le groupe de travail bâti du CNIG amène à considérer que l’ID ne doit pas être signifiant (notamment pour être pérenne)
L’objet de cette discussion a pour but d’étayer cette reflexion afin d’aboutir à un format d’ID correspondant à une bon usage du référentiel.
QQ critères pour animer la reflexion :
Proposition
Un NanoID de 15 caractères parmi l’alphabet suivant
123456789ABCDEFGHJKMNPQRSTVWXYZc’est à dire en retirant les 0,O, I, L, U pour éviter les confusions (inspiré du Crockford Douglas Base 32)Le site suivant aide à estimer le risque de collision. Dès lors, à raison d’une génération de 50 IDs par heure (~400 000 bâtiments générés par an), il faudrait environ 50 milliers d’années pour avoir une probabilité de 1% d’avoir au moins une collision.
Un exemple ID bâtiment pourrait donc être A8YB2 58DEH KAZD1
Ce NanoID répond à l’ensemble des critères évoqué précédemment et possède une implémentation dans de nombreux langages de programmation.
Hâte d’avoir vos retours et avis sur ce sujet ! Merci beaucoup !
Exemple dans la vie quotidienne
Liste de différent générateur ID
The text was updated successfully, but these errors were encountered: