[OSM-talk-fr] Dessiner un fleuve (grand multipolygon)

sylvain letuffe sylvain at letuffe.org
Dim 6 Juin 21:20:53 UTC 2010


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




Plus d'informations sur la liste de diffusion Talk-fr