[OSM-talk-fr] Modifier un pont erroné avec une dizaine de relations imbriquées au moins.

Philippe Verdy verdy_p at wanadoo.fr
Jeu 9 Aou 17:01:48 UTC 2018


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_irc at 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 at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
-------------- section suivante --------------
Une pièce jointe HTML a été nettoyée...
URL: <http://lists.openstreetmap.org/pipermail/talk-fr/attachments/20180809/48f84e0b/attachment-0001.html>


Plus d'informations sur la liste de diffusion Talk-fr