Re: [OSM-talk-fr] Cours d'eau

[Philippe Verdy]

Le 29 avril 2016 à 23:07, François Lacombe  a
écrit :

> Le 29 avril 2016 à 15:41, Frédéric Bonifas  a
> écrit :
> > Le ref:sandre est déjà présent sur la relation :
> > http://www.openstreetmap.org/relation/301845
> > Je ne connais pas plus que ça les relations type=waterway mais je suppose
> > que c'est suffisant et qu'il n'y a pas besoin d'ajouter le ref:sandre sur
> > tous les membres de la relation.
> >
> > Fred
>
> +1
> Le ref:sandre d'un cours d'eau correspond à une "route" et doit
> logiquement figurer sur la relation.


Tout n'est pas nécessairemetn dans la relation, notemment le nom du cours
d'eau qui peut changer le long du cours. De plus on a des relations où
sandre attribue pour certains bras des identifiants supplémentaires,
différents du bras principal (cela devrait concerner normalement uniquement
les membres "side_stream"). Dans les deltas c'est plus compliqué, chacun
des bras peut avoir son propre identifiant et aucun n'est celui du cours
principal. Enfin il y a le cas des estuaires où se rejoignent plusieurs
cours d'eau: les eaux sont mélangées entre eaux douces et eau marine, et
cet estuaire aura son identifiant séparé dans certains cas où il n'est pas
évident qu'un des cours d'eau qui s'y déverse est un "cours principal"
quand la mer est en fait a une importance largement supérieure.

On peut fouiller dans le détail mais les ref sandre ne sont pas si simples
que ça. Mais il est difficle de présupposer que c'est partout le même le
long du cours; sandre peut décider de segmenter un cours en plusieurs
parties selon ses propres critères (exemple quand un cours d'eau a
plusieurs ruisseaux sources  disputés, chacun a son identifiant propre, le
cours d'eau principal commence après leur confluent). ref:sandre a aussi
conservé des identifiants historiques pour certains bras sources qui avant
étaient consdérés comme des affluents séparés et qui depuis sont devenus
partie du cours principal.

(On a le cas particulier de la Seine: l'Yonne a un débit largement
supérieure à la Seine à son confluent, et *techniquement* la Seine est un
affluent de l'Yonne qui continue alors jusqu'au Havre; mais là on ne va pas
revenir sur toute la tononymie historique - Sinon ce ne serait plus la
Seine qui coule à Paris mais l'Yonne, et Vitry-sur-Seine deviendrait
Vitry-sur-Yonne, la Seine-Maritime deviendrait l'Yonne-Maritime, etc.!).

Enfin sandre n'est applicable qu'à la France, et on a des cours d'eau
transfrontaliers, mais une seule relation pour eux (on n'a pas créé de
sous-relations spécifiques par pays, d'autant que parfois un cours d'eau
peut longer une frontière, s'en écarter d'un côte et et revnir pour
s'écarter de l'autre côté.

Si cela arrive, il faudra bien mettre le ref:sandre sur le chemin quand il
est différent de celui du cours d'eau globalement représenté dans OSM (et
notammeent dans le cas fréquent des "side_stream", bien que sandre
considère parfois comme cours principal un ancien bras naturel et non la
partie canalisée navigable qu'on considère dans OSM comme faisant partie du
"main_stream"). Cependant s'il n'y a pas de différence de référence entre
chemin et relation, alors oui la ref:sandre est redondante sur le chemin.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Cours d'eau

[François Lacombe]

Le 29 avril 2016 à 15:41, Frédéric Bonifas  a écrit :
> Le ref:sandre est déjà présent sur la relation :
> http://www.openstreetmap.org/relation/301845
> Je ne connais pas plus que ça les relations type=waterway mais je suppose
> que c'est suffisant et qu'il n'y a pas besoin d'ajouter le ref:sandre sur
> tous les membres de la relation.
>
> Fred

+1
Le ref:sandre d'un cours d'eau correspond à une "route" et doit
logiquement figurer sur la relation.
Dans le cas où on ne cherche pas à faire apparaitre ce code sur le
rendu, il n'est pas nécessaire de l'ajouter sur les chemins.

Je crois me souvenir que mapcss ne permet pas d'aller chercher dans
les attributs d'une relation pour afficher une voie membre.

François

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Cours d'eau

[Frédéric Bonifas]

Le ref:sandre est déjà présent sur la relation :
http://www.openstreetmap.org/relation/301845
Je ne connais pas plus que ça les relations type=waterway mais je suppose
que c'est suffisant et qu'il n'y a pas besoin d'ajouter le ref:sandre sur
tous les membres de la relation.

Fred

Le 29 avril 2016 à 15:38, Ludovic Hirlimann  a écrit
:

> On 02/03/2016 14:31, Frédéric Bonifas wrote:
>
> Salut,
>
> Dans le menu imagerie de JOSM, tu peux ajouter une couche "BD Carthage"
> sur laquelle tu verras le tracé du cours d'eau, son code Sandre (par exempe
> Y0011200) et parfois son nom.
> Tu peux ensuite aller sur le site du Sandre pour rechercher la référence
> d'un cours d'eau et avoir plus d'informations :
> http://www.sandre.eaufrance.fr/Rechercher-une-donnee-d-un-jeu
>
> Fred
>
> Rah le canal des deux mers est super long et découpé en plein de petits
> morceaux, y a un moyen simple d'y ajouter sur toute sa longueur la
> "ref:sandre" sans être obligé dans josm de télécharger le canal petit bout
> par petit bout ? (comme je viens de le commencer
> http://www.openstreetmap.org/user/lhirlimann/history#map=11/43.8291/1.3191
> )
>
>
> Ludo
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Cours d'eau

[Ludovic Hirlimann]

On 02/03/2016 14:31, Frédéric Bonifas wrote:
> Salut,
>
> Dans le menu imagerie de JOSM, tu peux ajouter une couche "BD
> Carthage" sur laquelle tu verras le tracé du cours d'eau, son code
> Sandre (par exempe Y0011200) et parfois son nom.
> Tu peux ensuite aller sur le site du Sandre pour rechercher la
> référence d'un cours d'eau et avoir plus d'informations
> : http://www.sandre.eaufrance.fr/Rechercher-une-donnee-d-un-jeu
>
> Fred
>
Rah le canal des deux mers est super long et découpé en plein de petits
morceaux, y a un moyen simple d'y ajouter sur toute sa longueur la
"ref:sandre" sans être obligé dans josm de télécharger le canal petit
bout par petit bout ? (comme je viens de le commencer
http://www.openstreetmap.org/user/lhirlimann/history#map=11/43.8291/1.3191)


Ludo
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Cours d'eau et fusion

[Philippe Verdy]

Modif faite sur le wiki (qui mentionne d'autres roles possibles et
plusieurs types de relations envisagés ou déjà utilisés)

http://wiki.openstreetmap.org/wiki/Relation:waterway#Members

La discussion proprement dite d'impose donc:
- rechercher et lister les différentes variantes
- analyser les avantages et inconvénients de chacune
- proposer un schéma unifié (avec les conversions à effectuer, il y en a
encore peu à faire)
- faire un vote sur les propositions discutées
- finaliser la doc avec la/les solutions approuvées.

Le 13 mai 2015 23:02, Claude  a écrit :

>  Le 13/05/2015 13:16, Philippe Verdy a écrit :
>
> C'est nouveau ce rôle "waterbody". Jusqu'à présent je n'avais vu que le
> rôle "riverbank" dans les relations du linéaire fluviale pour référencer la
> relation de son surfacique.
>
> En Belgique, j'ai vu des rôle  "canalbank".
>
>
>
>
>
>
>
>
>
>  Et ce même si cette dernière relation surfacique maintenant utilise
> water=* (parfois avec landuse=water), je n'ai pas vu ces tags mentionner
> "water=waterbody" en valeur!
>
> Le 12 mai 2015 20:44, Jérôme Amagat  a écrit :
>
>> il y a une relation spéciale pour les cours d'eau:
>> http://wiki.openstreetmap.org/wiki/Relation:waterway
>> il faut y mettre surtout les way waterway=river, stream... le nom de la
>> rivière et le ref:sandre si possible.
>> les riverbank peuvent être ajouté mais avec le role waterbody.
>>
>>  Sinon le nom de la rivière va sur waterway=river, stream... mais je
>> vois pas l'utilité de le mettre en plus sur le riverbank si ce n'est pas
>> le nom d'un plan d'eau différent de la rivière.
>> Et moi je préfère ne pas mélanger les node et way des frontières avec
>> ceux des rivières.
>>
>> Le 12 mai 2015 20:13, Xavier Cremaschi  a écrit :
>>
>>>  Le nom aussi irait sur la relation ? En tout cas merci pour toutes les
>>> infos et vos réponses :)
>>>
>>>
>>>
>>> Le 12/05/2015 16:36, Francescu GAROBY a écrit :
>>>
>>> (J'ai envoyé mon mail trop vite...)
>>> Le wiki dit même que le tag ref:sandre doit être placé sur une relation
>>> 
>>>
>>>  Francescu
>>>
>>> Le 12 mai 2015 16:35, Francescu GAROBY  a écrit :
>>>
 Dans ce cas, fais une relation contenant tous les bouts de rivières et
 c'est sur cette relation que tu appliques le tag ref:sandre.

  Francescu

 Le 12 mai 2015 16:31, Xavier Cremaschi  a écrit :

>  Ok merci, mais donc ça implique de propager les tags de la rivière à
> plusieurs ways ?
>
> Par exemple si je veux rajouter ref:sandre=F---0100 sur la marne, je
> dois le faire sur tous les morceaux de cette rivière, or elle fait plus de
> 500km :/ pas simple
> Mais si je fusionne ces morceaux ça dépassera forcément 2000 points vu
> la longueur du cours d'eau donc pas trop le choix j'imagine.
>
>
>
> Le 12/05/2015 15:41, Francescu GAROBY a écrit :
>
> Bonjour,
> JOSM (ou OSM directement ?) limite les ways à 2000 points, d'où la
> découpe d'un riverbank en plusieurs morceaux.
> De-même, et ça semble être le cas ici, une rivière peut-être coupée
> car certains tronçons servent aussi de frontière.
>
>  Francescu
>
> Le 12 mai 2015 15:33, Xavier Cremaschi  a
> écrit :
>
>>  Une image vaut mieux qu'un long discours...
>>
>>
>>
>> Faut-il fusionner les rivières définies en plusieurs morceaux ? Même
>> question pour les multipolygons waterway=riverbank.
>> Si vous rajoutez un cours d'eau, le faites-vous en plusieurs morceaux
>> ?
>>
>> Merci d'avance,
>> Xavier.
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
>>
>>
>
>
>  --
>  Francescu
>
>
>


   --
  Francescu

>>>
>>>
>>>
>>>  --
>>>  Francescu
>>>
>>>
>>>
>>> ___
>>> Talk-fr mailing list
>>> Talk-fr@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-fr
>>>
>>>
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
>>
>>
>
>
> ___
> Talk-fr mailing 
> listTalk-fr@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-fr
>
>
>
> --
>  Envoyé avec Mozilla Thunderbird ---
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Cours d'eau et fusion

[Philippe Verdy]

Note que passer par un vote n'est vraiment nécessaire que là où on commence
à avoir un conflit d'interprétations et un usage élevé et qu'on veut
normaliser et trier les usages.
Vu le nombre encore peu élevé d'usages (118 pour riverbank depuis
longtemps, 108 pour waterbody depuis décembre seulement, et peut-être des
rôles plus exotiques comme "canalbank" que je n'ai trouvé nulle part en
Belgique...) le vote serait prématuré, mais il est bon de lancer une
discussion sur le sujet !
Ensuite viendra un vote sur les propositions discutées avev leurs avantages
et inconvénients.
Après on pourra normaliser et nettoyer

Le 13 mai 2015 16:35, Jérôme Amagat  a écrit :

> à oui c'est nouveau. je viens de regarder l'historique de la page ça date
> de décembre. Et c'est écrit que ce n'est pas passé par un vote.
> Sur taginfo : https://taginfo.openstreetmap.org/relations/waterway#roles
> une centaine de waterbody et de riverbank.
>
> Le 13 mai 2015 13:16, Philippe Verdy  a écrit :
>
>> C'est nouveau ce rôle "waterbody". Jusqu'à présent je n'avais vu que le
>> rôle "riverbank" dans les relations du linéaire fluviale pour référencer la
>> relation de son surfacique.
>>
>> Et ce même si cette dernière relation surfacique maintenant utilise
>> water=* (parfois avec landuse=water), je n'ai pas vu ces tags mentionner
>> "water=waterbody" en valeur!
>>
>> Le 12 mai 2015 20:44, Jérôme Amagat  a écrit :
>>
>>> il y a une relation spéciale pour les cours d'eau:
>>> http://wiki.openstreetmap.org/wiki/Relation:waterway
>>> il faut y mettre surtout les way waterway=river, stream... le nom de la
>>> rivière et le ref:sandre si possible.
>>> les riverbank peuvent être ajouté mais avec le role waterbody.
>>>
>>> Sinon le nom de la rivière va sur waterway=river, stream... mais je
>>> vois pas l'utilité de le mettre en plus sur le riverbank si ce n'est
>>> pas le nom d'un plan d'eau différent de la rivière.
>>> Et moi je préfère ne pas mélanger les node et way des frontières avec
>>> ceux des rivières.
>>>
>>> Le 12 mai 2015 20:13, Xavier Cremaschi  a écrit
>>> :
>>>
  Le nom aussi irait sur la relation ? En tout cas merci pour toutes les
 infos et vos réponses :)



 Le 12/05/2015 16:36, Francescu GAROBY a écrit :

 (J'ai envoyé mon mail trop vite...)
 Le wiki dit même que le tag ref:sandre doit être placé sur une relation
 

  Francescu

 Le 12 mai 2015 16:35, Francescu GAROBY  a écrit :

> Dans ce cas, fais une relation contenant tous les bouts de rivières et
> c'est sur cette relation que tu appliques le tag ref:sandre.
>
>  Francescu
>
> Le 12 mai 2015 16:31, Xavier Cremaschi  a écrit :
>
>>  Ok merci, mais donc ça implique de propager les tags de la rivière à
>> plusieurs ways ?
>>
>> Par exemple si je veux rajouter ref:sandre=F---0100 sur la marne, je
>> dois le faire sur tous les morceaux de cette rivière, or elle fait plus 
>> de
>> 500km :/ pas simple
>> Mais si je fusionne ces morceaux ça dépassera forcément 2000 points
>> vu la longueur du cours d'eau donc pas trop le choix j'imagine.
>>
>>
>>
>> Le 12/05/2015 15:41, Francescu GAROBY a écrit :
>>
>> Bonjour,
>> JOSM (ou OSM directement ?) limite les ways à 2000 points, d'où la
>> découpe d'un riverbank en plusieurs morceaux.
>> De-même, et ça semble être le cas ici, une rivière peut-être coupée
>> car certains tronçons servent aussi de frontière.
>>
>>  Francescu
>>
>> Le 12 mai 2015 15:33, Xavier Cremaschi  a
>> écrit :
>>
>>>  Une image vaut mieux qu'un long discours...
>>>
>>>
>>>
>>> Faut-il fusionner les rivières définies en plusieurs morceaux ? Même
>>> question pour les multipolygons waterway=riverbank.
>>> Si vous rajoutez un cours d'eau, le faites-vous en plusieurs
>>> morceaux ?
>>>
>>> Merci d'avance,
>>> Xavier.
>>>
>>> ___
>>> Talk-fr mailing list
>>> Talk-fr@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-fr
>>>
>>>
>>
>>
>>  --
>>  Francescu
>>
>>
>>
>
>
>   --
>  Francescu
>



  --
  Francescu



 ___
 Talk-fr mailing list
 Talk-fr@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk-fr


>>>
>>> ___
>>> Talk-fr mailing list
>>> Talk-fr@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-fr
>>>
>>>
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
>>
>>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.opens

Re: [OSM-talk-fr] Cours d'eau et fusion

[Philippe Verdy]

Dans ce cas je complète le wiki pour mentionner "riverbank" qui existait
depuis bien plus longtemps, pour exactement la même chose.
Je continue à préférer le rôle "riverbank" (qui correspond aussi au type de
relation référencé).

Le 13 mai 2015 16:35, Jérôme Amagat  a écrit :

> à oui c'est nouveau. je viens de regarder l'historique de la page ça date
> de décembre. Et c'est écrit que ce n'est pas passé par un vote.
> Sur taginfo : https://taginfo.openstreetmap.org/relations/waterway#roles
> une centaine de waterbody et de riverbank.
>
> Le 13 mai 2015 13:16, Philippe Verdy  a écrit :
>
>> C'est nouveau ce rôle "waterbody". Jusqu'à présent je n'avais vu que le
>> rôle "riverbank" dans les relations du linéaire fluviale pour référencer la
>> relation de son surfacique.
>>
>> Et ce même si cette dernière relation surfacique maintenant utilise
>> water=* (parfois avec landuse=water), je n'ai pas vu ces tags mentionner
>> "water=waterbody" en valeur!
>>
>> Le 12 mai 2015 20:44, Jérôme Amagat  a écrit :
>>
>>> il y a une relation spéciale pour les cours d'eau:
>>> http://wiki.openstreetmap.org/wiki/Relation:waterway
>>> il faut y mettre surtout les way waterway=river, stream... le nom de la
>>> rivière et le ref:sandre si possible.
>>> les riverbank peuvent être ajouté mais avec le role waterbody.
>>>
>>> Sinon le nom de la rivière va sur waterway=river, stream... mais je
>>> vois pas l'utilité de le mettre en plus sur le riverbank si ce n'est
>>> pas le nom d'un plan d'eau différent de la rivière.
>>> Et moi je préfère ne pas mélanger les node et way des frontières avec
>>> ceux des rivières.
>>>
>>> Le 12 mai 2015 20:13, Xavier Cremaschi  a écrit
>>> :
>>>
  Le nom aussi irait sur la relation ? En tout cas merci pour toutes les
 infos et vos réponses :)



 Le 12/05/2015 16:36, Francescu GAROBY a écrit :

 (J'ai envoyé mon mail trop vite...)
 Le wiki dit même que le tag ref:sandre doit être placé sur une relation
 

  Francescu

 Le 12 mai 2015 16:35, Francescu GAROBY  a écrit :

> Dans ce cas, fais une relation contenant tous les bouts de rivières et
> c'est sur cette relation que tu appliques le tag ref:sandre.
>
>  Francescu
>
> Le 12 mai 2015 16:31, Xavier Cremaschi  a écrit :
>
>>  Ok merci, mais donc ça implique de propager les tags de la rivière à
>> plusieurs ways ?
>>
>> Par exemple si je veux rajouter ref:sandre=F---0100 sur la marne, je
>> dois le faire sur tous les morceaux de cette rivière, or elle fait plus 
>> de
>> 500km :/ pas simple
>> Mais si je fusionne ces morceaux ça dépassera forcément 2000 points
>> vu la longueur du cours d'eau donc pas trop le choix j'imagine.
>>
>>
>>
>> Le 12/05/2015 15:41, Francescu GAROBY a écrit :
>>
>> Bonjour,
>> JOSM (ou OSM directement ?) limite les ways à 2000 points, d'où la
>> découpe d'un riverbank en plusieurs morceaux.
>> De-même, et ça semble être le cas ici, une rivière peut-être coupée
>> car certains tronçons servent aussi de frontière.
>>
>>  Francescu
>>
>> Le 12 mai 2015 15:33, Xavier Cremaschi  a
>> écrit :
>>
>>>  Une image vaut mieux qu'un long discours...
>>>
>>>
>>>
>>> Faut-il fusionner les rivières définies en plusieurs morceaux ? Même
>>> question pour les multipolygons waterway=riverbank.
>>> Si vous rajoutez un cours d'eau, le faites-vous en plusieurs
>>> morceaux ?
>>>
>>> Merci d'avance,
>>> Xavier.
>>>
>>> ___
>>> Talk-fr mailing list
>>> Talk-fr@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-fr
>>>
>>>
>>
>>
>>  --
>>  Francescu
>>
>>
>>
>
>
>   --
>  Francescu
>



  --
  Francescu



 ___
 Talk-fr mailing list
 Talk-fr@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk-fr


>>>
>>> ___
>>> Talk-fr mailing list
>>> Talk-fr@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-fr
>>>
>>>
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
>>
>>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Cours d'eau et fusion

[Claude]

Le 13/05/2015 13:16, Philippe Verdy a écrit :
C'est nouveau ce rôle "waterbody". Jusqu'à présent je n'avais vu que 
le rôle "riverbank" dans les relations du linéaire fluviale pour 
référencer la relation de son surfacique.

En Belgique, j'ai vu des rôle  "canalbank".









Et ce même si cette dernière relation surfacique maintenant utilise 
water=* (parfois avec landuse=water), je n'ai pas vu ces tags 
mentionner "water=waterbody" en valeur!


Le 12 mai 2015 20:44, Jérôme Amagat > a écrit :


il y a une relation spéciale pour les cours d'eau:
http://wiki.openstreetmap.org/wiki/Relation:waterway
il faut y mettre surtout les way waterway=river, stream... le nom
de la rivière et le ref:sandre si possible.
les riverbank peuvent être ajouté mais avec le role waterbody.

Sinon le nom de la rivière va sur waterway=river, stream... mais
je vois pas l'utilité de le mettre en plus sur le riverbank si ce
n'est pas le nom d'un plan d'eau différent de la rivière.
Et moi je préfère ne pas mélanger les node et way des frontières
avec ceux des rivières.

Le 12 mai 2015 20:13, Xavier Cremaschi mailto:omega.xav...@gmail.com>> a écrit :

Le nom aussi irait sur la relation ? En tout cas merci pour
toutes les infos et vos réponses :)



Le 12/05/2015 16:36, Francescu GAROBY a écrit :

(J'ai envoyé mon mail trop vite...)
Le wiki dit même que le tag ref:sandre doit être placé sur
une relation


Francescu

Le 12 mai 2015 16:35, Francescu GAROBY mailto:windu...@gmail.com>> a écrit :

Dans ce cas, fais une relation contenant tous les bouts
de rivières et c'est sur cette relation que tu appliques
le tag ref:sandre.

Francescu

Le 12 mai 2015 16:31, Xavier Cremaschi
mailto:xav...@cremaschi.fr>> a écrit :

Ok merci, mais donc ça implique de propager les tags
de la rivière à plusieurs ways ?

Par exemple si je veux rajouter ref:sandre=F---0100
sur la marne, je dois le faire sur tous les morceaux
de cette rivière, or elle fait plus de 500km :/ pas
simple
Mais si je fusionne ces morceaux ça dépassera
forcément 2000 points vu la longueur du cours d'eau
donc pas trop le choix j'imagine.



Le 12/05/2015 15:41, Francescu GAROBY a écrit :

Bonjour,
JOSM (ou OSM directement ?) limite les ways à 2000
points, d'où la découpe d'un riverbank en plusieurs
morceaux.
De-même, et ça semble être le cas ici, une rivière
peut-être coupée car certains tronçons servent aussi
de frontière.

Francescu

Le 12 mai 2015 15:33, Xavier Cremaschi
mailto:omega.xav...@gmail.com>> a écrit :

Une image vaut mieux qu'un long discours...



Faut-il fusionner les rivières définies en
plusieurs morceaux ? Même question pour les
multipolygons waterway=riverbank.
Si vous rajoutez un cours d'eau, le faites-vous
en plusieurs morceaux ?

Merci d'avance,
Xavier.

___
Talk-fr mailing list
Talk-fr@openstreetmap.org

https://lists.openstreetmap.org/listinfo/talk-fr




-- 
Francescu





-- 
Francescu





-- 
Francescu



___
Talk-fr mailing list
Talk-fr@openstreetmap.org 
https://lists.openstreetmap.org/listinfo/talk-fr



___
Talk-fr mailing list
Talk-fr@openstreetmap.org 
https://lists.openstreetmap.org/listinfo/talk-fr




___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr



--
 Envoyé avec Mozilla Thunderbird ---

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Cours d'eau et fusion

[Jérôme Amagat]

à oui c'est nouveau. je viens de regarder l'historique de la page ça date
de décembre. Et c'est écrit que ce n'est pas passé par un vote.
Sur taginfo : https://taginfo.openstreetmap.org/relations/waterway#roles
une centaine de waterbody et de riverbank.

Le 13 mai 2015 13:16, Philippe Verdy  a écrit :

> C'est nouveau ce rôle "waterbody". Jusqu'à présent je n'avais vu que le
> rôle "riverbank" dans les relations du linéaire fluviale pour référencer la
> relation de son surfacique.
>
> Et ce même si cette dernière relation surfacique maintenant utilise
> water=* (parfois avec landuse=water), je n'ai pas vu ces tags mentionner
> "water=waterbody" en valeur!
>
> Le 12 mai 2015 20:44, Jérôme Amagat  a écrit :
>
>> il y a une relation spéciale pour les cours d'eau:
>> http://wiki.openstreetmap.org/wiki/Relation:waterway
>> il faut y mettre surtout les way waterway=river, stream... le nom de la
>> rivière et le ref:sandre si possible.
>> les riverbank peuvent être ajouté mais avec le role waterbody.
>>
>> Sinon le nom de la rivière va sur waterway=river, stream... mais je vois
>> pas l'utilité de le mettre en plus sur le riverbank si ce n'est pas le
>> nom d'un plan d'eau différent de la rivière.
>> Et moi je préfère ne pas mélanger les node et way des frontières avec
>> ceux des rivières.
>>
>> Le 12 mai 2015 20:13, Xavier Cremaschi  a écrit :
>>
>>>  Le nom aussi irait sur la relation ? En tout cas merci pour toutes les
>>> infos et vos réponses :)
>>>
>>>
>>>
>>> Le 12/05/2015 16:36, Francescu GAROBY a écrit :
>>>
>>> (J'ai envoyé mon mail trop vite...)
>>> Le wiki dit même que le tag ref:sandre doit être placé sur une relation
>>> 
>>>
>>>  Francescu
>>>
>>> Le 12 mai 2015 16:35, Francescu GAROBY  a écrit :
>>>
 Dans ce cas, fais une relation contenant tous les bouts de rivières et
 c'est sur cette relation que tu appliques le tag ref:sandre.

  Francescu

 Le 12 mai 2015 16:31, Xavier Cremaschi  a écrit :

>  Ok merci, mais donc ça implique de propager les tags de la rivière à
> plusieurs ways ?
>
> Par exemple si je veux rajouter ref:sandre=F---0100 sur la marne, je
> dois le faire sur tous les morceaux de cette rivière, or elle fait plus de
> 500km :/ pas simple
> Mais si je fusionne ces morceaux ça dépassera forcément 2000 points vu
> la longueur du cours d'eau donc pas trop le choix j'imagine.
>
>
>
> Le 12/05/2015 15:41, Francescu GAROBY a écrit :
>
> Bonjour,
> JOSM (ou OSM directement ?) limite les ways à 2000 points, d'où la
> découpe d'un riverbank en plusieurs morceaux.
> De-même, et ça semble être le cas ici, une rivière peut-être coupée
> car certains tronçons servent aussi de frontière.
>
>  Francescu
>
> Le 12 mai 2015 15:33, Xavier Cremaschi  a
> écrit :
>
>>  Une image vaut mieux qu'un long discours...
>>
>>
>>
>> Faut-il fusionner les rivières définies en plusieurs morceaux ? Même
>> question pour les multipolygons waterway=riverbank.
>> Si vous rajoutez un cours d'eau, le faites-vous en plusieurs morceaux
>> ?
>>
>> Merci d'avance,
>> Xavier.
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
>>
>>
>
>
>  --
>  Francescu
>
>
>


   --
  Francescu

>>>
>>>
>>>
>>>  --
>>>  Francescu
>>>
>>>
>>>
>>> ___
>>> Talk-fr mailing list
>>> Talk-fr@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-fr
>>>
>>>
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
>>
>>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Cours d'eau et fusion

[Philippe Verdy]

C'est nouveau ce rôle "waterbody". Jusqu'à présent je n'avais vu que le
rôle "riverbank" dans les relations du linéaire fluviale pour référencer la
relation de son surfacique.

Et ce même si cette dernière relation surfacique maintenant utilise water=*
(parfois avec landuse=water), je n'ai pas vu ces tags mentionner
"water=waterbody" en valeur!

Le 12 mai 2015 20:44, Jérôme Amagat  a écrit :

> il y a une relation spéciale pour les cours d'eau:
> http://wiki.openstreetmap.org/wiki/Relation:waterway
> il faut y mettre surtout les way waterway=river, stream... le nom de la
> rivière et le ref:sandre si possible.
> les riverbank peuvent être ajouté mais avec le role waterbody.
>
> Sinon le nom de la rivière va sur waterway=river, stream... mais je vois
> pas l'utilité de le mettre en plus sur le riverbank si ce n'est pas le
> nom d'un plan d'eau différent de la rivière.
> Et moi je préfère ne pas mélanger les node et way des frontières avec ceux
> des rivières.
>
> Le 12 mai 2015 20:13, Xavier Cremaschi  a écrit :
>
>>  Le nom aussi irait sur la relation ? En tout cas merci pour toutes les
>> infos et vos réponses :)
>>
>>
>>
>> Le 12/05/2015 16:36, Francescu GAROBY a écrit :
>>
>> (J'ai envoyé mon mail trop vite...)
>> Le wiki dit même que le tag ref:sandre doit être placé sur une relation
>> 
>>
>>  Francescu
>>
>> Le 12 mai 2015 16:35, Francescu GAROBY  a écrit :
>>
>>> Dans ce cas, fais une relation contenant tous les bouts de rivières et
>>> c'est sur cette relation que tu appliques le tag ref:sandre.
>>>
>>>  Francescu
>>>
>>> Le 12 mai 2015 16:31, Xavier Cremaschi  a écrit :
>>>
  Ok merci, mais donc ça implique de propager les tags de la rivière à
 plusieurs ways ?

 Par exemple si je veux rajouter ref:sandre=F---0100 sur la marne, je
 dois le faire sur tous les morceaux de cette rivière, or elle fait plus de
 500km :/ pas simple
 Mais si je fusionne ces morceaux ça dépassera forcément 2000 points vu
 la longueur du cours d'eau donc pas trop le choix j'imagine.



 Le 12/05/2015 15:41, Francescu GAROBY a écrit :

 Bonjour,
 JOSM (ou OSM directement ?) limite les ways à 2000 points, d'où la
 découpe d'un riverbank en plusieurs morceaux.
 De-même, et ça semble être le cas ici, une rivière peut-être coupée car
 certains tronçons servent aussi de frontière.

  Francescu

 Le 12 mai 2015 15:33, Xavier Cremaschi  a
 écrit :

>  Une image vaut mieux qu'un long discours...
>
>
>
> Faut-il fusionner les rivières définies en plusieurs morceaux ? Même
> question pour les multipolygons waterway=riverbank.
> Si vous rajoutez un cours d'eau, le faites-vous en plusieurs morceaux ?
>
> Merci d'avance,
> Xavier.
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>


  --
  Francescu



>>>
>>>
>>>   --
>>>  Francescu
>>>
>>
>>
>>
>>  --
>>  Francescu
>>
>>
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
>>
>>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Cours d'eau et fusion

[Sébastien Dinot]

Francescu GAROBY a écrit :
> JOSM (ou OSM directement ?) limite les ways à 2000 points, d'où la
> découpe d'un riverbank en plusieurs morceaux.

Au delà des limites arbitraires, il faut bien se dire que plus les
objets sont complexes, plus ils sont difficiles à éditer. Il ne faut
donc jamais hésiter à mon sens à fractionner les polygones trop
imposants (qu'il s'agisse de riverbank ou de landuse), même si cela crée
des polygones contigus de même nature. À l'inverse, il faut résister
à la tentation des fusions qui engendrent des mastodontes.

Hier soir, j'ai complété le tracé d'un canal en créant plusieurs
« riverbank » qui n'excédaient pas 60 à 200 nœuds chacun mais dont la
boîte englobante de chacun couvrait un territoire déjà imposant.

Il y a quelques temps, j'ai passé une soirée à découper un polygone
géant (551 km2) en 17 morceaux et à créer autant de relations pour
redistribuer correctement les 385 polygones qu'il incluait.

Sébastien

-- 
Sébastien Dinot, sebastien.di...@free.fr
http://sebastien.dinot.free.fr/
Ne goûtez pas au logiciel libre, vous ne pourriez plus vous en passer !

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Cours d'eau et fusion

[David Crochet]

Bonjour

Le 12/05/2015 20:44, Jérôme Amagat a écrit :

Et moi je préfère ne pas mélanger les node et way des frontières avec
ceux des rivières.


+1.

Cordialement

--
David Crochet

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Cours d'eau et fusion

[Jérôme Amagat]

il y a une relation spéciale pour les cours d'eau:
http://wiki.openstreetmap.org/wiki/Relation:waterway
il faut y mettre surtout les way waterway=river, stream... le nom de la
rivière et le ref:sandre si possible.
les riverbank peuvent être ajouté mais avec le role waterbody.

Sinon le nom de la rivière va sur waterway=river, stream... mais je vois
pas l'utilité de le mettre en plus sur le riverbank si ce n'est pas le nom
d'un plan d'eau différent de la rivière.
Et moi je préfère ne pas mélanger les node et way des frontières avec ceux
des rivières.

Le 12 mai 2015 20:13, Xavier Cremaschi  a écrit :

>  Le nom aussi irait sur la relation ? En tout cas merci pour toutes les
> infos et vos réponses :)
>
>
>
> Le 12/05/2015 16:36, Francescu GAROBY a écrit :
>
> (J'ai envoyé mon mail trop vite...)
> Le wiki dit même que le tag ref:sandre doit être placé sur une relation
> 
>
>  Francescu
>
> Le 12 mai 2015 16:35, Francescu GAROBY  a écrit :
>
>> Dans ce cas, fais une relation contenant tous les bouts de rivières et
>> c'est sur cette relation que tu appliques le tag ref:sandre.
>>
>>  Francescu
>>
>> Le 12 mai 2015 16:31, Xavier Cremaschi  a écrit :
>>
>>>  Ok merci, mais donc ça implique de propager les tags de la rivière à
>>> plusieurs ways ?
>>>
>>> Par exemple si je veux rajouter ref:sandre=F---0100 sur la marne, je
>>> dois le faire sur tous les morceaux de cette rivière, or elle fait plus de
>>> 500km :/ pas simple
>>> Mais si je fusionne ces morceaux ça dépassera forcément 2000 points vu
>>> la longueur du cours d'eau donc pas trop le choix j'imagine.
>>>
>>>
>>>
>>> Le 12/05/2015 15:41, Francescu GAROBY a écrit :
>>>
>>> Bonjour,
>>> JOSM (ou OSM directement ?) limite les ways à 2000 points, d'où la
>>> découpe d'un riverbank en plusieurs morceaux.
>>> De-même, et ça semble être le cas ici, une rivière peut-être coupée car
>>> certains tronçons servent aussi de frontière.
>>>
>>>  Francescu
>>>
>>> Le 12 mai 2015 15:33, Xavier Cremaschi  a écrit
>>> :
>>>
  Une image vaut mieux qu'un long discours...



 Faut-il fusionner les rivières définies en plusieurs morceaux ? Même
 question pour les multipolygons waterway=riverbank.
 Si vous rajoutez un cours d'eau, le faites-vous en plusieurs morceaux ?

 Merci d'avance,
 Xavier.

 ___
 Talk-fr mailing list
 Talk-fr@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk-fr


>>>
>>>
>>>  --
>>>  Francescu
>>>
>>>
>>>
>>
>>
>>   --
>>  Francescu
>>
>
>
>
>  --
>  Francescu
>
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Cours d'eau et fusion

[Xavier Cremaschi]

Le nom aussi irait sur la relation ? En tout cas merci pour toutes les 
infos et vos réponses :)



Le 12/05/2015 16:36, Francescu GAROBY a écrit :

(J'ai envoyé mon mail trop vite...)
Le wiki dit même que le tag ref:sandre doit être placé sur une 
relation 


Francescu

Le 12 mai 2015 16:35, Francescu GAROBY > a écrit :


Dans ce cas, fais une relation contenant tous les bouts de
rivières et c'est sur cette relation que tu appliques le tag
ref:sandre.

Francescu

Le 12 mai 2015 16:31, Xavier Cremaschi mailto:xav...@cremaschi.fr>> a écrit :

Ok merci, mais donc ça implique de propager les tags de la
rivière à plusieurs ways ?

Par exemple si je veux rajouter ref:sandre=F---0100 sur la
marne, je dois le faire sur tous les morceaux de cette
rivière, or elle fait plus de 500km :/ pas simple
Mais si je fusionne ces morceaux ça dépassera forcément 2000
points vu la longueur du cours d'eau donc pas trop le choix
j'imagine.



Le 12/05/2015 15:41, Francescu GAROBY a écrit :

Bonjour,
JOSM (ou OSM directement ?) limite les ways à 2000 points,
d'où la découpe d'un riverbank en plusieurs morceaux.
De-même, et ça semble être le cas ici, une rivière peut-être
coupée car certains tronçons servent aussi de frontière.

Francescu

Le 12 mai 2015 15:33, Xavier Cremaschi
mailto:omega.xav...@gmail.com>> a
écrit :

Une image vaut mieux qu'un long discours...



Faut-il fusionner les rivières définies en plusieurs
morceaux ? Même question pour les multipolygons
waterway=riverbank.
Si vous rajoutez un cours d'eau, le faites-vous en
plusieurs morceaux ?

Merci d'avance,
Xavier.

___
Talk-fr mailing list
Talk-fr@openstreetmap.org 
https://lists.openstreetmap.org/listinfo/talk-fr




-- 
Francescu





-- 
Francescu





--
Francescu


___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Cours d'eau et fusion

[Philippe Verdy]

Sauf pour les cours petits ruisseaux qui n'ont pas encore eu besoin d'être
découpés. Ce sont pourtant les plus nombreux (et de loin!).

Les relations resteront donc longtemps une minorité (tant qu'on ne fera pas
du micromapping aussi sur ces petits ruisseaux, ou qu'on ne passera pas à
l'échelle du découpage parcellaire...

En allant jusqu'à tracer le plus petit bout de clôture ou chaque
canalisation et le détail des composants naturels sur leurs rives, jusqu'à
chaque arbre, ponton, point d'ancrage de ponton, grosse pierre remarquable,
ou inscription dessus, épave ou zone d'éboulis, bout de rive instable sujet
à érosion, ou moindre petit chantier qui temporairement viendrait à
déplacer un peu son cours ou l'enterrer dans des buses pour un culvert
permettant la traversée des tracteurs, du bétail, ou faciliter la vie à
quelques piétons voulant un droit de passage, ou pour un résident voulant
un chemin carossable privé vers sa maison, ou encore pour le dégagement
nécessaire aux réseaux de transport d'énergie ou de communication, ou pour
la connexion du moindre drain ou fossé, ou encore certains découpages
associés à des zones localement réglementées, protégées, polluées,
dangereuses, etc.

En fait peu de fleuves et rivières sont découpées en relations (en gros un
millier en France maximum à vue de nez), mais on a quelques centaines de
milliers de petits ruisseaux (en métropole cele devrait être de l'ordre de
200 000 si on inclue aussi ceux qui sont aujourd'hui enterrés, et ceux qui
ont été construits artificiellement dans et autours des zones habitées,
peut-être plus en comptant aussi tous les fossés et drains, dont l'ordre de
grandeur doit être d'un ou deux milliers par commune, soit à peu près
autant que d'habitants en métropole : toutes les personnes physiques, plus
toutes les personnes morales, entreprises, organisations et collectivités,
ces dernières personnes morales gérant souvent leurs propres réseaux de
petits cours d'eau ou ouvrages associés, on doit tomber à plusieurs
dizaines de millions de tout petits cours d'eau, dont une minorité
seulement est réellement régulée et connue par les agences de bassin qui ne
surveillent que les lieux où ils se déversent dans le réseau public, le
reste étant seulement de la législation ou de la régulation, et des
règlements ou sanctions seulement après incident ou litige !).

Bref on n'ira pas beaucoup plus loin que moins de 1% de relations pour
fleuves et rivières, contre plus de 99% de ruisseaux non découpés. On n'a
pas vraiment été très limitatif dans OSM pour ce qu'on appelle cours d'eau
(waterway).

Et ce n'est pas étonnant étant donnée l'énorme importance vitale et
économique de cette ressource qui fait aussi la richesse de notre pays (ou
de la plupart des pays européens, hors des rares zones très arides du sud
de l'Espagne et des îles, dont l'eau douce doit être amenée du continent ou
provenir du traitement de l'eau de mer ou des eaux usées ou récupérées des
précipitations par des bassins ou cuves de décantation/filtration).
D'autres pays n'ont pas cette chance, et l'eau de surface est rare, l'eau
profonde est là mais encore plus précieuse !


Le 12 mai 2015 16:36, Francescu GAROBY  a écrit :

> (J'ai envoyé mon mail trop vite...)
> Le wiki dit même que le tag ref:sandre doit être placé sur une relation
> 
>
> Francescu
>
> Le 12 mai 2015 16:35, Francescu GAROBY  a écrit :
>
>> Dans ce cas, fais une relation contenant tous les bouts de rivières et
>> c'est sur cette relation que tu appliques le tag ref:sandre.
>>
>> Francescu
>>
>> Le 12 mai 2015 16:31, Xavier Cremaschi  a écrit :
>>
>>>  Ok merci, mais donc ça implique de propager les tags de la rivière à
>>> plusieurs ways ?
>>>
>>> Par exemple si je veux rajouter ref:sandre=F---0100 sur la marne, je
>>> dois le faire sur tous les morceaux de cette rivière, or elle fait plus de
>>> 500km :/ pas simple
>>> Mais si je fusionne ces morceaux ça dépassera forcément 2000 points vu
>>> la longueur du cours d'eau donc pas trop le choix j'imagine.
>>>
>>>
>>>
>>> Le 12/05/2015 15:41, Francescu GAROBY a écrit :
>>>
>>> Bonjour,
>>> JOSM (ou OSM directement ?) limite les ways à 2000 points, d'où la
>>> découpe d'un riverbank en plusieurs morceaux.
>>> De-même, et ça semble être le cas ici, une rivière peut-être coupée car
>>> certains tronçons servent aussi de frontière.
>>>
>>>  Francescu
>>>
>>> Le 12 mai 2015 15:33, Xavier Cremaschi  a écrit
>>> :
>>>
  Une image vaut mieux qu'un long discours...



 Faut-il fusionner les rivières définies en plusieurs morceaux ? Même
 question pour les multipolygons waterway=riverbank.
 Si vous rajoutez un cours d'eau, le faites-vous en plusieurs morceaux ?

 Merci d'avance,
 Xavier.

 ___
 Talk-fr mailing list
 Talk-fr@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk-fr


>>>
>>>
>>>  --
>>>  Francesc

Re: [OSM-talk-fr] Cours d'eau et fusion

[david . crochet]

Bonjour

- Mail original -
De: "Xavier Cremaschi" 

Faut-il fusionner les rivières définies en plusieurs morceaux ? Même question 
pour les multipolygons waterway=riverbank. 
Si vous rajoutez un cours d'eau, le faites-vous en plusieurs morceaux ? 
- Mail original -

Non, je relationne, d'un un whemin ne peut comporter qu'un maximum de  
noeuds, en riverbank, ce seuil risque d'être rapidement atteinds.
De deux, une rivière à des caractéristiques évoluant au cours de son parcours 
(navigabilité, tirant d'eau, tirant d'air, passage en canalisation béton, etc.

Cordialement

-- 
David Crochet



___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Cours d'eau et fusion

[Francescu GAROBY]

(J'ai envoyé mon mail trop vite...)
Le wiki dit même que le tag ref:sandre doit être placé sur une relation


Francescu

Le 12 mai 2015 16:35, Francescu GAROBY  a écrit :

> Dans ce cas, fais une relation contenant tous les bouts de rivières et
> c'est sur cette relation que tu appliques le tag ref:sandre.
>
> Francescu
>
> Le 12 mai 2015 16:31, Xavier Cremaschi  a écrit :
>
>>  Ok merci, mais donc ça implique de propager les tags de la rivière à
>> plusieurs ways ?
>>
>> Par exemple si je veux rajouter ref:sandre=F---0100 sur la marne, je dois
>> le faire sur tous les morceaux de cette rivière, or elle fait plus de 500km
>> :/ pas simple
>> Mais si je fusionne ces morceaux ça dépassera forcément 2000 points vu la
>> longueur du cours d'eau donc pas trop le choix j'imagine.
>>
>>
>>
>> Le 12/05/2015 15:41, Francescu GAROBY a écrit :
>>
>> Bonjour,
>> JOSM (ou OSM directement ?) limite les ways à 2000 points, d'où la
>> découpe d'un riverbank en plusieurs morceaux.
>> De-même, et ça semble être le cas ici, une rivière peut-être coupée car
>> certains tronçons servent aussi de frontière.
>>
>>  Francescu
>>
>> Le 12 mai 2015 15:33, Xavier Cremaschi  a écrit :
>>
>>>  Une image vaut mieux qu'un long discours...
>>>
>>>
>>>
>>> Faut-il fusionner les rivières définies en plusieurs morceaux ? Même
>>> question pour les multipolygons waterway=riverbank.
>>> Si vous rajoutez un cours d'eau, le faites-vous en plusieurs morceaux ?
>>>
>>> Merci d'avance,
>>> Xavier.
>>>
>>> ___
>>> Talk-fr mailing list
>>> Talk-fr@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-fr
>>>
>>>
>>
>>
>>  --
>>  Francescu
>>
>>
>>
>
>
> --
> Francescu
>



-- 
Francescu
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Cours d'eau et fusion

[Francescu GAROBY]

Dans ce cas, fais une relation contenant tous les bouts de rivières et
c'est sur cette relation que tu appliques le tag ref:sandre.

Francescu

Le 12 mai 2015 16:31, Xavier Cremaschi  a écrit :

>  Ok merci, mais donc ça implique de propager les tags de la rivière à
> plusieurs ways ?
>
> Par exemple si je veux rajouter ref:sandre=F---0100 sur la marne, je dois
> le faire sur tous les morceaux de cette rivière, or elle fait plus de 500km
> :/ pas simple
> Mais si je fusionne ces morceaux ça dépassera forcément 2000 points vu la
> longueur du cours d'eau donc pas trop le choix j'imagine.
>
>
>
> Le 12/05/2015 15:41, Francescu GAROBY a écrit :
>
> Bonjour,
> JOSM (ou OSM directement ?) limite les ways à 2000 points, d'où la découpe
> d'un riverbank en plusieurs morceaux.
> De-même, et ça semble être le cas ici, une rivière peut-être coupée car
> certains tronçons servent aussi de frontière.
>
>  Francescu
>
> Le 12 mai 2015 15:33, Xavier Cremaschi  a écrit :
>
>>  Une image vaut mieux qu'un long discours...
>>
>>
>>
>> Faut-il fusionner les rivières définies en plusieurs morceaux ? Même
>> question pour les multipolygons waterway=riverbank.
>> Si vous rajoutez un cours d'eau, le faites-vous en plusieurs morceaux ?
>>
>> Merci d'avance,
>> Xavier.
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
>>
>>
>
>
>  --
>  Francescu
>
>
>


-- 
Francescu
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Cours d'eau et fusion

[Philippe Verdy]

Je pense que là aussi la découpe du riverbank est justifiée (mais pas entre
la rive droite et la rive gauche: personnellement je ne découperais le
riverbank que transversalement au lit, là où cette découpe suit une
fontière rejoignant une des deux rives ou les deux, mais pas de découpe du
riverbank le long du linéaire central du waterway).

En revanche la frontière de commune peut et a avantage à utiliser le
linéaire du waterway (elle le partage un segment du riverbank que sur le
segment rejoignant la rive) : il n'est guère utile de multiplier les lignes
parallèles au centre du cours, sauf là où la frontière administrative est
très éloignée du cours actuel (ce cas se trouve surtout dans les lits de
rivières élargies par la construction de barrages, la frontière ayant été
noyée: la complexité géométrique de cette frontière administrative ne suit
plus l'écoulement naturel qui ne fait pas de façon réaliste les mêmes
zigzags que la frontière administrative).

Le tracé du linéaire du waterway s'en trouvera simplifié (d'autant plus
qu'il est arbitraire, plus ou moins à vue de nez !). Ce waterway peut donc
partager un chemin avec la frontière administrative précise, presque
partout où les deux restent dans la surface du riverbank, hormis les cas
assez rares des frontières administratives noyées qui zigzagent ou créent
des polygones spécifiques dans la surface du riverbank (par exemple pour
une installation portuaire, ou des « bittes » (voir le n.b. ci-dessous)
d'amarrage, zones de bouées, zones de déversements ou de pompages dont une
seule collectivité en a la charge).

Ces deux tracés ne décrochent l'un de l'autre que parce qu'il y a des ilots
ou hauts-fonds ou bancs qui peuvent être parfois découverts (laissant alors
voir un bornage planté dessus (ce peut être les points d'accroches de
bouées, ou des poteaux de signalisation plantés dans un cube de béton
enterré pour résister aux crues et au marnage, ou bien un marquage sur une
installation fixée sur le lit, qui peut être parfois noyée, comme l'arrivée
d'une canalisation de pompage ou de drainage, cependant le marquage des
frontière se fait plutôt par alignement de repères hors d'eau sur les rives
ou sur les ilots, parfois juste par panneau ou marquage sur certains gros
arbres bien plantés dans le lit).

Mais de plus en plus les frontières n'ont même plus de bornage physique
visible sur les rivières: quand il est emporté ou déplacé par une crue
c'est le relevé cartographique avec des points de référence éloignés qui
sert, ce marquage n'est pas restauré.

De plus les collectivités bordant un cours d'eau ou plan d'eau ont
maintenant des obligations pour se partager les charges de l'entretien et
la protection du cours ou plan d'eau: sur le littoral on a la loi littoral,
mais en fait il y a aussi des obligations nationales (ou régionales à
grande échelle via les agences de bassin): cette partie fluviale des
frontières échappe à leur juridiction exclusive: bref si un cours d'eau
vois son lit bouger suite aux crues, on étend si nécessaire la surface du
riverbank, mais la frontière administrative au milieu est de moins en moins
précise (sauf là où il y a des installations physiques pour laquelle une
collectivité est désignée pour en avoir la charge et les éventuels
bénéfices fiscaux associés; mais même dans ce cas où l'installation
générerait des revenus, ils sont partagés au sein de l'agence de bassin qui
répartit aussi les charges entre communes membres).

---

N.b. on écrit « bitte » d'amarrage avec deux T !   ;-)
Et non pas un seul comme je l'ai lu parfois ici ou sur le wiki OSM.
Ce n'est un reproche pour personne, on peut facilement l'oublier à la
frappe, mais le mot saute vite aux yeux quand quelqu'un d'autre le lit. Si
on peut, on corrige pour les lecteurs suivants...


Le 12 mai 2015 15:41, Francescu GAROBY  a écrit :

> Bonjour,
> JOSM (ou OSM directement ?) limite les ways à 2000 points, d'où la découpe
> d'un riverbank en plusieurs morceaux.
> De-même, et ça semble être le cas ici, une rivière peut-être coupée car
> certains tronçons servent aussi de frontière.
>
> Francescu
>
> Le 12 mai 2015 15:33, Xavier Cremaschi  a écrit :
>
>>  Une image vaut mieux qu'un long discours...
>>
>>
>>
>> Faut-il fusionner les rivières définies en plusieurs morceaux ? Même
>> question pour les multipolygons waterway=riverbank.
>> Si vous rajoutez un cours d'eau, le faites-vous en plusieurs morceaux ?
>>
>> Merci d'avance,
>> Xavier.
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
>>
>>
>
>
> --
> Francescu
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Cours d'eau et fusion

[Francescu GAROBY]

Bonjour,
JOSM (ou OSM directement ?) limite les ways à 2000 points, d'où la découpe
d'un riverbank en plusieurs morceaux.
De-même, et ça semble être le cas ici, une rivière peut-être coupée car
certains tronçons servent aussi de frontière.

Francescu

Le 12 mai 2015 15:33, Xavier Cremaschi  a écrit :

>  Une image vaut mieux qu'un long discours...
>
>
>
> Faut-il fusionner les rivières définies en plusieurs morceaux ? Même
> question pour les multipolygons waterway=riverbank.
> Si vous rajoutez un cours d'eau, le faites-vous en plusieurs morceaux ?
>
> Merci d'avance,
> Xavier.
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>


-- 
Francescu
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Cours d'eau et cadastre

[Philippe Verdy]

Le 18 septembre 2012 07:47, Hélène PETIT  a écrit :
> Planifier ce chargement du cadastre dans le rythme de travail est souvent
> difficile, et ça doit être précisé : récemment un nouveau contributeur était
> persuadé que le chargement du cadastre chez lui ne marchait pas, avant de
> réaliser que c'est très très lent chez tout le monde.

En comparaison le cadastre espagnol (directement dsponible en WGS84
sur un serveur TMS) est bien plus rapide, et facile à utiliser. Même
s'il n'a pas autant de données (il 'agit surtout des parcelles
quelques limites administratives, et quelques toponymes et odonymes),
et a des défauts de conflation entre les feuilles cadastrales jointes
dans les mêmes tuiles.

Le jour où le cadastre français proposera une imagerie uniforme en
WGS84 avec fusion des feuilles sans avoir à chercher commune par
commune... Ou alors quand JOSM permettra de convertir directement les
projections cadastrales françaises en images WGS84 directement dans
leur rendu : on peut rêver. Devoir travailler en Lambert est pénible.

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Cours d'eau et cadastre

[Nicolas Dumoulin]

Le mardi 18 septembre 2012 10:00:08 Pieren a écrit :
> 2012/9/18 Nicolas Dumoulin :
> > C'est vrai. Et c'est aussi vrai que le chargement n'est pas aisé.
> > Ça relance l'idée de construire un service TMS/XYZ performant pour le
> > cadastre. Ça serait jouable pour openstreetmap.fr dans le principe ?
> 
> Il faut rappeler ici le caractère illégale de la mise en place d'un
> tel service aurait. Le cadastre ne peut être redistribué que dans un
> produit "composite".

Ha zut, je l'avais oublié ça. Tant pis.
Merci de ta vigilance ;-)

-- 
Nicolas Dumoulin
http://wiki.openstreetmap.org/wiki/User:NicolasDumoulin

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Cours d'eau et cadastre

[Ab_fab]

Concernant la rapidité de chargement du cadastre, est-ce que tu travailles
dessus particulièrement en journée et en semaine ?
J'ai lu que les serveurs côté cadastre "chauffent" pas mal durant les
heures de bureau.
Et de mon côté, qui ne l'utilise que soir et week-end, j'ai rarement été
ennuyé, c'est à dire que le temps de chargement est relativement faible en
comparaison du temps passé à ajouter des infos.

Comme tout est gardé en mémoire en local, une idée peut être de charger la
veille au soir pour ses contributions du lendemain. Pas idéal, j'en conviens


Le 18 septembre 2012 07:47, Hélène PETIT  a écrit :

> Mes conclusions après un paquet d'intégrations de cadastre, étalées sur un
> paquet de mois :
>
> (...)
> Pour le cadastre, par contre, c'est affreusement long, une demi-heure
> parfois, même en zone très rurale (puisqu'un carré de cadastre prend le
> même temps à charger, qu'il y ait dessus une agglomération habitée ou des
> champs à perte de vue).
>
> Planifier ce chargement du cadastre dans le rythme de travail est souvent
> difficile, et ça doit être précisé : récemment un nouveau contributeur
> était persuadé que le chargement du cadastre chez lui ne marchait pas,
> avant de réaliser que c'est très très lent chez tout le monde.
>
> Et ce calque cadastre, on ne doit pas s'en passer, à mon avis.
>
>
> Hélène
>
>
> __**_
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.**org/listinfo/talk-fr
>



-- 
ab_fab 
"Il n'y a pas de pas perdus"
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Cours d'eau et cadastre

[Pieren]

2012/9/18 Nicolas Dumoulin :

> C'est vrai. Et c'est aussi vrai que le chargement n'est pas aisé.
> Ça relance l'idée de construire un service TMS/XYZ performant pour le
> cadastre. Ça serait jouable pour openstreetmap.fr dans le principe ?

Il faut rappeler ici le caractère illégale de la mise en place d'un
tel service aurait. Le cadastre ne peut être redistribué que dans un
produit "composite".

Pieren

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Cours d'eau et cadastre

[Mickaël Guéret]

Le mardi 18 septembre 2012 à 07:47 +0200, Hélène PETIT a écrit :

> Bing, on l'a de suite (mais il faudra ensuite le recaler sur le cadastre).

> Et ce calque cadastre, on ne doit pas s'en passer, à mon avis.
> 
Salut Hélène,

je trouve que ces deux points se discutent.
- Dans mon coin, c'est souvent le cadastre qu'il faut recaler sur Bing.

- du coup, les feuilles cadastrales perdent un peu d'intérêt, je trace
beaucoup plus vite les routes avec Bing, je vais ensuite vérifier sur
place pour compléter l'info : nom des hameaux, maisons isolées, rues,
POI...

cordialement,
Mika_Gueret


___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Cours d'eau et cadastre

[Nicolas Dumoulin]

Le mardi 18 septembre 2012 07:47:01 Hélène PETIT a écrit :
> Et ce calque cadastre, on ne doit pas s'en passer, à mon avis.

C'est vrai. Et c'est aussi vrai que le chargement n'est pas aisé.
Ça relance l'idée de construire un service TMS/XYZ performant pour le 
cadastre. Ça serait jouable pour openstreetmap.fr dans le principe ?

-- 
Nicolas Dumoulin
http://wiki.openstreetmap.org/wiki/User:NicolasDumoulin

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Cours d'eau

[sylvain letuffe]

Le mercredi 1 juin 2011 23:33:40, Vincent Pottier a écrit :
> Bonsoir,
> @Sly,
> C'est rafraîchit tout les combien cette image (s'il y a une périodicité) ?
> http://beta.letuffe.org/ressources/cartes/hydrographie-france.png

Visiblement un bug l'empêchait, j'ai remis la génération de cette image en 
route tous les midis.

--
sly


___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

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

[sly (sylvain letuffe)]

> > 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.

En fait, je devais pas avoir bien cherché, en voulant créer ma page de 
proposition, j'ai simplement trouvé que type=waterway n'était pas du tout 
sorti du chapeau et était déjà là, simple et comme j'imaginais. Impec, je 
vais utiliser ça. (j'ai patché mon osm2pgsql pour qu'il ne l'ignore pas)

Je comprends donc maintenant que le débat est sur la création d'une relation 
pour la rivière au sens très large contenant plein de trucs, et dans une 
logique compatibilité ascendante, je la verrais bien incluant les relations 
type=waterway & type=multipolygon + waterway=river_bank comme membre.

> Ma méthode
> 
> http://www.openstreetmap.org/browse/relation/156145
(...)
> J'essaie de faire du tout-en-un :

 |
 | <- une corde
 o
\ / <- moi
||


> Il me parait pertinent de créer une relation qui représente un objet : 
> la rivière, 
ça, ça me plaît

> et dont les rôles signifient sous quel aspect elle est regardée. 
ça, ça me semble trop attendre des rôles. L'utilisation des données devra donc 
être "aware" de tous les rôles, ça pourquoi pas à la limite, sauf que dans 
les cas actuels le rôle est utilisé pour définir la structure géométrique 
(inner, outer, exclave, etc.) donc il deviendrait tentôt un "regard" tantôt 
un "quelle forme". Imagines que tu as une île sur ta rivière, tu va devoir la 
tagguer inner, sauf qu'il te faut aussi indiquer qu'il s'agit de waterbank, 
sinon l'algo de reconstruction va devoir s'arracher les cheveux pour deviner 
s'il s'agit d'un morceau du lit central ou un morceau de berge (ou un pont 
taggué en mode surface qui enjambe la rivière)

> 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

Certes certes, mais ne divise-t-on pas pour mieux régner ? Je comprends 
l'avantage de ta méthode : le nom n'est qu'a un seul endroit, la ref aussi, 
et dans un monde parfait ce serait l'avenir (quand plein d'outil magique 
gérerons), mais entre temps ça me semble dur à utiliser et un tros gros saut.

Donc l'idée de une relation type=river qui contient des relations formant les 
géométries aurait ma préférence.


> [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.

Marrant, moi je commence à douter ;-)

> [2] J'éviterai toutefois le type route 

Je connaissais pas type=waterway, ça me semble plus logique je vais prendre ça


-- 
sly
Sylvain Letuffe sylv...@letuffe.org
qui suis-je : http://slyserv.dyndns.org



___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Cours d'eau, relations, river bank - dessines moi de l'eau !

[sylvain letuffe]

Le jeudi 15 juillet 2010 23:44:25, Christian Quest a écrit :
> Ce genre de liste permet de voir l'avancée du travail de cartographie. Le
> site du SANDRE indique les longueurs des différents cours d'eau, cela
> permet de comparer avec la longueur actuellement présente dans OSM.

ça, je peux faire la même chose qu'avec les communes : si j'ai la liste sandre 
avec longueur et reférence sandre, et qu'on le saisie dans osm avec 
ref:sandre, alors no problème je peux faire un p'tit état de l'avancement 
cours d'eau longeur_osm/longeur_sandre

je vais regarder...

 
> Je n'ai mis que les waterway=river dans la relation, une autre relation
> pourrait reprendre les riverbank.

très bonne idée selon moi de ne pas mélanger.

> 
> Par contre je rencontre un problème, l'Yonne et la Canal du Nivernais (qui
> relie la Loire à la Seine via l'Yonne) partagent de nombreuses sections.

Avec une relation ;-), c'est sans problèmes non ?

--
sly



___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

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

[sylvain letuffe]

Le jeudi 15 juillet 2010 23:37:15, Pierre-Alain Dorange a écrit :
> Je suis aussi informaticien mais ça n'empêche pas d'utiliser des
> listes de références (wikipédia ou le wiki osm peuvent faire l'affaire).

Je plaisantais bien sûr, pas de rancune ? ;-)
je voulais dire que si on peut automatiser, autant le faire, surtout que si 
finalement on veut les +50 et -80, rien de tel que petit "if".

> Surtout que là il n'y a rien qui distingue un fleuve d'une rivière à
> ce jour dans osm (river tout les 2)...

là, je suis bien d'accord, et la longueur ne suffit pas. (Quoi que, un fleuve 
se 
jette dans la mer ? on peut peut-être faire le calcul d'intersection ;-) )

--
sly


___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

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

[Pierre-Alain Dorange]

Le 15 juil. 10 à 23:44, Christian Quest a écrit :

Ayant pas mal fait d'ajout autour de l'Yonne, j'ai créé une relation  
comme indiqué et rajouté l'Yonne dans les rivières de plus de 100km  
(292km).


Tu as bien fait, mais l'Yonne est une rivière la liste était les  
fleuves, mais y'a pas de raison puisque certaines rivières sont plus  
longues que certains fleuves... (je me comprend).
Je change donc le titre et il faudrait ajouter ou il se jette dans ce  
cas.


Ce genre de liste permet de voir l'avancée du travail de  
cartographie. Le site du SANDRE indique les longueurs des différents  
cours d'eau, cela permet de comparer avec la longueur actuellement  
présente dans OSM.


Je n'ai mis que les waterway=river dans la relation, une autre  
relation pourrait reprendre les riverbank.


Par contre je rencontre un problème, l'Yonne et la Canal du  
Nivernais (qui relie la Loire à la Seine via l'Yonne) partagent de  
nombreuses sections. Il était d'ailleurs intégralement cartographié,  
avec les écluses et leurs fréquences VHF. J'ai aussi créé une  
relation pour ce canal vu qu'il n'y en avait pas.


Plus bas il y a une liste des canaux.

--
Pierre-Alain Dorange,
Blog Citoyen de Cognac : 
Twitter :  - Facebook : 


___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

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

[sylvain letuffe]

Le jeudi 15 juillet 2010 21:52:27, Vincent Pottier a écrit :
> > entre ceux qui voudraient une relation qui contienne le nombre de canard
> > par km^2

> 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é.

ça doit être parce que je comprends mal l'anglais, mais tu avouera que dans 
ton envolée lirique, si tu n'as pas mentionné les canards, tu n'es pas passé 
loin :
http://wiki.openstreetmap.org/wiki/Talk:WikiProject_Rivers
VP : "Because a river is a complex with (...) * an area: made by areas,
(...) where we can swim or not, fish or not (...) Because the world is rich and 
complex and openStreetMap is ambitious."

Loin de moi à penser que ces choses n'ont pas raison de figurer dans une méga 
relation de la mort qui tue, mais je pense qu'il est aussi nécessaire de 
segmenter la chose pour la rendre utilisable. Pitié, pense à ceux qui écrivent 
des scripts en python, des requêtes longues comme le bras et des p...@$*#~ de 
styles mapnik.

On ne taggue pas pour un outil précis pour faire plaisir à un développeur 
feignant, mais je pense qu'il faut que ça reste utilisable, s'il faut un 
programme à intelligence artificielle pour en venir à bout après 2 semaines de 
calcul, on rend la donné vraiment dure à exploiter.
 
> 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.

Il est borné, tant pis pour lui, l'idée est bonne, je pense qu'il faut juste 
segmenter.
 
> > défini un truc de dingue en incluant et sans détruire le truc simple.
> 
> Ok, on fait comme ça. Yaka.

Yaka... jvéfaire, je suis un habitué des propositions qui n'aboutissent 
jamais.

Je vois un truc avec une relation de fou genre type=river qui contient les 
canards, les poissons, les écluses mais qui contient des éléments utilisables 
indépendament que sont :
- la relation faite de ways qui forme la longue ligne de la source à 
l'embouchure (role=center_stream, type=waterway)
- la relation faite de ways qui forme la surface haute de la rivière 
(role=max_water_bed, type=multipolygon+waterway=riverbank, constituant 
l'ensemble de la rivière et/ou les ensembles puzzle qui forme la rivière)
- ...

L'avantage est que les sous-relations seraient utilisable telle quelle sans 
fioritures, et je pourrais faire "simplement" mon rendu en utilisant juste les 
type=waterway, sans devoir deviner selon les 100 roles possibles passés et à 
venir, s'il s'agit d'un morceau de berge, de pont ou du lit principal.

> [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.

Ma foi, va pour type=waterway, c'est juste que j'avais trouvé bien l'idée que 
"type" définisse simplement la forme totale attendue par la relation et 
permette ainsi des outils généraux pour traiter les erreurs.
type=multipolygon -> contour(s) fermé(s)
type=linestring (oups, route) -> ligne(s) brisée(s)

--
sly


___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

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

[Christian Quest]

Ayant pas mal fait d'ajout autour de l'Yonne, j'ai créé une relation comme
indiqué et rajouté l'Yonne dans les rivières de plus de 100km (292km).

Ce genre de liste permet de voir l'avancée du travail de cartographie. Le
site du SANDRE indique les longueurs des différents cours d'eau, cela permet
de comparer avec la longueur actuellement présente dans OSM.

Je n'ai mis que les waterway=river dans la relation, une autre relation
pourrait reprendre les riverbank.

Par contre je rencontre un problème, l'Yonne et la Canal du Nivernais (qui
relie la Loire à la Seine via l'Yonne) partagent de nombreuses sections. Il
était d'ailleurs intégralement cartographié, avec les écluses et leurs
fréquences VHF. J'ai aussi créé une relation pour ce canal vu qu'il n'y en
avait pas.

--
Christian
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

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

[Pierre-Alain Dorange]

Le 15 juil. 10 à 23:22, sylvain letuffe a écrit :

Je suis informaticien moi ! Ma religion m'interdit de préparer un  
rendu en
listant à la main les 30 rivières/fleuves à représenter. Les "+ de  
100km" je
peux les déterminer automatiquement par calcul, je vais pas m'en  
priver.



Je suis aussi informaticien mais ça n'empêche pas d'utiliser des  
listes de références (wikipédia ou le wiki osm peuvent faire l'affaire).
Surtout que là il n'y a rien qui distingue un fleuve d'une rivière à  
ce jour dans osm (river tout les 2)...
Mais c'est sur que le calcul de la longueur d'une rivière à partir de  
sa relation est intéressant ;-)


--
Pierre-Alain Dorange,
Blog Citoyen de Cognac : 
Twitter :  - Facebook : 


___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

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

[sylvain letuffe]

Le jeudi 15 juillet 2010 19:30:54, Pierre-Alain Dorange a écrit :
> Ma méthode (La Charente :
> http://www.openstreetmap.org/browse/relation/961832) c'est de mettre le
> way du lit principal dans une relation pour avoir le tracé global du
> fleuve.

ça me semble bien fait et utilisable, je crois que en abscence de consensus 
internationnal je vais faire ça, comme dit ici : 
http://wiki.openstreetmap.org/wiki/WikiProject_France/Cours_d%27eau


> Ensuite si je dessine les riverbank et que je m'attaque maintenant aux
> seuils et écluses je ne les met pas dans la relation pour l'instant.
> Il me semble plus simple de ne laisser que l'essentiel : le lit
> principal du fleuve (waterway=river).
> Mais on pourrait imaginer d'y accoler pleins de choses (riverbank,
> lock, weir...) mais il faudra définir des rôles un peu cohérent avant.

Je pense qu'un fourre tout n'est pas souhaitable, il serait très difficile d'en 
extraire les éléments. Je vois plus la chose sous forme de relation de 
relation. (cf mail d'après)

> PS : concernant ton soucis de représenter les grands fleuves, j'ai
> commencé a mettre à jour la page wiki du projet france avec la liste
> des fleuves (de plus de 100 km pour l'instant) avec ce que j'ai pu
> agrégé a ce jour :
>  _Fleuves_.28.3E_100_km.29

Je suis informaticien moi ! Ma religion m'interdit de préparer un rendu en 
listant à la main les 30 rivières/fleuves à représenter. Les "+ de 100km" je 
peux les déterminer automatiquement par calcul, je vais pas m'en priver.

--
sly


___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

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

[Pierre-Alain Dorange]

Le 15 juil. 10 à 21:52, Vincent Pottier a écrit :

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 ?)



Pourquoi utilises tu le rôle waterbank ?
Il existe riverbank qui convient à priori, c'est en tout cas celui que  
je comptais utiliser pour les riverbank de la Charente.
Je note que ces "area" (way fermé) sont bien indiqué comme  
waterway=riverbank...


En tout cas une bien jolie rivière.

--
Pierre-Alain Dorange,
Blog Citoyen de Cognac : 
Twitter :  - Facebook : 


___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [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 10 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 
10 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

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

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

[Pierre-Alain Dorange]

Le 15 juil. 10 à 18:59, sly (sylvain letuffe) a écrit :

Le consensus c'est alors : pas de multi ? chacun son truc ? ou :  
sly, tu nous

fais chier ! ;-)



Ma méthode (La Charente : http://www.openstreetmap.org/browse/relation/961832) 
 c'est de mettre le way du lit principal dans une relation pour avoir  
le tracé global du fleuve.
Ensuite si je dessine les riverbank et que je m'attaque maintenant aux  
seuils et écluses je ne les met pas dans la relation pour l'instant.
Il me semble plus simple de ne laisser que l'essentiel : le lit  
principal du fleuve (waterway=river).
Mais on pourrait imaginer d'y accoler pleins de choses (riverbank,  
lock, weir...) mais il faudra définir des rôles un peu cohérent avant.


J'y ait réfléchit (un peu) récemment et je me demandais si il ne  
serait pas aussi intéressant (dans un deuxième temps) de créer une  
autre relation pour le Bassin du fleuve qui inclurait la relation des  
way du fleuve ainsi que celles des affluents, ce qui permettrait avec  
une relation de dessiner tout un bassin. je pense sur j'essayerai plus  
tard (faut déjà que je finisse le fleuve) et ensuite j'attaquerai les  
affluents principaux.


PS : concernant ton soucis de représenter les grands fleuves, j'ai  
commencé a mettre à jour la page wiki du projet france avec la liste  
des fleuves (de plus de 100 km pour l'instant) avec ce que j'ai pu  
agrégé a ce jour :

On y trouve quelques relations qui semble construite a peu près sur le  
même modèle (uniquement le waterway), même si certain (La Loire par  
exemple) ont quelques riverbank en rôle. Y'a la relation Rhône qui est  
un peu a part : seulement 2 petit riverbank c'est un peu léger...


--
Pierre-Alain Dorange,
Blog Citoyen de Cognac : 
Twitter :  - Facebook : 


___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] cours d'eau et referentiel Sandre

[Guillaume Allegre]

Le Wed 13 Jan 2010 à 01:19 +0100, Vincent Pottier a ecrit :

> Moi je ne sais faire que des requêtes /relation/gnagna/full
> Donc je mets les riverbanks dans la relation avec le rôle "riverbank".
> C'est pas très malin, mais c'est efficace et si c'est une info
> calculable, ça n'est pas un info redondante.

Je suis d'accord avec toi, et je vais probablement faire comme ça aussi.


-- 
 ° /\Guillaume AllègreMembre de l'April
  /~~\/\   allegre.guilla...@free.fr  Promouvoir et défendre le logiciel libre
 /   /~~\tél. 04.76.63.26.99  http://www.april.org

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] cours d'eau et referentiel Sandre

[Vincent Pottier]

Mathieu Arnold a écrit :
> +--On 12 janvier 2010 20:24:26 +0100 Guillaume Allegre
>  wrote:
> | Le Tue 12 Jan 2010 à 20:07 +0100, Mathieu Arnold a ecrit :
> | 
> |> J'allais répondre, mais j'ai vu qu'on a déjà donné la réponse :-)
> |> J'ai récement fait 80 bornes d'un affluent de La Garonne, le Dropt, en
> |> me basant sur ce que j'ai trouvé dans le wiki :
> |> http://www.openstreetmap.org/browse/relation/375959
> |> Si ça peut te donner une idée des trucs à faire :-)
> | 
> | Bon, ben j'en apprends encore.
> | 
> | J'avais jamais percuté que quand on trace les berges (riverbanks), 
> | il faut AUSSI tracer l'axe (en river). 
> | C'est d'ailleurs un peu fastidieux, mais bon. 
> | 
> | Du coup, dans la relation, on met uniquement les tronçons
> | de river, ou aussi les riverbanks ?
> | La page http://wiki.openstreetmap.org/wiki/WikiProject_Rivers
> | ne précise rien.
> | Dans la relation que tu donnes, il n'y a que les rivers, mais
> | ça me semble bizarre : si on veut "recoller" toutes les informations
> | un jour, il faut bien que les riverbanks fassent partie de la relation
> | (ou portent le tag ref:sandre), non ?
>
> Non, ils ne portent que le nom du cours d'eau, effectivement, il n'y a rien
> de précisé sur la page, j'ai hésité, et puis j'ai voté contre le fait
> de les mettre, l'ensemble des river décrivent le cours d'eau, c'est le lit
> qui est important, par les rives, et puis, je n'avais pas envie d'inventer
> un role pour les berges dans la relation :-)
>
>   
http://wiki.openstreetmap.org/wiki/Talk:WikiProject_Rivers#Why_relations_at_all.3F

Il y a eu une (forte) discussion pour savoir si une relation était
nécessaire après tout.

Il est vrai qu'un bon outil logiciel bien maîtrisé sait recoller les
bouts de la rivière comme il sait recoler les bouts de la D223 pour en
faire une route. Si cet outil est très bien maîtrise, il saura aussi
retrouver les riverbanks de la rivière. comme le parking et la voie de
service. S'il et très très bien maîtrisé, il trouvera le moulin,
l'écluse, le barrage... bref, la vie de la rivière comme les arrêts de
bus, les stations services le long de la route.

Moi je ne sais faire que des requêtes /relation/gnagna/full
Donc je mets les riverbanks dans la relation avec le rôle "riverbank".
C'est pas très malin, mais c'est efficace et si c'est une info
calculable, ça n'est pas un info redondante.

Ceux qui le veulent pourront se passer de l'info et faire tourner leur
matière grise et leurs ordis. Et ils auront droit à toute ma
considération pour leur habileté. (ce sera un plugin pour Étienne pour
un calcul de cohérence sur osmose ;-)
-- 
Vincent alias FrViPofm

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] cours d'eau et referentiel Sandre

[Mathieu Arnold]

+--On 12 janvier 2010 20:24:26 +0100 Guillaume Allegre
 wrote:
| Le Tue 12 Jan 2010 à 20:07 +0100, Mathieu Arnold a ecrit :
| 
|> J'allais répondre, mais j'ai vu qu'on a déjà donné la réponse :-)
|> J'ai récement fait 80 bornes d'un affluent de La Garonne, le Dropt, en
|> me basant sur ce que j'ai trouvé dans le wiki :
|> http://www.openstreetmap.org/browse/relation/375959
|> Si ça peut te donner une idée des trucs à faire :-)
| 
| Bon, ben j'en apprends encore.
| 
| J'avais jamais percuté que quand on trace les berges (riverbanks), 
| il faut AUSSI tracer l'axe (en river). 
| C'est d'ailleurs un peu fastidieux, mais bon. 
| 
| Du coup, dans la relation, on met uniquement les tronçons
| de river, ou aussi les riverbanks ?
| La page http://wiki.openstreetmap.org/wiki/WikiProject_Rivers
| ne précise rien.
| Dans la relation que tu donnes, il n'y a que les rivers, mais
| ça me semble bizarre : si on veut "recoller" toutes les informations
| un jour, il faut bien que les riverbanks fassent partie de la relation
| (ou portent le tag ref:sandre), non ?

Non, ils ne portent que le nom du cours d'eau, effectivement, il n'y a rien
de précisé sur la page, j'ai hésité, et puis j'ai voté contre le fait
de les mettre, l'ensemble des river décrivent le cours d'eau, c'est le lit
qui est important, par les rives, et puis, je n'avais pas envie d'inventer
un role pour les berges dans la relation :-)

-- 
Mathieu Arnold

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] cours d'eau et referentiel Sandre

[Guillaume Allegre]

Le Tue 12 Jan 2010 à 20:07 +0100, Mathieu Arnold a ecrit :

> J'allais répondre, mais j'ai vu qu'on a déjà donné la réponse :-)
> J'ai récement fait 80 bornes d'un affluent de La Garonne, le Dropt, en me
> basant sur ce que j'ai trouvé dans le wiki :
> http://www.openstreetmap.org/browse/relation/375959
> Si ça peut te donner une idée des trucs à faire :-)

Bon, ben j'en apprends encore.

J'avais jamais percuté que quand on trace les berges (riverbanks), 
il faut AUSSI tracer l'axe (en river). 
C'est d'ailleurs un peu fastidieux, mais bon. 

Du coup, dans la relation, on met uniquement les tronçons
de river, ou aussi les riverbanks ?
La page http://wiki.openstreetmap.org/wiki/WikiProject_Rivers
ne précise rien.
Dans la relation que tu donnes, il n'y a que les rivers, mais
ça me semble bizarre : si on veut "recoller" toutes les informations
un jour, il faut bien que les riverbanks fassent partie de la relation
(ou portent le tag ref:sandre), non ?


-- 
 ° /\Guillaume AllègreMembre de l'April
  /~~\/\   allegre.guilla...@free.fr  Promouvoir et défendre le logiciel libre
 /   /~~\tél. 04.76.63.26.99  http://www.april.org

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] cours d'eau et referentiel Sandre

[Guillaume Allegre]

Le Tue 12 Jan 2010 à 19:36 +0100, Frédéric Rodrigo a ecrit :

> http://wiki.openstreetmap.org/wiki/WikiProject_France/Cours_d%27eau
> Pas un mot de plus ;)

OK, désolé d'avoir raté ça. J'ai cherché une page avec "hydrographie", et 
j'ai rien trouvé.
C'était donc une bonne idée ;-)

Seul truc qui me soucie : la page indique qu'il faut baliser la relation, 
et pas le(s) way(s).
Est-ce que c'est valable même s'il n'y a qu'un morceau dans le waterway ?
(un waterway=stream complet par exemple). Plus précisément est-ce qu'on
est obligé de créer une relation, alors qu'il y a un seul membre dedans ?


-- 
 ° /\Guillaume AllègreMembre de l'April
  /~~\/\   allegre.guilla...@free.fr  Promouvoir et défendre le logiciel libre
 /   /~~\tél. 04.76.63.26.99  http://www.april.org

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] cours d'eau et referentiel Sandre

[Mathieu Arnold]

+--On 12 janvier 2010 19:33:08 +0100 Guillaume Allegre
 wrote:
| Salut,
| 
| Le SANDRE (Service d’Administration Nationale des Données et
| Référentiels sur l’Eau) fournit un référentiel avec une
| fiche-rivière pour chaque cours d'eau français. Un exemple pour
| l'Aigues :
| http://sandre.eaufrance.fr/app/chainage/courdo/htm/V53-0400.php?cg=V53-04
| 00
| 
| Ma proposition est d'ajouter un tag ref:SANDRE=Vxxx 
| sur les cours d'eau référencés.
| Eventuellement aussi un tag url=* correspondant.
| Qu'en pensez-vous ?

J'allais répondre, mais j'ai vu qu'on a déjà donné la réponse :-)
J'ai récement fait 80 bornes d'un affluent de La Garonne, le Dropt, en me
basant sur ce que j'ai trouvé dans le wiki :
http://www.openstreetmap.org/browse/relation/375959
Si ça peut te donner une idée des trucs à faire :-)

-- 
Mathieu Arnold

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] cours d'eau et referentiel Sandre

[Frédéric Rodrigo]

Le mardi 12 janvier 2010 19:33:08, Guillaume Allegre a écrit :
> Salut,
> 
> Le SANDRE (Service d’Administration Nationale des Données et Référentiels
>  sur l’Eau) fournit un référentiel avec une fiche-rivière pour chaque cours
>  d'eau français. Un exemple pour l'Aigues :
> http://sandre.eaufrance.fr/app/chainage/courdo/htm/V53-0400.php?cg=V53-0400
> 
> Ma proposition est d'ajouter un tag ref:SANDRE=Vxxx
> sur les cours d'eau référencés.
> Eventuellement aussi un tag url=* correspondant.
> Qu'en pensez-vous ?
> 
> 
> J'ai vu qu'Alban s'était intéressé à l'importation de la BD Carthage.
> Le référencement des données hydro déjà présentes serait un premier pas
> pour faciliter l'import éventuel.
> 

http://wiki.openstreetmap.org/wiki/WikiProject_France/Cours_d%27eau
Pas un mot de plus ;)
My 2cents
Fred

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr