|
bonjour, Vous faites erreur. la relation est constituée de ways fermé OUTER et non pas de ways ouvert OUTER. ça change tout. En plus, et comme le wiki le demande, les ways fermés OUTER ( qui n'ont pas changés ) sont taggués sur l'objet en waterway=riverbank Ce sont les iles INNER qui posaient problèmes car non pris en compte dans le schema nouveau : natural=water + water=river Je comprend votre confusion vu que sur le wiki il est décrit 2 schémas mais avec plusieurs méthodes. les ways fermés et les ways ouvert Cependant, comme Christian, je ne comprend pas pourquoi les iles ne seraient pas rendus avec le schema natural=water .... C'est pourtant les cas. J'ai laissé durant 1 semaine ce schema en place, et les iles n'apparaissaient pas. Mais dés replacement du schema waterway=riverbank dans la relation, les iles sont réapparues assez rapidement (1 jour pour les tuiles souvent appellées) si je me suis planté, je ne vois pas ou... En tout cas ça remarche ! djo_man Le 07/02/2014 10:44, Pieren a écrit :
2014-02-07 10:32 GMT+01:00 Frédéric Rodrigo <fred.rodr...@gmail.com>:Le lit de rivière est une entité unique.Oui, la forêt amazonienne aussi. Ca n'est pas une raison pour faire un seul polygone qui couvrirait le cinquième de l'amérique du sud (au pif). Il faut parfois être pragmatique. Il n'y a aucune nécessité à faire un seul polygone pour les riverbank. Alors si on peut l'éviter, autant revenir à quelque chose de plus facile à maintenir pour les contributeurs (je dis bien "si on a le choix", ce qui n'est pas toujours possible). Je ne parle pas de rendu ici mais de difficulté à maintenir les grosses relations en général (c'est vrai aussi pour les itinéraires "type=route"). J'imagine bien que ça peut poser quelques difficultés supplémentaires pour les consommateurs de données qui devront faire une requête spatiale un peu compliquée pour récupérer tous les contours. Mais il y a aussi la solution proposée par Christian (une superrelation). Et de manière générale, dans OSM, on privilégie toujours la solution qui facilite la vie des contributeurs, pas celle qui facilite la vie des consommateurs de données au détriment des contributeurs. Ce sont ces derniers qui font vivre le projet et qu'il faut choyer en priorité. Pieren _______________________________________________ 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
