> > Non, il ne l'est pas. > > Regarde mieux ! re-lit la page du wiki qui parle des relations multipolygone, elle dit : "the multipolygon relation can be used to build multipolygons in compliance with the OGC Simple Feature standard"
> Tiens compte du fait que l'ordre de tri des membres n'est pas > significatif, pas plus que l'orientation des ways Je ne fais que ça. > , 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. Tout est là, tu viens de le dire, on obtient 1 seule géométrie qui peut être valide au sens OGC, et comme c'est un pré-requis de la définition de la relation type=multipolygon, alors il n'y a pas d'ambiguité dans demo2.osm puisque la commune A n'a qu'une seule représentation OGC possible. CQFD > La > difficulté c'est l'algo pour déterminer cette géométrie valide (on a > un arbre de recherche combinatoire). Je ne le nie pas, mais la n'est pas la question (en tout cas pas pour l'instant) puisque je m'attache à expliquer que ta remarque initiale : "On a le cas suivant apparemment non prévu par OSM" est manifestement fausse. Maintenant, oui, on peut porter le débat sur l'éventuel difficulté de concevoir l'algorithme, de son optimisation, mais cette liste, je le répète, n'est pas le bon endroit pour parler développement. > tu obtiens soit deux carrés (ce à quoi tu > t'attends), soit une figure en 8 sans croisement Histoire que je sois sûr de bien me faire comprendre : non, on ne peut pas interpréter mon exemple ni comme un 8 ni comme E3 parce que cela n'est pas valide au sens OGC, donc invalide comme relation multipolygon Pour tes remarques suivantes concernant la complexité de l'ago, j'y répond sur dev-fr uniquement -- sly (sylvain letuffe) _______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
