Le 04/05/2012 22:31, sly (sylvain letuffe) a écrit :
Le vendredi 4 mai 2012 22:22:55, DH a écrit :
Cet espace est une espèce de trou noir si j'ai bien compris le schéma.
Quelle dimension pour le supertuyau afin de canaliser le superflux ?
PVCompatible ?
ça va ? c'est de la bonne ?
oui c'est de la bonne ; je l'ai acheté dans la même boutique où tu as
trouvé ton dictionnaire.
Self-Ring Intersection ?
http://workshops.opengeo.org/postgis-intro/validity.html
Non, je ne m'engagerai pas plus avant. Cette liste n'est pas ni
dimensionnée ni opportune pour faire cela.
C'est un peu facile, tu réponds, maintenant t'assume le retour ;-)
Certes c'est technique, mais c'est directement une question de "comment (ne
pas) mapper une relation multipolygone" et en ça, ça n'est pas une question de
dev donc dev-fr ne me semble pas la liste la plus adaptée, mais je peux me
tromper.
Il me semble que le problème se situe au niveau de l'interprétation d'un
osm2pg (ou autre) et donc plutôt dev. Mais je peux me tromper.
Modifier la manière de tracer des figures complexes (mais valides) est
un pis-aller pour éviter des problèmes de conversion en SQL/OGC.
Ton lien est très bien et j'étais déjà tombé dessus mais il parle de la
primitive "POLYGON" de l'OGC pas de la primitive MULTIPOLYGON dont il est
question ici, qui elle autorise que deux polygons distinct se touchent au sein
d'une primite MULTIPOLYGON
Exact. Pour un multipolygon ça ne le rend pas invalide. Comment se prend
la décision de passer un way en polygone ou en multipolygone (hors cas
faciles) ?
Si les bordures constitutives de la commune sont transformées en
polygon, il y une erreur de validité de la figure. Si les bordures dont
converties en multipolygon, ça passera sans souçi.
Denis
_______________________________________________
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr
