Je confirme que ton ficher OSM ne marche pas : il correspond EXACTEMENT à ce que j'avais mis juste avant de scinder le nœud commun en 4 (regarde l'historique).
Ton fichier ne lève pas du tout l'ambiguité de la façon d'interconnecter les 4 segments limités par ce point commun, osm2gis les connecte ensemble de la mauvaise façon dans tous les cas, que ces segments soient séparés dans des ways distincts ou non, et quelque soit le rôle (inner ou outer) attribué à ces ways. Et ici, osm2gis cherche toujours à connecter le maximum de segments : quand il a fait le tour d'un des deux polygones fermés, il voit encore avant et après ce point deux autres segments (ceux de l'autre polygone), il crée donc une double boucle qui s'entrecroise sur elle-même et ne sait même pas non plus lesquels coisir pour éviter cet entrecroisement : c'est au petit bonheur la chance selon on critère non défini clairement (visiblement c'est la première paire trouvée de segments jointifs qui est choisie sans tenir compte d'aucun autre critère pour savoir s'il sont connectables ou non). Il n'y a actuellement aucun moyen (fiable et documenté) de distinguer clairement les "ring" de chaque polygone : - les rôles communs attribués aux ways devraient servir à ça pour qu'osm2gis ne se trompe pas et ne fasse pas confiance au seul hasard de ce qu'il trouve quand il énumère les listes de segments (note osm2gis convertit tous les ways en listes de segments rectilignes et unitaires, il finit donc par ignorer même le groupement des segments en ways, et ne garde pas trace non plus des rôles qui ont été attribués aux ways membres pour les attribuer aux segments unitaires : cela se passe bien avant même le tri des segments puis la recherche exhaustive de toutes les paires de segments interconnectés, d'où il déduit ensuite les lignes polygonales fermées traduites en polygones, et les lignes ouvertes converties alors en polylignes). - le tri initial des ways membres dans la relation est lui aussi totalement ignoré. - de même osm2gis ignore aussi la distinction des nœuds OSM ayant des "id" différents (une solution que j'ai testée aussi pour tenter de résoudre le problème et qui n'a pas marché non plus) : il unifie tous les nœuds superposés à la même position en un seul, dès le début lorsqu'il découpe les ways en listes de segments unitaires. - tout segment qui en touche en autre formera une ligne polygonale chaque fois que possible par extension maximale : tant qu'il peut prolonger la polyligne par un segment non encore utilisé par un des polylignes en cours de génération, osm2gis le fait (la conversion des polylignes en polygones tient compte sulement du test final de la polyligne pour savoir sir les deux noeuds d'extrémité sont aux mêmes positions ou non). En résumé, osm2gis ne semble avoir strictement aucun critère de choix quand il y a plusieurs segments candidats à l'interconnexion dans une même polyligne à partir d'un même point GIS (peu importe le nœud OSM d'origine de ce point GIS puisque la distinction des nœuds OSM est aussi perdue et n'est plus un critère distinctif pour former la géométrie). En revanche osm2gis sait éliminer les paires de segments communs (sans tenir compte de leur orientation initiale dans le way où ce segment était présent), pour simplifier les géométries GIS obtenues (ce qui a pour effet bénéfique de joindre automatiquement les surfaces mitoyennes en une seule): - on ne devrait pas être obligé de faire ce nettoyage dans une représentation par frontières si on utilisait les relations filles pour former des relations pour des surfaces plus grandes, puisqu'il pourrait par ce procédé les joindre automatiquement aussi en éliminant les frontières communes (forcément partagées par paires de segments communs) : - on doit lui prémâcher le travail (ce qui lui évite aussi des tonnes de sous-requetes pour aller chercher les relations membres) en détaillant à sa place uniquement les ways externes et internes de don coutour mais c'est très pénible à éditer : des collections de polygones fermés dans des sous-collections feraient aussi bien le travail. Autrement dit, - on modélise dans la base OSM en fonction d'osm2gis, malgré ses bogues/limitations, - mais on omet dans la base OSM des infos dont il aurait besoin pour faire correctement le travail de génération des géométries : cela demanderait des modifications dans osm2gis, mais aussi de documenter mieux la façon de taguer les multipolygones qui se touchent - les rôles des membres ont un rôle décisif (et plus utile) à jouer pour les ways (ou relations) membres d'une relation avec ce système, il ne serait même plus nécessaire de trier les membres qui deviendraient des listes non ordonnées de ways ou relations munies d'un rôle, chaque rôle mentionné dans la relation formant une collection elle aussi non ordonnée ; d'où un gain de stockage dans la base OSM pour les relations puisqu'on peut alors éliminer les indices de tri des membres dont osm2gis ne tient finalement aucun compte - le tri pourrait toujours être fait dans les éditeurs après le chargement des ways membres (de la même façon que le fait osm2gis avec ses segments unitaires obtenus par découpage des ways OSM en une liste non ordonnée de segments, une liste qu'il trie ensuite lui-même de façon imprévisible) : c'est ce que fait JOSM quand on clique sur son bouton de tri, mais il pourrait le faire tout seul et automatiquement sans aucun clic nécessaire, pour aider les créateurs/modificateurs à générer des géométries correctes, et en présentant à l'utilisateur les relations non pas comme une liste de membres mais comme une liste de rôles, chacun contenant une sous-liste d'objets (ways ou relation) triés automatiquement et signalant les intersections au sein de chaque rôle. _______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
