Salut à tous,
Je comprends qu'il est plus simple et moins encombrant pour la base de données
de mêler le tag barrier=* avec la surface utilisée comme parking, mais ça reste
quelque peu incohérent pour moi, car on mélange les sémantiques pour un même
objet qui, une fois est interprété comme un way, une autre fois est interprété
comme une area (quelle est la valeur implicite de la clé non fournie "area" ?).
C'est comme mélanger un disque et un cercle : l'un est plein, l'autre n'est que
périphérique.
Comment voulez-vous par la suite attribuer des propriétés à l'un sans que
l'autre ne soit concerné ? Par exemple electrified=yes : est-ce que la surface
du parking est électrifiée ? Si on doit placer un tag généraliste comme, disons
un hypothétique color=*, à qui celui-ci s'appliquerait-il ?
Sans aller jusqu'aux surfaces, il a déjà été conclu que les railway=* et les
highway=* devaient être sur des ways différents, justement parce que les
confusions peuvent survenir dans les tags.
Dans un autre ordre d'idées, certains tags ont besoin d'un area=yes pour
exprimer une surface plutôt qu'un way : citons railway=platform, mais aussi
tous les highway=*. Alors, tous les tags qui y sont accolés devront aussi être
interprétés avec area=yes.
De mon point de vue, dans notre base de données géographique (nous ne nous
limitons pas aux cartes il me semble, même s'il s'agit du principal objectif),
on devrait décrire des objets avec leurs propriétés :
- quelle est la nature de cet objet (route, building, barrière, étendue d'eau,
etc.) avec l'aide éventuelle de plusieurs tags ;
- quelles sont les propriétés de cet objet (en termes d'accès, de propriété, de
forme, d'altitude, etc.) avec autant de tags qu'on veut.
C'est simple et logique.
Une barrière n'est pas un parking, une barrière n'est pas une sorte de parking,
et un parking n'est pas une sorte de barrière. Un parking peut être entouré
d'une barrière, mais dans ce cas on utilise un tag approprié. Si on mélange les
objets et leurs propriétés, on perd une importante logique descriptive pour en
faire un inventaire à la Prévert, où seule une interprétation méticuleuse des
éléments (triés "à la main") permet de comprendre ce qu'il en est.
Teuxe
PS. Je n'ai rien compris quant à l'utilisation de relations pour taguer un
parking entouré d'une barrière.
----- Mail original -----
De: "Philippe Verdy" <verd...@wanadoo.fr>
À: "Discussions sur OSM en français" <talk-fr@openstreetmap.org>
Envoyé: Vendredi 12 Octobre 2012 10:59:29
Objet: Re: [OSM-talk-fr] parking entouré d'une barrière
Le 11 octobre 2012 14:17, <te...@free.fr> a écrit :
> On peut se dire que le way fermé ("area") représente une surface qui sert de
> parking ; à l'opposé, la barrière, même si elle couvre tout le périmètre du
> parking, n'en reste pas moins un linéaire et n'est pas une surface : n'étant
> pas de même nature, on ne peut pas associer les deux au même "objet".
Pas dans un même way, mais la surface fermer peut devenir une relation
avec se attributs propres, mais dont les membres sont les ways
linéaires ayant leurs propres tags. Ce qui évite de superposer les
ways ouverts des clôtures et barrières et un way fermé dessus, voire
aussi de dupliquer les noeuds ou de les intercaler le long du même
tracé quasi superposé sur une grande longueur (où les traits ne
cessent de se recouper aléatoirement alors que les tracés n'ont pas de
raison partioculière de s'écarter l'un de l'autre).
Donc on transforme dans ce cas un way fermé en multipolygone (c'est le
multipolygone qui portera les attributs de la surface, plus le way
fermé inclus comme membre du multipolygone) avant de le découper, et
on fusionne les chemins linéaires communs : il ne reste alors que le
chemin linéaire et non fermé de la cloture, et celui de la barrière,
les deux utilisés en membres du multipolygone pour la surface fermée
du parking.
_______________________________________________
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr
_______________________________________________
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr
