[OSM-talk-fr] Problème insoluble de géométrie.

[Marc Sibert]

Le 04/05/2012 13:29, Philippe Verdy a écrit :
> J'ai un exemple de géométrie pour une commune très complexe (en
> Espagne) pour lequel je ne trouve strictement aucun moyen de le
> résoudre proprement.
>
> Voir ici :
>
> http://analyser.openstreetmap.fr/cgi-bin/index.py?relation=343332
>
> Cette commune n'est pas une erreur ! Elle est effectivement très
> fragmentée, mais le problème est moins le nombre de fragments que le
> fait que certains fragments se touchent uniquement par un seul point,
> dans un coin.
>
> On a le cas suivant apparemment non prévu par OSM (mais prévu dans les
> modèles OpenGIS), ou mal converti par osm2gis :
>
> Le cas concerné est celui-là (simplifié ici):
>
>     +-----+-----+ (noeuds 1, 2, 3)
>     |  A  |  B  |
>     +-----+-----+ (noeuds 4, 5, 6)
>     |  C  |  A  |
>     +-----+-----+ (noeuds 7, 8, 9)
>
> Ici, la commune A possède deux anneaux qui se touchent au point
> central, mais ces anneaux n'ont pas d'autre intersection : la surface
> de l'intersection des zones est nulle. Dans un cas comme ça, il faut
> fermer chaque anneau mais pas moyen non plus d'en faire un seul sauf
> si la zone A en haut à gauche rejoint celle de droite en une seule,
> auquel cas la zone B devient une enclave.
>
> Donc les deux anneaux de A sont tagués en "outer". Et pas moyen de
> joindre le trait descendant du haut vers le centre (à droite de la
> première zone A), avec le trait allant du centre à gauche (sous la
> première zone A), ni le trai joignant la droite au centre puis le
> centre vers le bas, car ces traits qui délimitent une zone A ne
> délimitent pas les mêmes zones externes (B et C). Pas moyen non plus
> de créer une microzone entre les deux zones A pour éviter qu'elles se
> touchent (à quelle commune B ou C faut(il l'attribuer) ?
>
> Normalement, si on dessinait juste des anneaux cela marcherait, mais
> on veut ici unifier les segments frontières sans superposition. Le
> problème est que OSM2GIS ne parvient pas à générer correctement les
> bons anneaux lorsqu'il fait le tri, malgré l'indication correcte ici
> que les 4 anneaux représentés par les 6 ways horizontaux et les 6 ways
> verticaux de cet exemple sont TOUS marqués (correctement !) de type
> "outer", et correctement triés dans les relations A, B et C.
>
> OSM2GIS se trompe et tente de mélanger les ways des deux anneaux
> formant A, et aboutit à un anneau qui s'entrecroise lui-même alors que
> ce n'est pas le cas dans les données OSM. De fait, la cartographie
> obtenue se trompe, omet les deux zones A (qui possèdent en interne
> leurs propres enclaves qui ensuite sont considérées comme faisant
> partie de la surface A, alors que ces enclaves non représetées dans le
> schéma ci-dessus) sont elles-même taguées correctement avec un rôle
> "inner" (il croit que c'est faux et en fait des ways "outer".
>
> Du coup, les libellés affichés dans les enclaves de chaque sous-zone
> de A affichent le libellé de A et non le libellé propre à ces
> enclaves.
>
> OK les ways ne doivent pas se croiser, mais quand ils ont correctement
> ordonnés, et leur intersection se réduit à un seul noeud, et tous les
> noeuds d'un même anneau (tel qu'ordonné dans la base OSM) sont du même
> côté (interne ou externe) de n'importe quel autre way de A, la
> définition est valide.
>
> J"ai cherché différentes solutions de tri des nœuds, de fusion ou non
> de certains traits, et osmose aussi bien que Layers (qui se basent
> tous deux sur les export OSM vers OpenGIS/SQL) se plantent dans les
> deux cas.
>
> Une solution alternative serait de créer les deux zones A de façon
> séparées, en copiant leurs attributs, mais alors les tests
> d'inclusions de points dans une commune échouent selon la zone
> considérée (et il n'y a pas moyen non plus de modéliser une collection
> de zones).
>
> Comment faire ??? C'est la seule commune espagnole pour laquelle je
> n'ai pas réussi à trouver de solution qui marche. On ne parvient donc
> jamais à avoir un rendu correct, aussi bien dans Mapnik, que Osmose,
> Layers, etc...
>
> Pourquoi ne peut-on pas explicitement modéliser dans une même relation
> de type multipolygone que deux sous-zones dessinées par frontières
> forment bien des anneaux physiquement séparés, meˆme s'il se touchent
> par un point de leur bordure) qui ne doivent pas être joints en un
> seul en mélangeant les ways d'un anneau ou de l'autre ? L'outil OSM 2
> GIS ne semble discriminer que les anneaux à partir du moment où ils
> ont des rôles différents (inner ou outer), mais ici le rôle est outer
> dans les deux cas.
>
> Les deux erreurs signalées ici par Osmose n'en sont pas. Les couleurs
> obtenues dans Layers sont incohérentes, de même que les libellés
> affichés dans les enclaves qui sont alors inversées par endroit...
>
> Pour un cas comme ça, il me faudrait un deuxième rôle autre que
> "outer" (par exemple "outer:2" ?) pour marquer les anneaux à garder
> séparés... Le rôle anonyme est ignoré : il est considéré comme
> équivalent à "outer". Ce deuxième rôle n'est pas nécessaire dans le
> cas où les anneaux ne se touchent pas du tout (enclaves et exclaves
> classiques), puisqu'alors il est facile de les séparer.
>
> Ce n'est pas le cas ici, OSM2GIS n'est fait qu'à sa guise et persiste
> en triant les ways et en charchant à les interconnecter de façon
> incorrecte, au point qu'il crée une figure entrecroisée en "8", d'où
> l'erreur !
>
> _______________________________________________
> Talk-fr mailing list
> Talk-fr at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr
Pourquoi ne pas simplement fermer les petites surfaces par des contours 
continus et ne pas "mutualiser" les limites, c'est à dire en faire 
plusieurs.
La modélisation restera juste mais non optimale.

Note : "Quand il n'y a pas de solution... c'est qu'il n'y a pas de 
problème !" (ou qu'il est mal posé). Ici le problème, c'est le code 
d'osm2gis qui ne gère pas correctement le modèle d'OSM. Il faudrait 
poser la question à dev. Je ne vois pas d'utilité à remettre en cause le 
modèle OSM.

-- 
Marc Sibert
mailto:marc at sibert.fr