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. _______________________________________________ Talk-fr mailing list [email protected] http://lists.openstreetmap.org/listinfo/talk-fr
