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
_______________________________________________
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr
