Les tags sur les ways sont de toute façon indicatifs uniquement quand le way entre dans une relation : la relation prime de toute façon en cas de conflit éventuel.
Aussi bien les frontières que les cours d'eau devraient être modélisés dans une relation contenant les way. Mais on a des tas de rues et de petits cours d'eau sans relation du tout. Ces tags sur le way quand il y a une relation sont plus des "rappels" informant de la présence (éventuelle) d'une relation: s'il y a une relation, c'est elle qui donne le nom a priori, mais pour les cours d'eau c'est un peu plus compliqué car si l'ensemble du cours a un nom, il peut changer localement le long du cours (notamment les cours d'eau sur plusieurs pays ayant des langues officielles différentes, mais aussi dans les estuaires (comme la Gironde et d'autres fleuves ouverts sur la remontée d'eau marine jusqu'au dernier barrage, ou équipement comme une barrière anti-sel, mais aussi les sections canalisées de fleuves et rivières qui localement prennent le nom du canal, par exemple sur l'Ille à Rennes) Le "name" alors sur le tracé est le nom local (ce serait un cas pour utiliser "loc_name" plutôt que "name" réservé au cours d'eau naturel). On a aussi des cas de noms encore plus locaux comme les noms d'écluses (là on a décidé d'utiliser "lock_name" pour ne pas rompre la continuité des noms des canaux et rivières canalisées). Même chose avec les noms locaux de ponts et tunnels sur une rue/route. D'une façon générale les frontières n'ont pas de nom bien défini sur leur way, ces noms dérivent des relations qui les utilisent: les noms de rivières et routes priment dans "'name". Les autres attributs ne souffrent pas d'ambiguité/conflits en général entre frontière et cours d'eau ou entre frontière et rue/route. Mais il y a des conflits de valeurs sur "admin_level=*" (on a opté pour utiliser sur le way la plus petite valeur), et sur "admin_type=*" ou "boundary=*" : là on choisit en général de prendre la valeur d'"admin_type" correspondant à l'admin_level le plus faible pour les frontières "boundary=administrative", qui est aussi prioritaire sur les autres types comme "boundary=political" sans "admin_level" (cas particulier: les frontières religieuses qui ont aussi malheureusement un "admin_level" à ne pas prendre en compte dans les priorités, cela aurait du être "religion_level", mais on a des conflits "administratifs" dans des pays multiconfessionnels qu'on ne peut pas régler sur les ways, uniquement sur les relations) les valeurs données sont là aussi indicatives mais on les choisit par degré d'importance administrative avant le reste. Si on met encore des tags sur les ways au lieu des relations parentes, c'est souvent par compatibilité avec plein d'outils et rendus qui eux ne cherchent pas les relations parentes, qui elles aussi ne sont pas encore obligatoires partout : ils sont aussi une aide utile pour les contributeurs car ces tags permettent de distinguer facilement les chemins dans des listes techniques d'objets qui ne sont pas pratiques à repérer avec juste leur ID numérique. Mais des améliorations des éditeurs pourraient aller chercher les relations parentes pour obtenir ces informations et les afficher sans qu'on ait à les renseigner aussi sur les ways (hormi cas spécial des noms locaux préférés aux noms globaux de l'objet dans leur relation parente) Le 3 août 2018 à 23:39, marc marc <marc_marc_...@hotmail.com> a écrit : > Le 03. 08. 18 à 11:27, Rpnpif a écrit : > > Oui bien sûr, mais le problème n'est pas là. Le problème est la > > superposition-fusion au mm près des tracés ou carrément le tagage type > > squat dans les attributs du flux. > > l'idéal est d'avoir un way pour la rivière avec uniquement les tags de > la rivière et utiliser ce way dans la relation boundary avec uniquement > les tags qui concerne le boundary. > mixer les 2 sur un way n'est pas top mais certains outils se servent > encore des tags boundary sur les relations... hélas... > _______________________________________________ > 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
