[OSM-talk-fr] Cours d'eau, relations, riverbank - dessines moi de l'eau !

[Vincent Pottier]

On 15/07/2010 18:59, sly (sylvain letuffe) wrote:
> relation
>
> Sauf que ma méthode est loin d'être reconnue et bien utilisée et que
> visiblement ça se bat fort :
> http://wiki.openstreetmap.org/wiki/WikiProject_Rivers
> entre ceux qui voudraient une relation qui contienne le nombre de canard par
> km^2, les berges innondables, non innondables, le tracé de la rivière tel
> qu'il était en 100000 BC (non je ne vise pas un certain VP), et qu'au final
> rien n'avance.
>    
Et bien,  il y en a s'il devaient mapper une sardine, peuchère, elle 
boucherai le port de Marseille, con ! Sly tu ezzagère ! J'ai jamais 
parlé de canard carré.

Bon, plus sérieux. Ça avance tout de même un peu, même si c'est 
disparate : sur le wiki, il n'y a qu'une personne pour s'opposer à la 
relation.
> J'aimerais dire "mapping comes first", genre, on se mets d'accord sur un truc
> simple, on fait une jolie démo et documentation et ensuite on défini un truc
> de dingue en incluant et sans détruire le truc simple.
>    
Ok, on fait comme ça. Yaka.
Re-sérieux : Oui, intéressant de faire une mise à plat, surtout si des 
données viennt à se libérer pour l'hydrologie. D'autant plus qu'avec le 
cadastre pdf, les ruisseaux et rivières pleuvent, si je puis dire : j'ai 
nettoyé des plans d'eau sur la Seine.
> == Les rivières "surfaces" ==
>
> Un peu la même chose en fait, je sais que le multipolygon ne plaît pas à tous,
> qu'il est courant de tagguer en méthode puzzle et que oui, ça a des
> avantages, mais là j'ai un peu les boules car on a dégommé mon travail sur
> l'isère :
> http://www.openstreetmap.org/browse/relation/278498
>
> Et mes échanges de mails avec un certain PA94 ...
>
> Le consensus c'est alors : pas de multi ? chacun son truc ? ou : sly, tu nous
> fais chier ! ;-)
>    
le 3/ je n'oserai même pas le penser.
Mon opinion
=========
Outre le coté indélicat de la façon de faire,
Je suis convaincu que ta méthode multipolygone est, à terme, la plus 
juste, mais la plus fragile [1]. De plus elle n'est pas simple à gérer 
pendant la construction. Une fois le puzzle construit, c'est 
relativement simple de changer la méthode du multi puisque les ways sont 
déjà existants et regroupés dans une relation. Un peu de découpe dans 
les pièces du puzzle, un peu de tri dans l'interface JOSM et hop, on 
obtient un pur multipolygone multiligne.

Ma méthode
========
http://www.openstreetmap.org/browse/relation/156145
(Âmes sensibles s'abstenir : la rivière présentée prend sa source dans 
un massif montagneux appelé Jura, dont l'origine remonte à bien avant 
100000 BC, soit à une époque appelée jurassique. Il se peut que des 
esprits faibles soient heurtés)
J'essaie de faire du tout-en-un :
La relation (peu importe dans un premier temps[2] son type, son nom...) 
regroupe des waterways et waterbank.
Il me parait pertinent de créer une relation qui représente un objet : 
la rivière, et dont les rôles signifient sous quel aspect elle est regardée.
Plutôt que de multiplier les objets, un pour l'aspect cours d'eau (pour 
dépasser les 60 km), un pour l'aspect plan d'eau et pourquoi pas un 
associated_river (pourquoi associated ? Jamais compris. Street tout 
court, ça ne suffit pas ?)


[1] Ton exemple pour résoudre le problème des confluents dans les 
multipolygones m'a convaincu : des ways constituant un multipolygone 
"plan d'eau", certains ways étant, de plus, "riverbank", c'est net.
[2] J'éviterai toutefois le type route : des éléments font partie d'une 
relation route pour représenter la voie navigable. Le type route ne me 
parait pas tout à fait indiqué pour désigner le parcours de molécules 
d'eau. Mais c'est un second débat.
--
FrViPofm