___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr
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
Bonjour
- Mail original -
De: "Topographe Fou"
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 (à
écembre 2016 1:30 AMÀ: talk-fr@openstreetmap.orgRépondre à: verd...@wanadoo.fr; talk-fr@openstreetmap.orgObjet: Re: [OSM-talk-fr] Problème de représentation avec des parcelles forestières Je ne vois pas en quoi ce changement de "multipolygon" en "boundary" devrait avoir un impact sur l
Je ne vois pas en quoi ce changement de "multipolygon" en "boundary"
devrait avoir un impact sur l'interprétation et la "remontée" des tags des
ways membres vers les relations qui les référence.
Cela reste un bogue de la conversion OSM en pgsql, qui ne tient pas compte
des critères nécessaires
J'ai basculé ces "type=multipolygon" en "type=boundary"... et tout
rentre dans l'ordre comme je l'avais imaginé dans mon précédent
message qui n'a visiblement pas été lu ;)
Bonjour et merveilleux !! Je n'avais pas compris le sous-entendu. Merci.
En terme de logique de tagging je verrai plutôt
J'ai basculé ces "type=multipolygon" en "type=boundary"... et tout rentre
dans l'ordre comme je l'avais imaginé dans mon précédent message qui n'a
visiblement pas été lu ;)
Ces sections forestières sont bien des frontières et ça évite à osm2pgsql
de chercher à savoir par une euristique imparfaite
Le 05/12/2016 à 21:57, LeTopographeFou - letopographe...@gmail.com a écrit :
Bonsoir à tous,
A vrai dire je croyais que le moteur ne dessinait que les objets issus
d'une requête (donc les objets connus) et pas tous les objets.
Visiblement ce n'est pas le cas.
Jusqu'à peu c'était le cas.
Bonsoir à tous,
Merci pour vos réponses. A l'heure actuelle le rendu est pire encore car
j'ai (à priori) terminé de réparer les mp mal taggés. Et il apparait que
si la précédente carte était plutôt bien dessinée, c'est plus par
"chance" que par la qualité des mp qui existaient. Maintenant
Ceci dit si je prend l'exemple du triangle formé entre les carrefours de la
Réserve, des Grès et de Madame par les trois routes forestières de la
Fresnaye, des Grès et de Madame, il y a bien un attribut highway commun,
mais aucun nom commun.
L'attribut highway est "remonté" au niveau de la
Le rendu ne fait pas cette interprétation tout seul: il ne le fait que si
tous les chemins membres d'une même relation partagent exactement le même
attribut, et dans ce cas il rapporte cet attribut à la relation, et
seulement si cette relation décrit une surface fermée (en un ou plusieurs
anneaux
J'ai regardé dans la base postgres qui sert au rendu FR.
Ce "multipolygone" n'ayant aucun tag connu d'osm2pgsql qui corresponde à
une surface (boundary serait un bon candidat) il s'est vu récupérer le
highway=track avec le nom correspondant.
Ces multipolygones sont un peu anacrhoniques et il y a
Oui, les multipolygones, c'est élégant d'un point de vue intellectuel et
parfois, c'est absolument impraticable dans la réalité. Et impossible à
maintenir. Pour 3 nœuds et trois ways, pourquoi inventer un MP plutôt
qu'utiliser un chemin fermé simple ?
Sinon, je pense (à confirmer) que le rendu
Bonjour,
Suite à mon sujet sur les intersections en forêt j'ai essayé de savoir
pourquoi certaines parcelles et chemins en forêt de Saint-Arnoult (mais
pas que...) génèrent des soucis de dessin alors qu'elles paraissent
toutes homogènes en terme de tags et qu'elles sont toutes fermées.
14 matches
Mail list logo