Le 06/06/2010 12:44, sylvain letuffe a écrit : > Selon moi, cette méthode n'a plus de raisons d'être utilisée, si ce n'est > l'habitude. > Pas seulement, voir plus loin > Lobying contre : > > * Les zones d'interconnexion entre plusieurs multipolygone sont tout à fait > arbitraire et ne correspondent à rien de réél > > * S'il me prend de vouloir représenter les bords du fleuve en bleu foncé, > c'est > très galère car je vais introduire des coupures le long du lit de la rivière > aux endroits "qui font le collage" > > * Le nom de la rivière doit être indiqué sur chaqu'un des morceaux qui la > compose > > * Si je veux obtenir dans un format vectoriel la forme complète de la rivière, > je suis obligé de récupérer à la main, tous les morceaux, faire des découpes > et re-collage > > je ne suis pas seul à penser ça : > http://lists.openstreetmap.org/pipermail/talk/2008-February/023009.html > > Et j'utilise plus volontier la logique déjà bien utilisée (ailleurs en tout > cas) des multipolygones : > http://wiki.openstreetmap.org/wiki/Relations/Proposed/Rivers > Le problème, c'est que le tout ne forme pas un multipolygon valide au sens OSM > du terme (ni au sens GIS du terme d'ailleurs) > Sly, tu as raison, en partie : le tag riverbank pour cartographier des plans d'eau tel qu'utilisés couramment n'est pas exact. Le tag devrai être une traduction anglaise de "plan d'eau sur rivière". Le rendu mapnik est celui d'un area alors que "riverbank" désigne un way. L'usage du multipolygone semblerait plus exact, comme pour les "boundary" Seulement... Un multypolygone "riverbank" n'est jamais fermé : il y a des confluents. Et au confluent, la limite du fleuve ou de la rivière n'est plus un "riverbank". Pour fermer le multipolygone, je devrais mettre un way dans le confluent du Rhône et de la Saône, ce qui ferait un vilain trait au milieu de l'eau. (Déjà que, à Lyon, il y a quelque chose de spécifique au milieu du Rhône et de la Saône au dessus de l'eau (de l'o) : un accent circonflexe)
Tout ça pour dire que la solution du multipolygone n'est pas complètement satisfaisante non plus, ni formellement, ni pour le rendu. Donc la solution adoptée, pragmatique, est de sectionner le fleuve et d'utiliser le "riverbank" comme un area, ce qui le rend plus maitrisable sur des longues distance, de le rendre moins fragile aux erreurs (la moindre erreur fout en l'air l'ensemble du multipolygone). Pas satisfaisant, mais plus maniable. -- FrViPofm _______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
