Le 5 mai 2012 15:24, sly (sylvain letuffe) <li...@letuffe.org> a écrit : > Le samedi 5 mai 2012 14:12:22, Philippe Verdy a écrit : >> Je maintiens que ton fichier démo2 reste ambigu selon les règles mêmes >> énoncées dans le wiki > > Non, il ne l'est pas.
Regarde mieux ! Tiens compte du fait que l'ordre de tri des membres n'est pas significatif, pas plus que l'orientation des ways : tu obtiens 3 géométries possibles dans ton fichier (en ignorant l'orientation des anneaux obtenus ainsi que le noeud de départ de chacun d'eux), même si dans ce cas simple 1 seule correspond à une géométrie GIS valide. La difficulté c'est l'algo pour déterminer cette géométrie valide (on a un arbre de recherche combinatoire). Si tu fais le tri dans JOSM, selon l'ordre dans lequel tu as dessiné ou scindé les ways, tu obtiens soit deux carrés (ce à quoi tu t'attends), soit une figure en 8 sans croisement (on rebondit sur le point central en tournant à 90 degrés), soit une figure en 8 croisée (en continuant en ligne droite) dont la surface à droite du tracé parcouru dans la même direction sera alternativement à l'intérieur puis à l'extérieur du polygone (façon ruban de Moebius)... Le tri de JOSM est donc instable et impossible à prédire s'il dépend de l'ordre de création des ways ou de leur id dans la base (ces ids peuvent changer car les ways pourraient être scindés ou fusionnés avec d'autres ways superposés pendant des modifications successives et changer d'id : le tri de JOSM change alors sans pour autant que les contours aient changé). osm2gis aura les mêmes choix mais cela dépend en plus de la stabilité de son tri interne et de l'ordre dans lequel il indexe les segments créés par l'éclatement des ways, ordre des segments qui dépend de l'orientation des ways (alors que cela ne devrait pas influer). cela dépend aussi de son algo de tri de base (est-ce un QuickSort ? je n'ai pas regardé) et des clés de tri qu'il utilise et comment il indexe les éléments géométriquement égaux mais par ailleurs distincts par leur position relative dans la liste initiale à trier. Si l'algo de base n'est pas stable pour les valeurs égales, le tri obtenu dependra alors du nombre total de segments (qui peut varier simplement parce qu'on a coupé un segment en deux parties sans changer la forme géométrique décrite). Dans des cas plus complexes comportant plus d'1 noeud commun — ou plus rarement s'il y a 6, ou 8 chemins terminés sur ce même noeud, cas aussi possible et que j'ai vus dans OSM ! — on obtient plusieurs géométries valides, et cela explose de façon combinatoire et de façon encore plus rapide, en plus d'obtenir un algo de résolution particulièrement lent puisque le problème à résoudre pour énumérer les géométries possibles, dont chacune reste à valider selon les contraintes des polygones GIS, est topologiquement équivalent à celui du voyageur de commerce : avec un grand nombre de ways (par exemple une centaine, ce qui arrivé dans le cas justement de Xativa en Espagne), c'est prohibitif ! _______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
