[OSM-talk-fr] Comment tagger un bâtiment composé de plusieurs morceaux ?

[Denis]

Matthias Dietrich a écrit :
> Bonjour,

Bonsoir Matthias,

Merci de démontrer que les nouveaux venus peuvent passer entre les 
gouttes de l'averse du fonctionnement de la liste et rester concentré 
sur le fonctionnement de (la) base.
> 
> Lorsqu'on regarde le cadastre, on se rend compte que de nombreux 
> bâtiments sont composés de plusieurs parties, pouvant être de 
> différentes hauteurs, avec ou sans murs, etc. Avant on pouvait être 
> tenté de ne tracer que le contour général, mais avec l'arrivée du script 
> d'import semi-automatique, on récupère directement un assemblage parfois 
> complexe de ways.
> Un exemple typique : une église, qui sera composée d'une nef, transepts, 
> chapelles latérales plus basses, clochers, sacristie, etc.

L'import "semi-automatique" (qu'il porte bien ce nom) du cadastre ne 
fait que reproduire l'existant. Parfois cela a du sens (hauteurs 
différentes supposées, distinction dur-léger), parfois non (bâtiment 
coupé artificiellement par une parcelle).
Distinguer le bon grain de l'ivraie relève du sacerdoce.
A titre personnel, j'essaie de le faire, mais ce n'est pas ce que je 
recommanderai pour un novice car cela nécessite une certaine expérience 
des données cadastrales, de ses règles, de ses limites/contraintes. Ce 
n'est pas pour frimer, juste l'odeur du cambouis.
Le cadastre n'est pas réaliste ; il n'est pas (toujours) faux non plus.
> 
> Si je garde l'exemple de l'église, comment peut-on tagger l'ensemble ?
> 
> 1. On marque tous les ways en "amenity=place_of_worship". Dans ce cas on 
> multiplie l'information, ça ne me paraît pas vraiment être la bonne 
> façon de faire.
> 2. On fusionne tous les morceaux et on n'a donc plus qu'un seul way à 
> marquer. Inconvénient : on perd de l'information sur la structure du 
> bâtiment, mais certains se réjouiront de voir le nombre de nœuds baisser ;-)
> 3. Une relation sur l'ensemble des ways ? Dans ce cas, de quel type ? 
> J'ai bien trouvé la trace d'une proposition qui allait dans ce sens 
> (http://wiki.openstreetmap.org/wiki/Relations/Proposed/Buildings) mais 
> certains semblent plutôt préférer une relation "site", même si je ne 
> suis pas complètement d'accord avec ça (j'imagine plutôt une relation 
> site contenant éventuellement des relations "building" qui elle-même 
> contiennent les différents "morceaux" d'un bâtiment). Il resterait bien 
> l'idée de faire une relation "multipolygon", mais je ne trouverais pas 
> très logique de mettre en "outer" un morceaux situé à l'intérieur du 
> bâtiment ...

La question première à se poser est : qu'est-ce qui donne du (bon) sens 
à la base ?
Qu'apporte comme plus-value une relation sur ton église par rapport au 
fait de ne taguer que le bâtiment principal (appelons "nef" pour faire 
simple) en "amenity=place_of_worship" ? Reste la question du toponyme : 
je l'ai résolu en ne placant qu'un name sur la "plus grosse partie" (le 
reste des éléments juste en "amenity=place_of_worship" et tant pis pour 
l'optimisation de la base. Restons réalistes sur les priorités et enjeux 
d'OSM dans les 2-3 prochaines années (après on peut discuter de 
raffinement ; sera-ce du raffinage ?)

Comme j'ai déjà eu l'occasion de le dire ici : nous ne pouvons pas 
prévoir tous les usages qui seront fait de la base OSM. En tentant de 
les anticiper (la relation a la cote), nous les briderons peut-être.

Je m'empresse de me contre-dire car j'ai eu une demande concernant des 
corps de ferme sous forme d'objet unique (ça sent la relation à plein 
nez ;-). Cette demande émanait de professionnels pointus (doit-on en 
rester au gourdin ?). Ma pirouette préférée est de dire : OSM est une 
base libre ; just do it.

Bref, dans le monde libre, le plus dur est de faire le bon choix entre 
investissement/contraintes et besoins/plaisir.

Denis