Bonjour,

> De : "Pieren"
>
> 2013/9/30 Philippe Verdy :
>
> > Je maintiens que c'est une erreur de ne pas taguer le multipolygon lui-même
> > alors qu'il est crée spécifiquement pour créer un "trou" dans la surface
> > qu'il décrit,
>
> Ben, c'est juste un problème de définition. On peut aussi bien dire
> que la relation de type "multipolygon" se contente de décrire une
> géométrie, une surface, avec ou sans trous, et que les tags restent
> sur le way externe. Après tout, cela donne une certaine cohérence avec
> les autres surfaces sans trou. On pourrait aussi dire que la relation
> décrit l'objet dans son ensemble, en plus de sa géométrie. C'est donc
> juste un point de vue et les deux sont acceptables.

Sauf qu'en parlant du "way externe" (au singulier), tu raisonnes sur un cas 
particulier.
Et même si ce cas est largement implémenté, par exemple pour les bâtiments avec 
une cour
intérieur, ça reste un cas particulier.

Le cas général, c'est qu'une relation de type multipolygon a n way pour décrire 
son
contour extérieur, et m ways pour décrire les trous faits dans ce contour. À 
partir de
là, considérer que les tags des n ways (au pluriel) qui forment le contour 
extérieur
doivent permettre de définir les tags du multipolygon, c'est la porte ouverte 
aux
incohérences et à la complexité. Ça demande au logiciel de conversion 
d'interpréter les 
tags de ces ways, de les comparer, de faire son marché dedans pour dire 
le(s)quel(s) sont
à garder, lesquels sont à ignorer. C'est sans comparaison avec une modélisation 
où
le multipolygon est un objet en soi, avec ses géométries membres (ways inners 
et outers)
_et_ avec ses tags en propre. Là, pas d'ambiguïté, pas d'algo compliqué.

Le souci est plutôt dans la pratique, vu que les outils (notamment osm2pgsql) 
cherchent
à exploiter les multipolygons sans tags significatifs, en remontant les tags 
des ways
membres (cf. ton exemple de natural=water à Colmar), manifestement par souci de
retro-compatibilité (ce qui est louable, vive les paradoxes). En cautionnant 
ça, on
n'incite pas à modéliser les multipolygon correctement. À noter qu'à ce jour, 
pour parler
d'un cas répandu chez nous, l'outil de mise à dispo du cadastre vectoriel, pour 
les
bâtiments, utilise des multipolygons sans tag 'building' et taggue en building 
les ways
avec rôle 'outer'. C'est dommage.

vincent

Une messagerie gratuite, garantie à vie et des services en plus, ça vous tente ?
Je crée ma boîte mail www.laposte.net

_______________________________________________
Talk-fr mailing list
[email protected]
https://lists.openstreetmap.org/listinfo/talk-fr

Répondre à