« S'*il n'y a pas de solution*, *c'est qu*'*il n'y a pas de problème*. »
Devise des Shadoks ! 2012/5/4 Marc Sibert <m...@sibert.fr> > 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<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@openstreetmap.org >> http://lists.openstreetmap.**org/listinfo/talk-fr<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:m...@sibert.fr > > > ______________________________**_________________ > Talk-fr mailing list > Talk-fr@openstreetmap.org > http://lists.openstreetmap.**org/listinfo/talk-fr<http://lists.openstreetmap.org/listinfo/talk-fr> > -- -------------------------------------------------------------------- Arnaud Van De Casteele Mines Paris Tech - CRC Sophia-Antipolis 0698 24 25 29 SIG - WebMapping - Spatial Ontology - GeoCollaboration Web Site http://perso.crc.mines-paristech.fr/~arnaud.van_de_casteele/ http://geotribu.net/ http://www.i2c.eu/
_______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
