J'avais déjà suggéré cette solution dans mon message. Il n'empêche que c'est du pseudo-mapping : on ajoute des trucs inexistants (ici des frontières supplémentaires qui rompent les relations de voisinage à cause d'un bogue de la conversion des données OSM vers OpenGIS. Ca montre une limite du modèle actuel.
Note: tu n'as pas vu l'exemple, la précision de ces fragments nécessiterait une microzone de séparation de largement moins qu'un mètre. Ce bogue ne concerne que le cas des deux zones qui sont exclaves l'une de l'autre et qui ne se touchent que sur un seul point: - Dans le cas de zones qui se touchent mais dont l'une enclave l'autre, il n'y a pas de problème puisque alors ce sont des relations séparées. Cela ne bogue pas car les rôles "inner" et "outer" sont séparés. - Dans le cas où l'intersection des deux zones exclavées forme un segment, on supprime ce segment pour fusionner ces zones en une seule. - Dans le cas où l'intersection des deux zones exclavées forme une surface, on supprime les segments qui bordent aussi cette intersection pour former une seule zone. - Mis dans le cas où l'intersection des deux zones forme seulement des points, il n'y a pas de simplification possible : la conversion OSM vers OpenGIS échoue car elle tente de recoller ensemble des segments ayant le même rôle "outer" (ou les mêmes rôles "inner") en un seul de façon arbitraire, qui ignore même l'ordre des segments indiqué dans la relation puisque justement ce sont les mêmes rôles. (note: mettre "exclave" ou rien à la place de "outer" ne change rien au problème, dans les faits, la conversion OSM vers OpenGIS échouera puisqu'il n'est pas possible de séparer explicitement les sous-ensembles de ways formant un même anneau délimitant une surface. Je n'aime pas trop mapper des trucs inexistants... Surtout que la solution de la micro-zone va rendre non limitrophes deux zones au départ limitrophes par un point, et va rendre limitrophes par un segment complet deux zones qui ne se touchaient que par un point. Pour les applications qui cherchent les relations limitophes, on obtient des résultats faux, et on se retrouve à devoir chercher "ailleurs" les véritables éléments limitrophes en acceptant un rayon de recherche non clairement défini. Note: j'ai vérifié le cadastre espagnol : cette municipalité n'est pas une erreur, la fragmentation très complexe des enclaves et exclaves qui semblait suspecte est bel et bien réelle ! D'ailleurs Google Maps s'avère incpable d'afficher les limites réelles de cette commune et oublie une grande partie des surfaces des municipalités concernées dans cette zone, et affiche même des frontières très approximatives, largement arrondies, et qui ne tiennent compte que de la zone principale et pas de la plupart des exclaves et enclaves (c'est peut-être pour ça que Google Maps évite même d'afficher les frontières, mais ne les représente (en rose) que pour entourer une seule localité recherchée à la fois. Google Maps se trompe couvent d'ailleurs sur des zones plus grandes comprenant des exclaves, il en omet plein en Espagne (où les exclaves sont réellement très fréquentes à tous les niveaux administratifs) ! Bing Maps omet aussi d'afficher les frontières (pour les voir il faut demander à afficher des cartographies complémentaires. Je trouve cela bien dommage car cela permet de préciser les adresses et lever des ambiguités d'homonymies. Les adresses obtenues dans Google Maps sont donc très souvent très approximatives quand on est près des frontières. Et pour faire des cartes dérivées (par exemple des données statistiques, Google Maps/Earth, comme aussi Bing, sont totalement inutilisables !) Pour aller jusqu'à la précision cadastrale (par exemple reprérer le bâti), on ne peut pas se passer d'une précision complète des surfaces, mais il est dommage qu'OSM se plante dans sa représentation, là où le modèle OpenGIS (basé sur la représentation des surfaces par anneaux) répond totalement à ce problème. OSM pourrait lever ces ambiguités en précisant les rôles et admettant des rôles comme "outer:2" (qualifiés par un numéro symbolique d'anneau) pour faire le tri de ce qui est jointif ou non dans les relations, et faciliter la conversion OSM vers OpenGIS (puisque cela lève toutes les ambiguités sans nécessiter aucune pseudo-géométrie supplementaire). Le 4 mai 2012 14:34, David MENTRE <dmen...@linux-france.org> a écrit : > Bonjour, > > Le 4 mai 2012 13:29, Philippe Verdy <verd...@wanadoo.fr> a écrit : >> 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. > > Faites une surface dérisoire de liaison (quelques mètres voire > centimètres). Solution très simple qui utilise une approche > archi-classique. > > Cordialement, > d. _______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
