Pour le cas où un contour interne touche un contour externe, il n'y a pas d'ambiguïté : il **faut** utiliser la représentation la plus "convexe" possible utilisant le plus grand nombre d'anneaux et qui ne les fusionne pas en un seul anneau à forte concavité (où un même nœud est visité plusieurs fois par le même anneau).
Cela fait alors que chaque anneau ne visite chacun de ses nœuds qu'une seule fois (sauf le premier et le dernier nœud de l'anneau fermé qui sont nécessairement les mêmes et qui forme une seule visite complète en entrée et en sortie). Alors tout anneau enferme SOIT la totalité de la surface d'un autre, SOIT une surface nulle d'intersection avec l'autre, SOIT sa surface est totalement dans l'autre. Cela forme alors une relation d'ordre partiel (sur les surfaces sans les bordures), même si ces anneaux d'un même multipolygone peuvent se toucher (uniquement sur un nombre fini de points, donc sur une longueur totale nulle). Dans un même multipolygone toutefois, si deux anneaux ont un segment commun de longueur non nulle, c'est qu'un des segments doit être découpé sur les noeuds d'un autre segment, avant d'éliminer les paires de segments communs, afin de fusionner les deux anneaux en un seul sans ce segment commun. Tout cela est malgré tout entièrement automatisable (comme aussi le fait alors de savoir si un anneau et interne ou externe, un jour ou l'autre on pourra se passer même de devoir préciser les rôles "inner" et "outer" dès que les outils les calculeront systématiquement eux-mêmes pour informer l'utilisateur). Dans ce cas les rôles seront utilisés pour autre chose ! Et permettront d'avoir n'importe quelle intersection entre membres d'une relation, tant que ce sont des rôles différents ; sauf les rôles "" (vide), "inner", "outer", "enclave" et "exclave" qui seront alors tous vus comme totalement équivalents les 4 derniers étant dépréciés ou tous automatiquement remplaçables en "inner" ou "outer" (pour les multipolygones uniquement, qui sont nécessairement formés uniquement de d'anneaux fermés, mais pas pour les multilinetrings dans lesquels les 2 rôles n'ont strictement aucun sens puisque les mutlinestring sont utilisés à la fois comme contours internes et externe selon les multipolygones qui les référence, même lorsque un multilinstring contient un ou plusieurs anneaux fermés). Le 15 novembre 2012 10:35, Pieren <pier...@gmail.com> a écrit : > 2012/11/14 Lapinos03 <lapino...@free.fr>: > > Parfois, vaut mieux voir cela directement avec l'auteur. Une chance que > je > > passais par là ! ;) > > Effectivement, le polygone "inner" de la relation intersectait le > polygone > > "outer", ce qui doit perturber Mapnik. Du coup, je l'ai sorti de la > relation > > pour l'instant. > > Dans un polygone, les "trous" (role inner) ne doivent pas sortir des > limites extérieures (role outer) dudit polygone. Si c'est le cas, il > faut exclure la surface "imbriquée" de la relation et redéfinir les > contours extérieurs du polygone pour qu'il n'y ait pas de > chevauchement entre polygones. > Là où il peut y avoir différentes interprétations sur la validité d'un > polygone (et donc matière à contester le fonctionnement de > osm2pgsql/mapnik), c'est lorsque le contour du inner touche le bord > extérieur sans le franchir (pas d'intersection). Sly a lancé plusieurs > discussions dans le forum des développeurs sur ce sujet pour faire > émerger un consensus entre les différents outils OSM et les normes > SIG. > > Pieren > > _______________________________________________ > Talk-fr mailing list > Talk-fr@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-fr >
_______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
