[OSM-talk-fr] Suivi des cours d'eau français

[Pierre-Alain Dorange]

sylvain letuffe <sylvain at letuffe.org> wrote:

> > Comme de nombreuses relations intègrent les riverbank (du moins du
> > partie de ceux-ci) ne pourrais tu pas dans tes scripts mouliner les way
> > de la relation pour ne considérer que les waterway=river dans le calcul
> > de longueur voir même le rendu. 
> 
> Cette approche est possible techniquement en effet. Il est presque tout le
> temps possible de trouver l'algorithme qui va s'en sortir, sauf que est-ce
> le bonne voie ? J'y vois un risque d'erreur : - si un way n'est pas taggué
> en waterway=river mais appartient quand même à la relation, qu'en penser ?
> (ça peut se produire avec des frontières de communes qui sont tagguées
> boundary=administrative et qui ont comme support physique la rivière)
> 
> On pourrait se dire : c'est une erreur de mapping, il faut donc corriger,
> mais finalement ce n'est une erreur que parce qu'on le dit,
> structurellement ça peut très bien marcher (on peut quand même déduire
> qu'il s'agit d'une rivière car faisant partie de la relation)

Pour moi c'est clairement une erreur de mapping. Un tronçon sera
manquant sur la carte (je sais c'est le rendu) mais aussi à l'analyse
(mais que vient faire un boundary dans une relation waterway ?)...

> D'ailleurs ça pourrait marcher par négation, si le way dans la relation
> est un riverbank, on peut imaginer le retirer, ça marcherait aussi. Ce qui
> tendrait à monter qu'ajouter le role "riverbank" est inutile puisque
> contenu dans les tags du way.

Le "retirer" de l'analyse de la longueur de ton outils, je ne parle que
de ça.

> La question que je me pose, c'est que si je dois ruser pour m'en sortir,
> si l'outil de base osm2pgsql doit être modifié pour y arriver, est-ce que
> ça ne veut pas dire qu'a chaque fois que quelqu'un voudra reconstruire la
> rivière, il devra lui aussi faire un algorithme spécial. Et donc est-ce
> que ça n'indique pas que ce modèle n'est pas le plus adapté ?

En effet.
Je ne connais pas osm2pgsql (j'ai essayé de l'installer sur mon mac mais
j'ai abandonné plusieurs fois) et si tu dois envisager de la modifier
pour faire ça pas la peine... J'imaginais plutot que tu avais des
scripts (python ou autre) de traitement et que là a ce niveau c'est
"relativement" facile de filtrer pour calculer la longueur totale.
L'objectif n'est pas de pallier les défauts de tags, mais plutot de
fournir un vrai outil d'analyse pour améliorer l'existant. En calculant
correctement (seulement le cours principal) la longueur des cours d'eau
et avec ton % on a un réel état de l'avancement et cela peut motiver les
gens a continuer le travail.
Car aujourd'hui quand on voit un fleuve à 180% on se dis qu'il n'y a
rien a faire alors que peut être le waterway n'est que de 50% le reste
étant une parti des riverbank.

Mais tu as raison, le modèle avec riverbank n'est pas adapté. La
première étape de construction d'un cours d'eau c'est son cours
principal par autre chose.
 
> Je pense que d'autres sont arrivés à la même conclusion que moi, même si je
> n'ai pas le "killer argument", je préfère ne pas inciter à faire autrement.

OK
-- 
Pierre-Alain Dorange