[OSM-talk-fr] Explosion d'un carrefour

[Philippe Verdy]

Le 29 septembre 2013 20:16, Pieren <pieren3 at gmail.com> a écrit :

> 2013/9/29 Philippe Verdy <verdy_p at wanadoo.fr>:
>
> > Mais un multipolygone sans attribut n'a pas de sens: il faut remonter
> ceux
> > de la bordure externe si on veut exclure une zone "inner".
>
> Comme il y a des nouveaux qui nous lisent et qui ne connaissent pas
> encore Philippe (qui est filtré par la plupart des anciens abonnés de
> cette liste), je vais corriger au moins ce point.


Il n'y a rien à corriger du tout. Ce que tu décris ci-dessous est une
"recette de cuisine" faite par l'outil que tu décris, destinée à tenter de
corriger l'erreur, et qui pourtant n'arrive pas clairement à résoudre tous
les problèmes. Notamment sur le fait que cela conduit à créer des doublons
de tags en conflit, et qu'il est impossible alors de savoir lequel est
applicable.

Je maintiens que c'est une erreur de ne pas taguer le multipolygone
lui-même alors qu'il est crée spécifiquement pour créer un "trou" dans la
surface qu'il décrit, et que le tag sur le polygone "outer" oublit d'exlure
la surface des poygones "inner", et de fait ce poygone "outer" ne doit PAS
porter les tags correspondant à la surface **réellement** désignée mais ils
doivent être transférés au multipolygone...



> Il n'y a aucune
> "obligation" à reporter les tags sur la relation multipolygon; ça
> n'est pas une erreur ni une mauvaise pratique. Les multipolygons sont
> interprétés de la manière suivante par le principal outil de
> conversion des données osm en postGIS ([1]):
> - si un multipolygon n'est pas taggué (aucun tag principal), alors on
> prend tous les tags de tous les ways "outer" (mais le processus peut
> foirer si ces tags ont des valeurs différentes (->rejeté)). C'est
> facile lorsquil n'y a qu'un seul way outer (le cas de la plupart des
> multipolygons).
> - si un multipolygon est taggué, c'est uniquement ces tags qui seront
> pris en considération et pas ceux portés par les ways "outer"
> - si les tags d'un way "inner" est diffèrent des tags sur les ways
> "outer" ou ceux de la relation, alors ce way devient un nouveau
> polygone


Cet algo n'en est pas un. Tout cela n'est qu'une heuristique destinée à
tenter de corriger plus ou moins automatiquement certaines anomalies. Alors
qu'il n'y a strictement aucune anomalie ni heuristique à réaliser si on a
les tags sur le multipolygone directement.

Ce serait aussi vrai dans une base GIS si on taguait les "rings" (anneaux)
au lieu des multipolygones (dans une base GIS ce ne sont pas des "ways"
(chemins) qui sont membres, mais des bien des "rings" (autrement dit
uniquement des polygones fermés). Et c'est ce que tente de réaliser le
script de conversion avec plus ou moins de difficultés.

En plus tu te trompes dans la première partie : la conversion ne prend pas
TOUS les tags des chemins membres, mais SEULEMENT ceux qui sont en commun.
Et cela fait une grosse différence car tous les tags ne sont pas à
considérer. Et pourtant cela foire car certains ne devraient pas être
transférés, même s'ils sont communs (sinon cela entraine des conflits, par
exemple quand le multipolygone est créé pour une valeur de "natural=*"
différente de celle des chemins membres, un cas où il est parfois
nécessaire de créer un multipolygone ayant un seul membre).

Normalement seuls les tags du multipolygone devraient suffire, et ceux des
chemins membres ne sont là que pour combler un manque et à condition qu'ils
ne soient pas en conflit entre eux, et pas en conflit non plus avec ceux du
multupogone.

Alors tes approximations sont à metttre en parallèle de mes "prétendues"
erreurs qui n'en sont pas.
-------------- section suivante --------------
Une pièce jointe HTML a été nettoyée...
URL: <http://lists.openstreetmap.org/pipermail/talk-fr/attachments/20130930/3d4ca2a8/attachment.htm>