Note: je suis tombé aussi sur d'autres cas de géométries qui son mal résolues lors de la conversion OSM vers OGC.
Un de ces cas incluait la situation suivante (schématisée ici) : +-------------------------------------------------------+ | | | +----------------------------------------------+ | | | A | | | +---------+ +-----------+ +--------+ | | \ / \ / | | B \/ B \/ | +----------------+-----------------+-----------------+ Ici la commune B possède la commune A en enclave, mais cette enclave A touche la bordure externe de B en deux points (en bas sur ce schéma). La définition de la commune A encavée ne pose pas de problème, il n'y a qu'un seul contour externe dans sa relation. La commune B a elle aussi apparemment un seul contour externe (le rectangle dans ce schéma, lisible avec une police proportionelle comme Arial). Là encore la conversion OSM > OGC se plantait et signalait une intersection et produisait des zonages incorrects. La solution théorique consisteraint à représenter la commune B en deux polygones distincts (avec leurs ways eux aussi munis du rôle "outer"), un premier pour la partie supérieure et latérale, et un autre polygone pour le morceau inférieur, de sortes que ces deux parties sont des exclaves l'une de l'autre. C'est ce qu'on ferait dans une représentation multipolygone du schéma OGC. Mais dans le cas d'OSM, qui ne sait pas représenter proprement les polygones fermés séparés constituant le même multipolygone, mais mélange tous les ways et ne tient pas compte ni des rôles (outer/inner) ni même du tri effectué entre les ways qui les connecte. Et je me suis retrouvé dans le schéma GIS avec les contours de A formant une boucle faisant deux tours et où la ligne se croise. Cela ne marche pas, car là encore la conversion ne tient pas compte du tri des ways dans la relation, dès lors que l'outil de conversion tient à interconnecter le maximum de ways même si cela crée des anneaux (rings) invalides qui s'entrecroisent. Le problème vient là encore du tri des ways qui est systématiquement effectué, et du fait qu'il n'est pas tenu compte du tout de la façon dont les ways sont ordonnés dans la relation OSM type=multipolygon. Ce cas est géré seulement par l'outil de conversion OSM>OGC quand une enclave touche une zone englobante uniquement par un seul point (il y a un "truc" qui évite de former la même double boucle et tenant compte de l'existence de l'unique point de contact pour créer deux anneaux distincts et non un contour unique entrecroisé. J'ai réglé ce cas là aussi trouvé en Espagne, en allant chercher dans le cadastre pour vérifier si ces points de contact étaient réels ou non : et j'ai trouvé que c'était des faux points de contact, provenant d'une conflation incorrectement effectuée entre les planches cadastrales : la solution était donc de séparer les points des contours de A et de B, afin de faire de A une enclave n'ayant aucun contact avec la bordure externe de B, puisque c'était bien le cas. les points de contact (sur la ligne inférieure du rectangle schématique ci-dessus) de A ont été remontés légèrement de quelques centimètres pour qu'ils ne touchent pas le contour de B. Mais je n'ai pas réglé le problème de conflation qui aurait demandé de refaire totalement la numérisation des planches cadastrales sur une commune là aussi complexe possédant des enclaves sur la majeure partie de sa surface...), car il y avait visiblement des problèmes d'alignement des planches (avec un offset non corrigé. Car je ne sais pas laquelle des planches cadastrales de A ou de B était mal alignée (je penche pour la planche de B, la commune compliquée qui possède des enclaves A quasi-jointives entre elles sur la majeure partie de sa surface, ces enclaves étant séparées entre elles par des corridors étroits de parfois moins de 10 mètres de large...). Du coup j'ai aussi laissée une note "fixme" pour signaler le problème de conflation et d'alignement de la commune B et de ses enclaves comme A (il me semble que la numérisation des enclaves A a utilisé par erreur une des projection UTM/ED50 légales espagnoles, natives dans son cadastre, alors que la numérisation de B a utilisé les coordonnées en WGS84, le cadastre espagnol pouvant retourner au choix des données dans l'une ou l'autre des deux projections). Ce n'est pas un problème car le cadastre espagnol signale que cette commune B est en cours de mise à jour et serra réimportée bientôt (il y aurait des fusions et échanges de parcelles entre municipalités pour supprimer certains des corridors dans B mais proches de son contour externe, de sorte que certaines municipalités comme A aujourd'hui totalement enclavées dans B ne le seraient plus en acquérant la surface de ces corridors étroits). Note : je n'ai pas les outils pour importer le cadastre espagnol directement, la seul chose que je fais ce sont des microdéplacements tant qu'il sont de quelques centimètres (bien en dessous de la limite de précision du cadastre pour les limites de planches municipales), pour régler la géométrie OSM actuelle qui ne marche pas correctement. D'ailleurs même le site web de consultation du cadastre espagnol montre très bien que les planches cadastrales numérisées ne collent pas exactement les contours des municipalités : on voit très clairement le double contour "aléatoire" là où il n'y a réellement qu'une seule frontière et pas deux ! Le cadastre espagnol n'a pas effectué partout lui-même la conflation des planches et attend sans doûte plutôt des relevés plus exacts sur le terrain pour repositionner plus précisément ces frontières incertaines. (La conflation a été faite entre les planches des zones "urbaines", mais pas encore pour de nombreuses planches "rurales", ce travail devant amener à revoir les relevés des actes de cession/vente notariés ou actes d'expropriations, ou des décisions municipales ou judiciaires pour déterminer quelles mesures ici en conflit sont légalement à conserver, ce qui n'est pas forcément évident pour savoir qui possède ou entretient le lit d'un ruisseau, ou à qui appartient une haie, un arbre, une clôture, un mur, ou un chemin dans sa parcelle, et il peut aussi y avoir des arbitrages intercommunaux...) _______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
