Le 4 mai 2012 19:24, sly (sylvain letuffe) <li...@letuffe.org> a écrit : > En cherchant, on fini par tomber sur l'information concernant ce standard qui > dit : > "2. The Boundaries of any 2 Polygons that are elements of a > MultiPolygon may not ‘cross’ and may touch > at only a finite number of points." > > Donc, ne change rien, ce que tu as fais est bon conformément à ce que dit le > wiki.
Justement je démontre ici que ce n'est pas vrai. Et qu'en fait la relation de type multipolygon ne permet pas de représenter correctement deux "rings" dans la même relation qui se touchent même un un seul point, malgré le fait de les trier correctement et que OSM stocke ce tri, justement parce qu'ensuite l'outil de conversion ne tient absolument pas compte du tri stocké, et systématiquement cherche à trier les ways et les connecter comme bon lui semble : Il y a ici 4 ways qui se connectent au même nœud, la conversion OSM vers OpenGIS cherche à trier les ways en les associant par paire dans un ordre imprévisible. Il va donc prendre la première paire de ways qui se présente qui a un noeud commun, même si ça génère alors deux chemins qui se croisent (alors qu'ils ne se croisent pas, mais ne font que se toucher, si les bonnes paires de way à connecter sont sélectionnées). En faisant ça au passage, il semble même ignorer totalement les rôles inner et outer des ways pour les calculer lui-même à la place. en fonction du résultat de ce tri qu'il fait lui-même. Plus que les rôles inner/outer (qui sont ignorés) il serait préférable de pouvoir labelliser les rôles avec le numéros ou noms symboliques d'anneaux fermés distincts quand ils doivent être clairement distingués dans les tris de ways. > "Generally, the multipolygon relation can be used to build multipolygons in > compliance with the OGC Simple Feature standard > (http://www.opengeospatial.org/standards/sfs)." Je démontre que OSM ne supporte toujours pas correctement l'OGC Simple Feature standard. Note : les ways dans OSM forment une liste ordonnée de noeuds. L'orientation des ways joue un rôle puisqu'alors la conversion des relations OSM vers des 'rings' OpenGIS doit déterminer leur orientation et renverser des listes de noeuds selon le noeud par lequel un way est connecté à un autre (ce n'est pas toujours le dernier noeud du way précédent avec le premier du way suivant (ce n'est vrai que dans la moitié des cas pour les boundaries, car en formant les anneaux (rings), il faudra toujours orienter les ways de deux anneaux qui se touchent en sens contraire (dans OGC, les anneaux fermés sont tous orientés dans le sens antihoraire). Bref la conversion OSM vers OpenGIS ne peut pas se passer de réorienter les ways, mais pourquoi doit-elle obligatoirement aussi trier les ways entre eux, et pourquoi ignore-t-elle systématiquement l'ordre relatif des ways dans une relation de type=multipolygon ? Cela casse les anneaux fermés et introduit des chemins qui forment des "8", donc des croisements, dès qu'une paire d'anneaux se touche par un seul noeud. Note aussi : si deux anneaux se touchent par 2 noeuds ou plus, on n'a pas ce problème puisqu'alors il est possible de reféfinir la forme par un contour fermé externe (outer) et un autre contour fermé interne (inner). Ce n'est pas possible si l'intersection se réduit à un seul noeud. Pour l'instant j'ai du créer des microzones en remplaçant deux noeuds distincts à problèmes correspondant à deux paires d'anneaux externes qui se touchent en ces deux noeuds, par 2 paires de 4 noeuds (pour préserver la direction des traits avant et après ces noeuds. J'ai mis une note sur les 2 fois 4 noeuds en demandant à ne pas les fusionner pour l'instant (ils sont distants d'environ 10 centimètres dans chaque groupe de 4, où il forment un carré centré leur ancien noeud commun, c'est invisible dans les rendus actuels qui limitent le zoom; on ne peut pas mettre moins de 10 centimètres, sinon les outils OSM ont des limites de précision et finissent par confondre ces noeuds malgré tout, et cela ne résoud rien). Nulle part ailleurs en Espagne que dans la municipalité de Xativa (pour ses deux petites exclaves qui touchent la zone principale, et dont j'ai vérifié l'existence effective dans le Cadastro espagnol) je n'ai pas eu besoin de ce "truc" immonde qui consiste à fausser un peu la géométrie. D'où les tags "note" que j'ai mis maintenant, après divers essais jusqu'à ce que ça "marche". Cependant, le "truc immonde" ici se présente dans une partie du Cadastro espagnol où l'imprécision précision des points est largement supérieure aux 10 centimètres (il suffit de voir le tracé des voies, et les différences liées aux superpositions imprécises entre les planches des diverses municipalités en présence, ce qui entraine des frontières "en double" très visibles et mal alignées). Cette légère modification de géométrie n'entraîne donc pas de différence significative avec le cadastre puisque cela survient justement aux limites imprécises de séparation des municipalités, là où le cadastre n'assure pas de superposition correcte et corrigée, bien que les municipalités ici soient supposées toutes numérisées dans le même référentiel ED50/UTM30. Cette modification est donc similaire aux effets des corrections de "conflation" effectuées ailleurs dans OSM pour joindre les planches cadastrales distinctes de nos communes françaises (qui ont le même problème). Malgré tout : Les outils de conversion OSM vers OpenGIS supposent tous qu'il ne peut y avoir que deux ways d'une même relation se connectant en un même noeud. Il n'y a pas de modélisation OSM supportée et stable géométriquement permettant de représenter des surfaces faites d'anneaux fermés et dont l'intersection se réduit à des nœuds isolés de leur contour. OSM n'est donc PAS actuellement totalement conforme avec le modèle OGC Simple Feature. On doit y pallier par des "bidouilles" dont il est difficile de prévoir la stabilité (d'autant plus que cela dépend aussi de la précision de calcul de nos outils de conversion ou d'analyse des géométries), et qui compliquent aussi la tâche pour l'édition : le résultat est difficile à prévoir. Le modèle OSM en revanche supporte le fait que leur intersection puisse être des segments de longueur non nulle (et dans ce cas la conversion élimine ces segments communs deux à deux et ça marche bien pour gérer les frontières communes de zones limitrophes, la conversion vers OpenGIS produira les anneaux fermés corrects et joindra d'elle-même ces zones limitrophes dans un même anneau). La solution est simple: qu'OSM permette de distinguer les rôles pour des anneaux fermés distincts, et que les outils tiennent compte de ces étiquettes distincts dans les rôles, pour éviter d'associer dans les chemins fermés reconstruits les mauvaises paires de ways (quand il y en a plus de 2 connectés à un même nœud terminal). On devrait en revanche pouvoir se passer du sens donné aux rôles "inner" ou "outer" (dont il n'est actuellement plus tenu compte du tout dans les outils), ou bien considérer qu'il ne s'agit que d'étiquettes symboliques permettant de distinguer des anneaux dans un même multipolygone. Cependant ce sont les éditeurs qui doivent alors s'assurer de préserver ces étiquettes (sachant qu'il est assez courant de trouver des rôles "outer" d'anciens ways remplacés par des rôles anonymes de nouveaux ways corrigés ou issus de fusions avec d'autres ways qui utilisaient d'autres rôles, et aussi qu'n cas de fusion de ways, JOSM génère par défaut un rôle "outer" dans les relations où un way est remplacé par un autre). _______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
