M4thi3u34
commented
1 year ago Bonjour à tous, Merci pour ce poste, peut-être expliciter qu'il n'y a pas d'adhérence avec la notion de GeoHASH qui ne sont pas fait pour être recopiés à la main.
Open fe51 opened 1 year ago
M4thi3u34
commented
1 year ago Bonjour à tous, Merci pour ce poste, peut-être expliciter qu'il n'y a pas d'adhérence avec la notion de GeoHASH qui ne sont pas fait pour être recopiés à la main.
RollandMELET
commented
1 year ago bonjour et merci pour cette contribution. Je fais parti d'un groupe joint entre https://buildingsmartfrance-mediaconstruct.fr/ et https://www.gs1.fr/ dans lequel nous travaillons la question de la continuité numérique entre tous les acteurs de la construction, de la rénovation et de la maintenance des ouvrages bâtis.
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. En ça se erait TRES utile que cet ID puisse être une URI de sorte à toujours pouvoir relier l'ouvrage à ses datas.
bien à vous
NicolasPyIGN
commented
1 year ago 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 ? Cela éclaire cependant encore trop peu votre débat.
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,
haubourg
commented
1 year ago 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.
J'ai un peu joué avec le générateur, on pourrait prendre un alphabet avec minuscules et majuscules, enlever les - et _ et garde le L , peu équivoque.
ça donne cet alphabet d'encodage 0123456789ABCDEFGHLJKMNPQRSTUVWXYZabcdefghjkmnpqrstuvwxyz
et quelques exemples de code généré
DAPmKFGk24Q2
wfurftWfakjA
PUmJWYyCGHkz
Avec des - et _, j'ai trouvé assez étrange d'avoir ces caractères en début de d'ID, comme par exemple _PUmJWYyCGHkz . Informatiquement ça ne me choque pas, j'ai plus peur qu'à l'usage des personnes les supprime à l'écrit , pensant que ça ne fait pas partie de l'ID
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. En prévoyant des règles de gestion dédiées, ça me semble parfaitement raisonnable. On pourrait même descendre encore plus court!
La question de préfixer avec des codes géographiques de département remontera au CNIG, par exemple un 38_DAPmKFGk24Q2 . Cela permettrait encore de réduire la taille de la partie aléatoire du code. En revanche, le jour ou les département sont refondus, c'est l'enfer. Un simple redécoupage de limite communale faisant frontière de département laissera des batiments avec l'ancien code de département à jamais. Donc NON pour moi ;)
pe-beta
commented
1 year ago Bonjour à tous, J'ai rejoint bat-id en tant que développeur il y a deux semaines.
@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.
haubourg
commented
1 year ago J'ai rejoint bat-id en tant que développeur il y a deux semaines.
Bonjour et bienvenu sur le projet !
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.
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.
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é.
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.
@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.
C'est possible oui. Et c'est bien plus confortable de ne taper que des minuscules :)
GT-CNIG-DDU
commented
1 year ago Bonjour, et merci pour ces contributions que je lis avec intérêt ! Juste une question pour @pe-beta au sujet de la mention : "En interne, nous avons une clé primaire classique, en entier auto-incrementé." : En interne à quel système d'informations ? Le GT BATI-ID n'est-il pas en train de construire le modèle...
pe-beta
commented
1 year ago Bonjour @GT-CNIG-DDU, Je parlais du prototype du référentiel que sommes en train de réaliser.
pe-beta
commented
1 year ago @haubourg Tout à fait, l'identifiant sera bien unique.
SylvainBessonneau
commented
1 year ago 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 :
ou est-il prévu de générer l'ensemble aléatoirement ?
Je trouverai intéressant qu'une partie fasse référence à des valeurs réelles mais cela va peut-être en contradiction avec l'idée d'exclure les 0,O, I, L, U.
pe-beta
commented
1 year ago Bonjour @SylvainBessonneau, A ce stade, le choix s'oriente vers un identifiant non signifiant. Il serait généré aléatoirement en suivant les éléments partagés par Félix en début de discussion. Le Compte rendu n°6 du GT Bati évoque ce point avec comme argument principal la robustesse de l'identifiant dans le temps (fusion/division de communes, éventuelles modification des départements ou rares cas de batiment à cheval sur deux communes).
RollandMELET
commented
1 year ago Bonjour à tous Pourquoi la proposition de créer l'information sous forme d'URI ( cf https://github.com/fab-geocommuns/BatID/issues/24#issuecomment-1443449656 n'a pas plus d'écho auprès de ce groupe ? Ce d'autant que comme le mentionne @NicolasPyIGN dans son commentaire cela rendrait conforme le BatID à la réglementation INSPIRE ?
Merci d'avance de vos réponses
Bien à vous
pe-beta
commented
1 year ago Bonjour @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 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.
haubourg
commented
1 year ago 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 https://github.com/fab-geocommuns/BatID/issues/24#issuecomment-1446618818, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAMN5HLEQM4GKOP2OT4UYTLWZTHGRANCNFSM6AAAAAAVF5JPIY . You are receiving this because you were mentioned.Message ID: @.***>
fe51
commented
1 year ago Bonsoir à tous,
Tout d'abord, merci pour vos nombreux retours.
Concernant le sujet de l'URI. On va creuser le sujet, mais quel semble être le critère fondamental, le fait d'avoir un identifiant qui est compatible avec une utilisation dans un URL de telle sorte que l'adresse rnb.data.gouv/BATIMENTRC51 pointe de façon (durable) sur ces informations ?
Concernant la clé de contrôle, c'est un point intéressant à investiguer (il faudrait pouvoir ne pas trop allonger l'identifiant avec cette clef, d'autant plus qu'une vérification avec un alphabet large et une clef pertinente courte n'est peut être pas évidente
Concernant l'alphabet à préconiser, je rejoins sur le fait de ne pas être sensible à la casse :)
RollandMELET
commented
1 year ago @fe51
- Concernant le sujet de l'URI. On va creuser le sujet, mais quel semble être le critère fondamental, le fait d'avoir un identifiant qui est compatible avec une utilisation dans un URL de telle sorte que l'adresse rnb.data.gouv/BATIMENTRC51 pointe de façon (durable) sur ces informations ?
de l'extérieur, un des plus gros problèmes est de savoir où sont les données associées à un ouvrage. C'est un problème général dans toutes les relations Objets / Données associés. le monde des produits de grandes consommations (PGC) va régler le problème en transformant l'identifiant des produits (GTIN EAN13) en pointeur (URI) matérialisé sous forme d'un QR-Code, le tout réglé par un standard ouvert : le Digital Link. Du point de vue du monde de la construction (et de sa maintenance) il est vraiment très intéressant que le Bat ID puisse donner acces à un registre ouvert via une URI ou les divers propriétaires d'un ouvrage puissent enregistrer, ou permettre d'enregistrer, des données utiles à la connaissance ou l'exploitation de l'ouvrage.
NicolasPyIGN
commented
1 year ago Bonjour, Découverte dans mes RSS du jour, sans que je ne les ai creusés: The US Department of Energy created an open-source unique building identifier (UBID) creation technique soit (liens du post stackexchange):
UBID has a simple uniform format and is easily constructible from geospatial information that is available from common web-based mapping services. UBID builds on the open-source grid reference system and is essentially the north axis-aligned "bounding box" of the building's footprint represented as a centroid along with four cardinal extents. Unlike addresses, it is easy to tell with high confidence whether two independently constructed UBIDs actually reference the same building. UBID scales naturally both down (to parts of buildings) and up (to groups of buildings like campuses) and UBIDs obey "containment" — it is easy to tell whether a given building belongs to a given campus based on their UBIDs.
hbs
commented
1 year ago 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 :
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.
hbs
commented
1 year ago _PUmJWYyCGHkz
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.
haubourg
commented
1 year ago 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é! https://buildingid.pnnl.gov/pdf/UBID_Intro_Webinar.pdf
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.
Le rapport final semble dire que la lourdeur de l'outil le rend trop cher pour les petites structures.
Geo-Toulouse
commented
1 year ago 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. Une fusion de commune ou un autre regroupement géographique ne remettrait pas en cause l’unicité de cet identifiant (voir à ce sujet le document DGFIP https://www.collectivites-locales.gouv.fr/sites/default/files/migration/ffs_2020_bati.pdf au chapitre 1.3.2 « Fusion de communes »). Dans le cas d’une requête géographique, il faut expliquer à son concepteur que les attributs de l’objet sont là pour supporter cette requête (code département, code commune ou autre…), et que l’identifiant n’a pas cette vocation.
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. A Toulouse (31555) par exemple où nous avons un stock de 250 000 bâtiments à numéroter et un flux maxi de 1500 PC déposés par an (avec autant de bâtiments à numéroter ?), une chaine de 13 caractères suffirait :
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.
JVURBS
commented
1 year ago 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 :
1) Ce type d'ID peut être lu, écrit, mais surtout retenu et transmis à l'oral facilement par un humain tout en limitant fortement les possibles erreurs lors de la recopie, la mémorisation ou la transmission. En effet, l'ID sera utilisé il me semble au quotidien par des humains (services administratifs, gestionnaires de parc, services de secours, ...). Sinon pourquoi devrait-il pouvoir être lu et écrit. Or si c'est bien le cas il devrait surtout pouvoir être mémorisable et transmissible à l'oral et ce facilement et sans risque d'erreur (notamment si à terme il doit être utilisé par les services de secours).
2) Ce type d’ID n’est pas signifiant
3) Il peut être généré par un usager lambda (sous conditions je reviendrai sur ce point plus bas, l'usager lambda étant forcément un acteur public/une administration selon moi)
4) Il est tout à fait possible d'en générer de manière performante et en grand nombre (idem je reviendrai sur ce point plus bas)
5) On ne réinvente pas la roue
Bien entendu il pourrait y avoir les critiques suivantes :
A) Le risque de collision est élevé. B) Il faut une base centralisée
C'est vrai mais : Pour la collision, pourquoi vouloir générer de manière aléatoire des ID ? Car pour réduire le risque de collision il faut avoir des ID complexes et donc non transmissible ou mémorisable aisément par un humain (encore une fois un humain peut tout lire mais pas tout mémoriser). Et même si la probabilité est faible voir très faible le risque de collision existera toujours (en théorie). PS : les nano ID de type A8YB2 58DEH KAZD1 ou DAPmKFGk24Q2 ne sont pas facile à retenir ni à transmettre (à l'oral du moins)
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.
fe51
commented
1 year ago 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 ?
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é)
--> 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 !
fe51
commented
1 year ago 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.
GT-CNIG-DDU
commented
1 year ago Pour être moins manichéen il manque à mon avis les propositions : "l'ID peut être signifiant" et "sans opinion". Personnellement je voterais "peut être signifiant" car je ne le vois ni comme une obligation, ni comme étant rédhibitoire.
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 [insee]_[millesime]_[increment]
(si besoin le millésime peut être remplacé par une date plus précise)
haubourg
commented
1 year ago C'est pourquoi j'adhère à la proposition de @Geo-Toulouse du type
[insee]_[millesime]_[increment]
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 :=)
LRebours
commented
1 year ago 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. Cet identifiant pourra être échangé / utilisé avec liens avec d'autres informations (commune/adresse, positions, libellés, ...).
A noter que cela est très largement partagé dans la sphère des urbanistes SI.
Voir par exemple de ce document de 2013 :
(on y parlait à l'époque d'URI - mais le sujet Nano-Id me semble un très bon choix)
Geo-Toulouse
commented
1 year ago 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. La coexistence de ces deux systèmes d'identifiants ne devrait pas poser de problème dès lors qu'ils désignent chacun des enregistrements uniques. Et, si problème, il suffirait que l'identifiant local soit nommé "Référence locale" et traité comme un simple attribut à la BDNB.
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 Responsable du Domaine Connaissance du Territoire Toulouse Métropole
fe51
commented
1 year ago 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 :
Un NanoID avec un alphabet customisé, pour former un ID de 12 caractères (faut il envisager d'encore le raccourcir au risque de rencontrer plus régulièrement des collisions ? ). Voir plus haut pour l'argumentaire autour de ce format.
Un ID format "plaque d'immatriculation" de type AB123CD, (plus?) simple à lire, issu d'une génération centralisée. Voir plus haut l'argumentaire proposée par JVURBS.
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 :)
ETV1802
commented
1 year ago 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. Et probablement plus simple à utiliser pour nous (opérateur de réseaux) dans ses règles de gestion.
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."
JVURBS
commented
1 year ago 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 ? Dans le cas du NanoID, le générateur devra (de ma compréhension) être unique ou du moins paramétré de manière identique pour tous les utilisateurs ! Qui garanti cela ? Ou récupérer le générateur ?
MaelREBOUX
commented
1 year ago 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.
haubourg
commented
1 year ago Complètement en phase avec @MaelREBOUX de mon coté.
- UUID ça marchera : pourquoi choisir autre chose ?
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 pense que le NanoID ne souffre pas de ce problème et que l'on va vite le retrouver implémenté par défaut dans la plupart de nos outils
quelques exemples:
# UUID
47a7c633-067b-4323-a130-7abd81bfea2d
4b15f085-d512-48be-8fe8-bce13b48376d
# NanoID
NPWoGLggM5Rxzb
wnDMCZPcxLqaUhJe 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
haubourg
commented
1 year ago Sinon 100% en phase avec @MaelREBOUX
NicolasPyIGN
commented
12 months ago Découverte dans mes RSS du jour, sans que je ne les ai creusés:
haubourg
commented
3 weeks ago @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