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

[sly (sylvain letuffe)]

> > 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)