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