Le dimanche 06 juin 2010 22:51:45, Vincent Pottier a écrit : > L'intérêt de distinguer l'area (et les multipolygones) du way, et de > reconstruire le tout dans un type=river, c'est qu'une rivière est un > plan d'eau ET un cours d'eau, voire des écluses, des barrages, une > activité économique et autres....
Tout à fait. Et ces éléments peuvent être mis en relation, pourquoi pas. > Or, le multipolygone ne s'intéresse qu'à l'aspect surface pour en > désigner la géométrie. Le multipolygone n'est donc pas "river" mais > pourrait être "river_surface". C'est vrai, mon exemple n'étais pas très bon, un river_surface serait un mot mieux choisi puisque c'est ça que ça représente. > relation river avec des éléments de surface et des éléments axiaux est > une solution relativement propre. Oui, ce que je trouve moyennement bien fichu c'est uniquement la partie description de la surface. Je ne vois pas d'inconvénients à créer une autre relation type=river qui contient la relation qui décrit la surface, le way (ou relation) qui décrit l'axe, et tout ce qu'on voudra bien y mettre (j'ai malgré tout un peu de mal à imaginer l'usage, mais ma foi, certain y trouverons bien un intérêt) Ce que je vois bien par contre, c'est qu'aujourd'hui le modèle de donnée ne me permet pas de construire par exemple une carte des cours d'eau français de longueur supérieur à X km cf l'horreur à laquelle je me suis arrété : http://wiki.openstreetmap.org/wiki/File:Hydro.png > > Maitrisable dans quel sens ? > > Longueur du cours d'eau. > Je mappe dans mon coin. Dans mon coin la rivière est bien tagguée. > > Si je dois m'assurer de la cohésion des 1000 km de la Loire... > Il y a des problèmes pour la coastline, on retrouverait ce type de > problème (à moindre échèle) pour les cours d'eau. Avec la solution du multipoly qui couvre tout le cours d'eau, une modification locale sur un poly valide n'a aucune raison d'entrainer une rupture 100km plus loin, vu que justement on n'a téléchargé que les riverbank d'une petite zone. En revanche, et c'est là que je trouve que c'est pernitieux les multiples bouts autonomes de surface qui forment une plus grosse surface, c'est que si je calcul la longeur/surface d'un fleuve, une valeur me sera retournée, mais qui sera fausse > Le logiciel de routage ne se basera pas sur les multipolygones, les > plans d'eau, mais sur du filaire (le waterway) Certes, le principe est similaire, si mon waterway à un trou, graphiquement ça ne se voit que mal mais le routage est interompu. Certes encore, il existe de toute façon des outils pour contrôler plus ou moins tout. Je reviens un peu sur ton example du coastline, ça me donne des idées :-) La solution utilisée est une re-construction périodique des côtes pour qu'un controle semi-humain valide que tout est bien fermé avant de lancer des rendus/utilisations. Une bonne (peut-être ?) idée serait de faire du controle d'integrité et du versionning. Si la relation X qui représente un polygone ne forme plus un polygone, on ne fait pas la mise à jour. C'est ce que je fais en fait sans y avoir pensé ici : http://beta.letuffe.org/ressources/export-communes/ Je ne rend disponible une mise à jour que si celle-ci est complète est valide, sinon je fourni la précédente -- sly _______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr