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
_______________________________________________
Talk-fr mailing list
[email protected]
http://lists.openstreetmap.org/listinfo/talk-fr
