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

<br>
-- <br>
Marc Sibert<br>
mailto:<a href="mailto:marc@sibert.fr" target="_blank">marc@sibert.fr</a><br>
<br>
<br>
______________________________<u></u>_________________<br>
Talk-fr mailing list<br>
<a href="mailto:Talk-fr@openstreetmap.org" target="_blank">Talk-fr@openstreetmap.org</a><br>
<a href="http://lists.openstreetmap.org/listinfo/talk-fr" target="_blank">http://lists.openstreetmap.<u></u>org/listinfo/talk-fr</a><br>
</font></span></blockquote></div><br><br clear="all"><br>-- <br>--------------------------------------------------------------------<br>Arnaud Van De Casteele<br>Mines Paris Tech - CRC<br>Sophia-Antipolis<br>0698 24 25 29<br>
SIG - WebMapping - Spatial Ontology - GeoCollaboration<br><br>Web Site<br><a href="http://perso.crc.mines-paristech.fr/%7Earnaud.van_de_casteele/" target="_blank">http://perso.crc.mines-paristech.fr/~arnaud.van_de_casteele/</a><br>
<a href="http://geotribu.net/" target="_blank">http://geotribu.net/</a><br><a href="http://www.i2c.eu/" target="_blank">http://www.i2c.eu/</a><br>