Le 07/12/2016 à 10:06, Topographe Fou a écrit :
Probablement parce que comme l'explique le Wiki un multipolygon est
par défaut une aire (contrairement à boundary qui est une frontière,
quelque chose de linéaire) et que si un tag manque au niveau de la
relation il va le chercher au niveau des membres (là je suis d'accord
avec toi : ce n'est pas normal et pousse à la surinterpretation). Il
donne même un exemple en Allemagne ou des mp ont été massivement
utilisés au lieu de boundary. Un multipolygon est conçu comme une
manière de définir une aire mais en utilisant plusieurs ways au lieu
de une.
Donc comme le rendu ne reconnaît pas cette manière de tagger un
parcelle, il adopte son comportement par défaut qui est "c'est une
aire" et "je cherche les tags d'abord dans la relation, sinon dans
les membres". Avec une boundary il ne dessine pas d'aire donc le
glitche ne se produit pas. Est-ce une magouille ou un " taguer pour le
rendu" ? Je ne sais pas trop encore... Si tu rajoute un tag
landuse=forest à un mp de type parcel, on devrait logiquement arriver
au même résultat et cela ne me paraît pas sémantiquement faux aussi.
Résultat un multipolygon avec que des membres highway est donc vu
comme un highway. Contrairement à ce que j'ai pu dire je ne pense plus
qu'il y ai bug mais reste persuadé qu'il y a une erreur de conception
(à savoir la remontée de tags qui pousse à une mauvaise pratique).
Cordialement
LeTopographeFou
frontière ou surface, ça arrive dans la même table postgres via osm2pgsql...
Ensuite, le rendu se mélange forcément les pinceaux car les données dans
la base osm2pgsql sont incohérentes mais le rendu peut soit remplir les
surfaces des (multi)polygones soit ne tracer que leurs frontières... ce
n'est qu'une question de feuille de style.
Le souci provient à l'origine de l'euristique d'osm2pgsql qui lorsqu'on
utilise un type=multipolygon qui ne fait que décrire le type de
géométrie sans décrire à quoi elle correspond va chercher à la compléter
par l'information sémantique.
Cette euristique n'est pas parfaite... et donc il vaut mieux indiquer
qu'on décrit bien la frontière d'une section (comme on décrit la
frontière d'une commune) avec un type=boundary et du coup osm2pgsql ne
cherche par à découvrir par lui même la sémantique estimant qu'elle est
déjà décrite dans la relation.
On peut voir ça comme un bug d'osm2pgsql, mais le code ne peut pas
toujours deviner l'intention du contributeur... il est préférable
d'expliciter le type et en plus ça me parait cohérent en terme de tags.
--
Christian Quest - OpenStreetMap France
_______________________________________________
Talk-fr mailing list
[email protected]
https://lists.openstreetmap.org/listinfo/talk-fr
