Garder deux niveaux de description immeuble > batiment

[haubourg]

Suite au groupe CNIG, je reprend en détail la raison de notre souhait de garder deux niveaux d’emboîtement possibles.

Sur cette image qui représente pour moi le cas nominal de la construction collective:

L'immeuble est l'ensemble constructif cohérent, sur lequel portait le permis de construire.
Les trois entrées correspondent à trois batiments fiscaux DGFIP (et on a les compteurs ENEDIS / arrivées de réseaux ) sur ces trois points.
L'immeuble est géré par un seul syndic, et a des parties communes (parkings et garages couverts à droite de l'image).

Les murs porteurs ne sont connus d'aucune base de données nationale.
Cet immeuble a une seule adresse BAN, et des boites au lettres dans les trois cages d'escaliers.

On ne sait raccrocher des données DPE ou autre base annexes qu'à l'immeuble pour l'instant. Et on ne sait pas sur le stock positionner le découpage des murs porteurs depuis les photos aériennes. Donc on saura initialiser un stock d'immeubles depuis la BDtopo / fichiers fonciers, On saura qu'on a trois batiments d'après les données DGIFP, mais tant qu'on aura pas positionné les trois portes d'entrées, on aura pas la capacité à positionner ces trois batiments.

Mon point est que sans ce niveau de construction, on ne pourra pas vraiment initialiser un stock.

Dans la BDNB, nous avons un modèle à trois niveaux de superpositions,

• le groupe de batiment = tous les batiments d'une même parcelle unifiée. C'est ce niveau qu'on arrive à reconstituer le mieux pour l'instant
• la construction = ensemble continu issu d'une même méthode de construction et sur une même parcelle (ce serait notre immeuble)
• le batiment fiscal = la cage d'escalier comme point d'entrée et les murs porteurs qui délimitent la circulation autour.

Avec ce modèle, on arrive à faire circuler des informations des différentes sources externes. Si on enlève ce niveau d'immeuble dans le référentiel, on ne saura pas distinguer deux ensembles constructifs qui sont juste géographiquement collés.

Oui c'est plus compliqué en acquisition, mais ça permet de gérer un stock incertain sans portes d'entrées connues.

cc @fe51

[LRebours]

Petites réactions :

1. Nos travaux de définition - et son annexe en particulier- précise bien une ambition sur ce qui nous motiverait pour faire 1 ou plusieurs bâtiments.
   Dans le cas de cette photo : il me semble qu'il manque l'hypothèse de savoir si on peut circuler dans toute la barre ou non en interne.
2. la problématique du regroupement "de bâtiments" dépend des métiers (on donne ici 2 exemples - qui sont en gigogne mais pourraient ne pas l'être toujours avec tous les cas particuliers de chaque métier). J'avais compris qu'on ne voulait pas aborder ce type d'objet dans les travaux de référentiel commun (dans un premier temps ?). En tout cas, il faut surtout qu'on s'allerte si on pense que vouloir introduire un(des) objet() regroupants() (maintenant ou plus tard) ne provoque pas des échanges sur la définition du Bâtiment lui même...
3. Il me semble important de ne pas s'appuyer sur des notions "d'avoir une ou plusieurs entrées" pour nos discussions : tous les cas sont possibles ! Et le fait d'avoir 1 adresse BAN ou plusieurs n'est en rien qualifiant non plus : toutes les résidences privées closes (au sens territoire) ne seront pas adressées bâtiment/entrée par bâtiment/entrée.
4. Concernant l'initialisation d'un stock de bâtiment (et des entrées) : je comprends les craintes. Mais ce n'est pas en gérant d'autres notions que cela clarifiera forcément : il faut avant tout prévoir qu'on aura des erreurs / des corrections d'inventaire (on aura peut-être identifié un immeuble qu'on identifiera plus tard finalement comme plusieurs). Dans ce cas, il faudra surtout s'attacher à voir ce qu'on fait pour tracer ces corrections d'inventaires (la relation d'historique esquissée dans le modèle).
   (Et on peut déjà prévoir des discussions sur le fait de savoir si dans ce cas on "fermera" l'id initial pour créer 3 nouveaux ou si on garde l'initial en considérant que ce n'est qu'une partie + ajouter 2 nouveaux.... L'important sera de savoir ce qu'on veut avoir comme info sur ces évolutions et la manière de les capter (saisie ou détection SI ?).

[GT-CNIG-DDU]

Si je comprends assez facilement le besoin de garder deux niveaux de description : immeuble et bâtiment, je suis gêné par le fait que, dans le langage courant, ces deux termes sont tout à fait synonymes pour le grand public.
En gardant immeuble pour l'entité englobante (mais bâtiment peut également être un bon candidat => à étudier / débattre), il me semblerait préférable d'adopter pour le deuxième niveau des termes comme :

• partie d'immeuble (terme neutre du point de vue schéma conceptuel de données)
• bâtiment fiscal (terme suffisamment différenciateur, et semblant assez justement employé ci-dessus)
• montée d'escalier (certainement pas le meilleur candidat sur le plan conceptuel... mais correspondant au langage courant)

[haubourg]

@GT-CNIG-DDU

Si je comprends assez facilement le besoin de garder deux niveaux de description : immeuble et bâtiment, je suis gêné par le fait que, dans le langage courant, ces deux termes sont tout à fait synonymes pour le grand public.

On est face à un objet métier fractal. ça me rappelle les travaux de normalisation des zones humides du Sandre. On pourrait aussi dire qu'un bâtiment est potentiellement inclus dans un autre. Mais ça donne des modèles de données génériques récursifs durs à exploiter et qui aboutissent à ne pas vraiment chercher à normaliser les représentations d'objets. Et au final les bases de données deviennent hétérogènes.

• bâtiment fiscal (terme suffisamment différenciateur, et semblant assez justement employé ci-dessus)

• montée d'escalier (certainement pas le meilleur candidat sur le plan conceptuel... mais correspondant au langage courant)

ces deux là sont identiques dans ma compréhension, mais je ne connais pas les raffinements MAJIC suffisamment bien.

partie d'immeuble (terme neutre du point de vue schéma conceptuel de données)

Dans le cas des maisons individuelles, le terme ne fonctionne pas.

[haubourg]

@LRebours

Dans le cas de cette photo : il me semble qu'il manque l'hypothèse de savoir si on peut circuler dans toute la barre ou non en interne.

Je confirme que non, on ne peut pas circuler entre batiments dans ce cas.

2. a problématique du regroupement "de bâtiments" dépend des métiers (on donne ici 2 exemples - qui sont en gigogne mais pourraient ne pas l'être toujours avec tous les cas particuliers de chaque métier). J'avais compris qu'on ne voulait pas aborder ce type d'objet dans les travaux de référentiel commun (dans un premier temps ?). En tout cas, il faut surtout qu'on s'allerte si on pense que vouloir introduire un(des) objet() regroupants() (maintenant ou plus tard) ne provoque pas des échanges sur la définition du Bâtiment lui même...

C'est vrai. La vision thématique pourrait aboutir à des définitions de regroupements différents si on parle de chaufferie commune, de compteurs communs. Ma proposition serait de s'intéresser uniquement au système constructif, c'est assez objectif je pense.

Le risque est en retour de ne pas savoir répondre à des questions de cohérence du système constructif, que l'on peut attraper au dépôt du permis de construire. On peut imaginer faire des regroupements par date de construction , code parcelle et contiguité topologique pour essayer de reconstituer cette information. Mais ce serait probabiliste.

Il me semble important de ne pas s'appuyer sur des notions "d'avoir une ou plusieurs entrées" pour nos discussions : tous les cas sont possibles

Il me semblait qu'une entrée était le minimum pour qualifier l'existence d'un bâtiment. (c'est le cas du modèle suisse). Une entrée ne veut pas forcément dire une adresse BAN en effet. Ce serait bien d'inciter fortement dans le process de création, mais oui, on devra vivre longtemps avec des endroits sans adresse BAN. Le modèle doit l'autoriser clairement.
Si on raisonne en terme d'interface de saisie, la création d'objet bâtiment au stade de projet pourrait très bien se faire un posant un point de la future entrée supposée et ça suffirait à créer un identifiant. Cela correspond aussi un peu à l'exercice du RIL, et permettrait de plus se focaliser sur un objet simple à identifier en masse, y compris sur le stock existant. Et bonus, on pourrait imaginer que la reprise du stock soit collaborative en lien avec OSM avec des initiatives comme https://every-door.app/ .

4. Concernant l'initialisation d'un stock de bâtiment (et des entrées) : je comprends les craintes. Mais ce n'est pas en gérant d'autres notions que cela clarifiera forcément : il faut avant tout prévoir qu'on aura des erreurs / des corrections d'inventaire (on aura peut-être identifié un immeuble qu'on identifiera plus tard finalement comme plusieurs). Dans ce cas, il faudra surtout s'attacher à voir ce qu'on fait pour tracer ces corrections d'inventaires (la relation d'historique esquissée dans le modèle).

+1

[Geo-Toulouse]

Bonjour,

Je suis aussi partisan de distinguer les deux niveaux constructifs des Immeubles et des Bâtiments :

Le niveau « Immeuble » (= ensemble constructif qui regroupe de 1 à N bâtiments) nous permettra d’initialiser plus facilement la base par la reprise du stock des objets du cadastre ou de la BDTopo qui sont déjà définis sur ce niveau de représentation. A noter aussi que les dimensions périmétriques de l’immeuble seront d’une précision homogène alors que celles des bâtiments qui le composent seront très incertaines.

D'un point de vue réglementaire, un permis de construire se rattache à la "construction existante" dans son ensemble quand elle existe et non pas à l’une de ses subdivisions en bâtiment. La notion d'immeuble serait surement très utile pour faciliter la modélisation de la base et assurer la mise à jour du flux.

Pour la gestion courante, beaucoup de données se rattachent à l’immeuble plutôt qu’à ses subdivisions en bâtiments. Outre les DPE, la plupart des diagnostics obligatoires (thermites, amiante, plomb…), de même que la qualification des risques (sécurité incendie, inondation, immeubles menaçant ruine…), les nuisances, les aides à la rénovation (ravalements de façades..), les servitudes, le social (RPLS, copropriétés en difficultés)…

La séparation de l’immeuble en « Bâtiments » reste néanmoins nécessaire, mais elle est difficile à tracer graphiquement. Peut-être que cette représentation des bâtiments pourrait se faire sous la forme de points seulement ? Les points du RIL pourraient effectivement nous y aider quand le RIL existe (seulement pour les communes de plus de 10.000 habitants). Il faudrait pour cela créer autant de points que d'"Entités Adressées" et venir les positionner dans les bons immeubles…
Ce travail d'appariement est laborieux à faire. C'est la solution que nous avons retenue en expérimentation à Toulouse, avec l'ambition de tracer ensuite les périmètres des bâtiments en subdivisant chaque immeuble au prorata du nombre des Entités adressées qu'il contient.

Georges Monnot
Responsable du Domaine Connaissance du Territoire
Toulouse Métropole