> De : "Stéphane Brunner" > A : talk-fr@openstreetmap.org > > Mais si on sort un peut de ce cadre il me semble que si on a un très grand > polygone > 2000 nœud c'est tout de même la solution la plus propre.
En fait c'est surtout la seule possible compte tenu des limites données par l'API v0.6 : pas plus de 2000 nodes par way. Mais on parle ici de la constitution d'un polygone en tant que tel, pas forcément d'un multipolygon. Généraliser ce fonctionnement rejoindrait la proposition de sly : on ne dessine pas de polygone en tant que tel mais des ways, jamais superposés, qui via une relation constituent des surfaces. Sans forcément atteindre les 2000 nodes, c'est exactement ce qui se fait déjà pour les emprises administratives. Pour des surfaces plus petites et surtout plus simples à gérer, on reste dans un modèle un peu topologique (les noeuds communs sont 1 seul noeud) et un peu spaghetti [1] (les ways sont distincts par polygone, même s'ils sont superposables exactement). Bref on est entre 2 approches, sly plaide pour le tout topologique [2] (si je ne trahis pas ses propos), ça me plaît aussi mais c'est un gros enjeu pour les interfaces de saisie. S'il faut pour former un polygone dessiner un nouveau way à chaque fois qu'un node est visuellement au croisement de 3 ways puis ensuite éditer une relation "polygon" pour lister les ways, avec l'ergonomie actuelle de JOSM on n'a pas fini... vincent [1] : http://www.gitta.info/DigitModel/fr/html/Topologies_learningObject1.html [2] : http://www.unites.uqam.ca/dgeo/geo7530/stb3.htm Une messagerie gratuite, garantie à vie et des services en plus, ça vous tente ? Je crée ma boîte mail www.laposte.net _______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
