> +-------------------------------------------------------+ > | | > | +----------------------------------------------+ | > | | A | | > | +---------+ +-----------+ +--------+ | > | \ / \ / | > | B \/ B \/ | > +----------------+-----------------+-----------------+
Notez que ce cas est en fait le même que le précédent : si on considère un des points de contact sur la ligne inférieure, il y a 4 segments passant par ce point, et en faisant le tour et en cherchant à interconnecter le maximum de segments jointifs pendant le tri, la conversion OSM vers GIS conduit à croiser le chemin obtenu, de façon imprévisible. Ce cas se détecte en énumérant les zones autour de ce point de contact : B, A, B, C (la zone C étant celle sous le rectangle ci-dessus). Osmose signale une erreur s'il détecte que la même zone apparaît deux fois de façon non consécutive dans le cycle énumérant les zones autour d'un point : il croit qu'il s'agit d'une intersection, car il n'y a aucun moyen fiable de taguer quels segments sont à associer ensembles dans un même chemin polygonal ou dans un chemin séparé. Pour faire cette distinction, il faudrait des rôles séparés pour les chemins (la conversion OSM > OGC ne tient visiblement pas compte des différences de rôles "inner" et "outer" pourtant mis ici sur les chemins respectifs de A et de B dans la définition de la relation de type=multipolygone pour B), et que cette conversion ne cherche pas à interconnecter des segments de ways ayant des rôles distincts dans la relation. C'est donc là encore une ambiguïté non résolue du modèle OSM, une ambiguïté qui n'existe pas dans le modèle OGC qui distingue correctement les polygones fermés en tant qu'anneaux (ring). Et qu'il va bien falloir un jour documenter et régler : mettre les rôles inner et outer permet la plupart du temps ces distinctions à condition que l'outil de conversion en tienne compte (ce qu'il ne fait pas !), et que les outils d'édition permettent de bien distinguer ces rôles. Cependant : * les rôles "inner" ou "outer" (voire aussi "enclave" et "exclave") devraient alors devenir purement symboliques et il faudrait régler le problème des ways inclus dans les multipolygones sans aucun rôle. * les rôles dans les multipolygones ont diverses utilisations ne servant pas toujours à créer des frontières de surface. Il faudrait une convention de nommage * seulement deux rôles "inner" ou "outer" pour les frontières est insuffisant dans certains cas, il faudrait aussi "outer:2", "outer:3", et même plus clairement "outer:*" et "inner:*" pour désigner symboliquement les anneaux distincts au sein d'une même relation, le symbole pouvant être un nom et pas forcément un numéro peu clair. * des rôles supplémentaires distinctifs ne sont pas nécessaires si aucun des nœuds des ways (actuellement de rôles inner/outer/enclave/exclave ou de rôle anonyme) inclus dans le multipolygone n'est partagé par plus de 2 segments, il en faut s'il y a 3 segments ou plus pour un même nœud (3 segments c'est possible pour des relations de type multilignes, mais pas pour les relations définissant des surfaces "multipolygones" nécessairement fermées, ce qui implique que ces noeuds ne sont partagés que par un nombre pair de segments, sinon le multipolygone n'est pas correctement fermé) _______________________________________________ Talk-fr mailing list [email protected] http://lists.openstreetmap.org/listinfo/talk-fr
