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

[Philippe Verdy]

Note bien ce qui est écrit dans la doc des multipolygones sur le wiki :

Usage

The intended use of multipolygons is this:
[..]
The direction of the ways does not matter.
The order of the relation members does not matter (but properly sorted
member lists can help human editors to verify completeness).

Autrement dit la direction et l'ordre des ways n"étant pas
significative, tous les outils DOIVENT trier ces listes pour
déterminer comment fermer les polygones ou former des lignes
continues.

Aucun éditeur n'assure que le tri sera conservé par exemple lorsqu'on
scince un way en deux parties (les parties peuvent être ajoutées dans
un ordre quelconque dans la relation.

Si on ne peut pas tenir compte de l'ordre, alors ton fichier demo2
décrit 3 géométries différentes (dont une seule ici peut correspondre
à une géométrie GIS valide)

Mais dans d'autres cas, il y a plusieurs géométries possibles aussi
dès que les polygones se touchent si on a plus que deux polygones dans
la même relation. C'est le cas dans la municipalité mentionnée en
Espagne qui, si on ne PEUT PAS tenir compte de l'ordre stocké dans la
base (selon la doc wiki elle-même), génère 18 géométries possibles,
dont 9 sont valides en GIS !

Si on doit tenir compte de l'ordre alors il y a des quantités énormes
de multipolygones brisés à réparer, et la doc est donc fausse puisque
l'ordre est significatif et les outils d'édition devraient alors en
tenir compte pour ne pas les briser par un ordonnancement incorrect
lors s'une simple scission d'un way en deux parties, ou lorsqu'on
fusionne des ways communs (au passage leur orientation est aussi
modifiée, mais elle n'est pas significative non plus, toujours d'après
le wiki) !

Bref il n'y a PAS de bogue dans osm2gis, il est OBLIGÉ de trier
lui-même (à cause des règles énoncées dans la doc du wiki OSM), et n'a
aucune indication sur le nombre de ways à inclure dans un même
polygone (il cherche en fait à créer les polygones comptant le plus
grand nombre de segments possibles, et c'est ce qui génère alors de
toute façon les boucles qui se croisent et des géométries invalides
non représentables en tant que polygones GIS ; s'il cherchait
uniquement à générer des polygones GIS valides, fermés, sans aucun
noeud parcouru plus d'une fois par le même chemin, il aurait encore à
faire un choix arbitraire).

Sans règle supplémentaire (non écrite dans la doc), il n'est donc pas
possible de représenter dans la même relation multipolygone OSM et
sans ambiguité d'interprétation, plusieurs polygones qui ont des
sommets communs, parce que les multipolygones OSM ne savent pas
représenter actuellement la séparation entre les sous-ensembles de
ways décrivant les polygones fermés à générer.

La seule séparation "virtuelle" (dont osm2gis ne tient pas compte en
fait car ils sont très souvent incohérents) c'est celle des rôles
"inner"/"outer", et ça ne suffit pas non plus :

Il faut plus de rôles et ne plus tenir compte non plus de leur qualité
"inner" ou "outer" qui est souvent mal indiquée (et qu'osm2gis
recalcule lui-même après avoir généré les polygones GIS et seulement
quand ils sont valides c'est-à-dire sans aucun point traversé plus
d'une fois par la ligne de contour générée. Des rôles *qualifiés* et
distincts (de façon symbolique) seraient donc nécessaires pour séparer
explicitement les sous-ensembles de ways.

Ma règle supplémentaire, basée sur des rôles explicites, est simple et
ne remet pas en cause 99% des données de la base (je suis peut-être un
peu large dans cette statistique estimée à vue de nez, qui pourrait
être fausse dans le cas des multipolygones du bâti, et des zones
"landuse=*", ou si des cas comme ceux trouvés en Espagne sont plus
fréquents qu'on croit dans d'autres pays) :

(1) des rôles explicites ne sont nécessaires QUE s'il y a des sommets
communs (faisant partie de plus de 2 ways dans la même relation) et
dans ce cas ce même rôle doit être indiqué pour TOUS les ways d'un
même polygone à distinguer dans la même relation.

(2) par soucis de cohérence et de vérification (en cas de polygones
brisés par les relations par des modifications sur des données
partiellement téléchargées), on ne tient plus compte des rôles
"'inner", "outer", "enclave", "exclave", et anonymes, qui font parie
par défaut du même jeu de données, mais il serait tout de même bon que
ces rôles soient nommés "inner:*" et "outer:*" (uniquement s'il y a
des sommets communs), tout en laissant "inner" et "outer" pour les
jeux de ways formant les polygones sans sommet commun (pour ceux-là
osm2gis sait correctement vérifier leur cohérence).

En attendant que ce soit développé, il n'y a que la solution
consistant à séparer artificiellement les noeuds communs avec un tout
petit écart (10 centimètres, soit moins qu'un demi-pixel dans la
résolution la plus fine de tous les moteurs de rendus actuels zoomé au
maximum, mais suffisant pour différencier deux coodonnées flottantes
stockées sur 32 bits, ou encore une centaine de pixels au zoom maximum
de JOSM quand il affiche la barre d'échelle représentant 4
centimètres).

Cet écart artificiel de 10 cm (regardez la barre d'échelle dans JOSM)
entre nœuds qui devraient être superposés est invisible (et reste
conforme à toutes les sources orthophotographiques ou cadastrales
utilisées) mais résoud l'ambiguité d'interprétation des géométries OSM
pour ce cas.