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

[Vincent Pottier]

Le 06/06/2010 23:20, sylvain letuffe a écrit :
> Le dimanche 06 juin 2010 22:51:45, Vincent Pottier a écrit :
>> 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.
>    
La solution est mieux, théoriquement.

Mais avec des segments, les crottes chez mon voisins n'entachent pas mon 
bac-à-sable.
C'est plus petit mais plus sur.

Et puis, je me sens le courage de cartographier 80 km du cours d'eau, 
pas 800 km. Dois-je attendre que le courage me vienne ?

La cohésion locale, je la contrôle dans JOSM, donc en direct, pas dans 
osmose, en différé.

Quand j'édite des bouts de multipolygones dans JOSM, j'ai des formes 
bizarres, pas belles, pas finies.

Bref, ta solution est mieux, théoriquement, ou à terme.

Mais les segments, c'est plus politiquement correct, plus sur, à court 
terme, plus rassurant.
> 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
>    
Pas à partir de ça : somme des role=waterbank

De toute façon on ne calculera que la surface 'cartographiée' du fleuve.
>    
>> 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
voire pas du tout sous un waterbank
>   mais le routage est interompu.
>    
On a le même problème que pour les routes...
On pourrait reprendre l'algorythme des bouts de train (voir un autre 
mail) et repérer les waterways cul-de-sac, qui ne sont pas la mer.
Je pense qu'il y a un tag pour les "pertes" pour éviter les faux positifs.
> Certes encore, il existe de toute façon des outils pour contrôler plus ou
> moins tout.
>    
Pas encore mais ça vient !
> 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
>    
Ouais, il est possible que des serveurs "label qualité" vont se 
multiplier, notamment pour les collectivités, où la donnée n'est pas de 
toute première fraicheur, mais relue et filtrée.
--
FrViPofm