[OSM-talk-fr] Problème insoluble de géométrie.

[Philippe Verdy]

>  +-------------------------------------------------------+
>  |                                                        |
>  |    +----------------------------------------------+  |
>  |    |       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é)