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@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
