[OSM-talk-fr] Problème de représentation avec des parcelles forestières

[Christian Quest]

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

-------------- section suivante --------------
Une pièce jointe HTML a été nettoyée...
URL: <http://lists.openstreetmap.org/pipermail/talk-fr/attachments/20161207/29f80213/attachment.htm>