Identifiant unique sur les bâtiments

[aducos]

Je remarque que dans les fichiers bâtiments, il n'y a pas d'identifiants uniques dans les geojson.

Le soucis c'est que si nous voulons mettre à jour les bâtiments dans notre base de donnée, nous devons donc tout effacer puis réimporter, plutôt que juste mettre à jour ce qui a changé.

Et donc si on ajoute des données dans notre base pour un bâtiment défini, ces données seront perdues à chaque import.

Il faudrait une clé unique immutable comme il y a pour les parcelles, ou les communes.

Il pourrait être intéréssant de récupérer ces données (code insee + prefixe section + code section + numero de plan + numero_batiment). Ou tout autre clé unique qui ne bougera pas.

[jdesboeufs]

Bonjour,

Hélas cette information n'est pas présente dans les fichiers fournis sous licence ouverte par la DGFiP, nous ne pouvons donc pas la proposer dans nos fichiers retravaillés.

Nous pourrions néanmoins construire un identifiant stable à partir de la géométrie du bâtiment, mais à chaque changement de géométrie (agrandissement, ajustement) le bâtiment aurait un nouvel identifiant. Qu'en pensez-vous ?

[aducos]

J'avais pensé à la même chose faire un md5 sur la géométrie par exemple mais ça change l'identifiant à chaque changement de géométrie ce n'est donc pas l'idéal.

Si il n'y a pas de possibilité d'avoir un vrai ID, je ne pense pas qu'il y ait un intérêt à le faire de votre côté.

[aducos]

Il y a peut-être un moyen de retrouver l'ancien polygone via une intersection sur le nouveau polygone même si le polygone change.

Entre 2 mises à jour, le nouveau bâtiment qui partage le plus de superficie avec l'ancien bâtiment devrait correspondre au même bâtiment et donc au même id, et ce même si le dessin change.

[manuamador]

La bd parcellaire fait un lien entre le bâti et la parcelle non bâtie. Comment font-ils par analyse géométrique ? Ou bien par l’usage des donnees Majic et des invariants/numéro de parcelles ? En tout cas une information existe et son existence ne gêne pas. On pourrait imaginer une clé parcelle non bâtiie_numerodebatiment on pourrait rêver et avoir une clé numéro de parcelle_invariant_pev et pouvoir cliquer sur les bâtiments d’une carte directement...

[jdesboeufs]

L'utilisation des invariants de MAJIC est possible en effet, mais il faut s'assurer de comment ce dernier évolue dans le temps.

[manuamador]

Je pense que les invariants_partieevaluée doivent évoluer comme les parcelles. Dans les données Majic invariant et parcelle sont reliés. Puis partir évaluée et invariant le sont aussi. Ce serait un vrai plus de pouvoir cliquer sur un bâtiment dans une carte.

[aducos]

Si ces invariants évoluent comme les parcelles (au moment des remembrements) alors c'est parfait.

[jdesboeufs]

En fait les invariants concernant les locaux, pas les bâtiments. Pour une adresse donnée on a des compléments d'adresse : BAT 1, BAT 2 etc. Mais aucun moyen d'identifier le bâtiment en question sur le plan.

[manuamador]

Effectivemment, mais le numéro de bâtiment, d'accès et de local sont dans les données MAJIC... DNUBAT, DESC DPORT je crois. Je ne mesure pas l'effort à faire pour faire sortir ces informations des données MAJIC. J'imagine que c'est un peu comme faire un casse à Fort Knox ?

[jdesboeufs]

Oui c'est bien ceux là. Mais rien ne permet de dire que tel rectangle est le BAT 1 etc.

[jdesboeufs]

Toujours pas de solution acceptable, donc on repousse.

[PierreNansot]

Est-ce que un id composé par les coordonnées du centroid serait envisageable ?

[jdesboeufs]

On pourrait en effet, mais je vois au moins deux limites :

• deux bâtiments imbriqués peuvent avoir le même centroïde
• si un bâtiment est modifié, l'identifiant change

Pour plus de fiabilité il faudrait prendre les coordonnées sources, et là aussi on peut avoir des chevauchements.

Si on est prêt à accepter ces fragilités, allons-y !

[PierreNansot]

On pourrait en effet, mais je vois au moins deux limites :

* deux bâtiments imbriqués peuvent avoir le même centroïde

Effectivement, il y a ce risque. Il faudrait calculer un centroid dans le polygon obligatoirement.

* si un bâtiment est modifié, l'identifiant change

Ca me choque pas plus que ça. Quand une parcelle cadastrale est modifiée, on lui réattribue un nouveau numéro.

Pour plus de fiabilité il faudrait prendre les coordonnées sources, et là aussi on peut avoir des chevauchements.

Si on est prêt à accepter ces fragilités, allons-y !

Pour réduire la taille de l'id, on peut aussi envisager de soustraire la latitude minimal du territoire français à la latitude du centroid du batiment. Pareil pour la longitude.

[jdesboeufs]

On va donc partir sur un algo maison (mais documenté). Par cohérence je pensais préfixer ces identifiants par l'identifiant de section : CCCCCPPPSSB...B C'est un peu long, et ça induira des changements lors des remaniements ou fusions de commune. Un avis ?

[ChristopheVergon]

Bonjour, Le plus simple est d'utiliser le champ IDU de l'objet subsection et de le préfixer par code département (char[2]) et code commune (char[3]). Pour ce qui est des changements en cas de fusion d'une manière ou d'une autre le codage utilisé (code commune + code commune fusionné) arrive à sa limite. Si la commune A fusionne avec la commune B, nous avons pour la nouvelle commune : code de B + code de A et code de B + "000" ce qui permet de distinguer deux sections de même nom dans la nouvelle commune. Maintenant cette nouvelle commune fusionne avec une commune issue de la fusion de C et D, là on fait comment ? Pour ce qui est du remaniement et remembrement comme la nature géométrique des parcelles, des sections, changent il n'y a pas moyen de faire une correspondance autrement que par fonctions spatiales.

Nous avons solutionné le problème des fusions en attribuant un identifiant numérique unique aux communes (Primary Key) ce qui permet de rendre indépendant le modèle relationnel des attributs. La commune A de PK=1 (idcommune :: integer) qu'elle change de nom, de code insee ou de ce qu'on veut reste la commune d'Id= 1.

[rbonnefoi]

Bonjour,

Je me permets de remonter le sujet en haut de la pile : je suis également intéressé par un identifiant unique stable des bâtiments. Je ne sais pas si les développements récents de la base BDNB (base nationale des bâtiments) permettent de simplifier ou unifier les approches.

Et je comprends les états d'âmes sur la permanence relative (en fonction des évolutions apportées) mais je me dis qu'une permanence, même imparfaite, est toujours mieux qu'aucune permanence.

Quoi qu'il en soit, merci pour le boulot sur l'unification des données cadastrales.