Les multipolygons des riverbanks arrivent justement parce que tous les riverbanks ne sont pas des polygones fermés et ont du à un moment être découpés (à cause des difficultés liées aux superpositions des ways avec divers autres polygons attenants, mais aussi parce qu'il y a assez souvent aussi des iles à exclure au milieu). Globalement les riverbanks doivent être tagués comme surfaces. Mais leur géométrie cadre mal avec le filaire (qui en sont une version simplifiée) et ont aussi des relations optionelles pour les grouper, et aussi les associer entre eux (par des membres "tributary", spécifiques qux relations waterway=*, mais non compatibles avec les relations multipolygon). On ne peut pas mélanger les ways du filaire et les ways des multipolygon, cela donne des anomalies entre plus critiques. Si on change le type de relation waterway en multipolygon, ce multipolygon se retrouve avec des ways "inner" et "outer" et souvent aussi d'autres sans role, pour les riverbanks; mais en plus aussi pour le filaire des ways membres "main_stream" et "secondary_stream", mais encore assez souvent des ways sans rôle, sui du coup sont ambigus entre l'interprétation surfacique et l'interprétation filaire.) Enfin on trouve assez souvent des ways partagés entre le filaire (waterway=*) et le surfacique (water=riverbank) dans des sections étroites. C'est difficile de faire cohabiter les deux sans créer diverses anomalies de géométrie. Je pense que les relations séparées se justifient et c'est plutôt Poitron qui a des problèmes à distinguer les deux types et tente de tout mélanger. On voit ce que cela provoque chez lui. Il vaut mieux avoir deux relations (d'autant plus que les surfaces des "riverbank" ne sont pas toujours contigues, car il peut y avoir des parties de cours d'eau souterraines ou parce que tout le cours d'eau n'a pas été tagué avec des riverbanks : typiquement pas pour les parties en amont et diverses sources) Les relations filaires contiennent aussi d'autres membres optionnels : un ou plusieurs noeuds de rôle "stream" pour la ou les sources, un membre relation de rôle "riverbank" associant la relation "riverbank" collectant toutes les surfaces). Je pense que c'est une mauvaise idée de tout mélanger dans une seule relation, cela posera encore plus de problèmes. Ton problème est plutôt une anomalie spécifique du rendu Positron qui tente d'interpréter ou "réparer" à sa façon. Les relations "multipolygon" des surfaces riverbank sont plutôt à laisser inchangés et entièrement compatibles avec les polygones fermés simples, la transformation de l'un en l'autre étant possible à tout moment, mais ne doivent avoir aucun membre supplémentaire (chemins "main_stream", noeuds "stream", relation "tributary", qui sont pour les relations filaires, où les chemins membres "*_stream" sont tous orientés, contrairement aux chemins membres des relations multipolygon de surface). La complétude du filaire est également bien plus avancée (que celle des surfaces), elle forme un réseau (ce n'est pas le cas des surfaces riverbank qui sont toutes parcellaires). La priorité est donnée encore au filaire des relations "waterway" qui devrait être interconnecté en réseau orienté. les surfaces c'est un "luxe" supplémentaire ajouté séparément pour représenter autre chose (globalement l'utilisation du sol).
Le jeu. 18 oct. 2018 à 23:57, François Lacombe <fl.infosrese...@gmail.com> a écrit : > Bonsoir, > > Une petite question sur les deux relations qui qualifient Le Rhône : > La 1ere pour sur le filaire river : > https://www.openstreetmap.org/way/34907146 > La 2nd sur le riverbank, un multipolygon sur tout le court du fleuve : > https://www.openstreetmap.org/relation/660056 > > Je ne comprends pas l'intérêt de la deuxième. > Ne faudrait-il pas mettre le wikidata sur la 1ere relation et supprimer la > 2nde pour ne laisser que des polygones riverbanks continus sans relation ? > > On dirait que ça met le bazar sur des rendus comme Positron : > https://www.maptiler.com/maps/#positron//vector/15.12/5.81699/46.054843 > (même si on ne tag pas pour le rendu) > > Merci par avance pour vos retours, bonne soirée > > François > _______________________________________________ > 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
