[OSM-talk-fr] "type=*" déprécié dans les relations?

[Philippe Verdy]

Note aussi que "highway=road" est déprécié depuis longtemps au profit des
autres valeurs plus précises ou sinon "highway=unspecified" si réellement
on n'a pas d'information. Pourtant il en reste plein.

Si pour les autres types de relation on doit par exemple remplacer
"type=natural" par une valeur appropriée de "natural=*" on n'a aucune
valeur évidente de remplacement, et cela mériterait alors une analyse pour
les repérer, et savoir ceux qui peuvent être convertis de façon quasi
automatique (grace à d'autres tags déjà présents et non ambigus).

Sinon, autant laisser en attendant ces valeurs de "type=*" ambiguës, sans
même avoir à créer une nouvelle valeur fourre-tout de substitution (pas la
peine de refaire la même chose que "highway=unspecified" qui n'a fait que
déplacer le problème de l'ancien "highway=road" avec une valeur ayant les
mêmes problèmes qu'avant).

Dans ce cas le traitement est "simple": si une relation utilisant
"type=xyz" n'a pas un autre tag "xyz=*" mieux qualifié, la signaler comme
ambiguë, et ne rien changer, mais la reporter sur un outil QA tel qu'Osmose
(car elle est même déjà incompatible avec d'autres tags déjà présents dans
la relation ou dans des relations maitre).

Dans l'immédiat je ne voit pas l'intérêt de garder "type=boundary" quands
on a déjà explicitement un tag "boundary=*" : le "type=boundary" est
clairement redondant (vérifier avant que les rendus qu'on utilise ne
dépendent pas dans leurs règles de la présence de "type=boundary" pour
afficher les frontières, mais qu'ils se contentent juste de "boundary=*".

Les rendus ont d'autres problèmes sur les frontières: souvent ils ne
tiennent pas compte du tag "boundary=*"" présent dans les relations, mais
uniquement de ce tag (et de "admin_level=*") sur les ways. Souvent ces ways
ont oublié ces tags, et les frontières disparaissent du rendu alors que les
relations sont bien formées et correctement taguées. C'est un exemple où
l'ancienne façon de taguer est la seule encore prise en compte (et pourtant
on a du mal à définir une valeur appropriée pour "boundary=*" sur les ways,
qui peuvent servir à plein de choses et même pour des frontières de types
différents (boundary=adminsitrative, boundary=postal_code,
boundary=political). Même chose pour les valeurs à donner au tag
"political_division=*" sur ces mêmes ways (il n'y a pas de critère objectif
de choix aussi facile que les "admin_level=*" pour les frontières
administratives ; exemple avec les valeurs "canton" et
"circonscription_législative"...) Là encore ce n'est pas sur le way qu'il
faudrait chercher l'info mais sur les relations qui ont ce way en membre.
Mais ces relations ne devraient pas être cherchées selon leur "type=*" mais
uniquement sur "boundary=*".

Tout cela a des conséquences aussi sur la quantité de travail que doivent
produire les outils d'exports vers les bases de rendus (exemple osm2pgsql
qui passe un part énorme de son temps à chercher différentes façon de
taguer la même chose afin de générer des listes de features importables sur
une base de données GIS standard qui sert ensuite à alimenter un serveur de
rendu). On le sait, les serveurs ont de plus en plus de travail (mais pas
la capacité de monter en charge aussi vite. Plus la base grossit, et plus
cela devient lourd et plus les rendus ont du retard.

Bref des nettoyages s'imposent dans la base OSM sur ce qui est réellement
utile et sur ce qu'on devrait déprécier bien plus rapidement pour soulager
le travail des serveurs et leur faire gagner en réactivité (et aussi mieux
utiliser les ressources disponibles). Mais évidemement les divers outils
utilisateurs des données devrient être passés en revue pour savoir s'ils
n'ont pas encore besoin de valeurs obsolètes (et uniquement celles-là car
ils leur manque la prise en compte des nouveaux tags)



Le 17 mars 2016 à 16:32, Vincent de Château-Thierry <osm.vdct at free.fr> a
écrit :

> Bonjour,
>
> > De: "Philippe Verdy" <verdy_p at wanadoo.fr>
> >
> > J'ai vu à plusieurs endroits que le tag type=* serait déprécié dans
> > les relations, parce qu'il est en fait ambigu, et parce que les
> > relations peuvent en fait simultanément de plusieurs types
> > différents.
>
> Philippe, tu as un lien vers les endroits en question ? Autant je trouve
> le tag type=* complètement inutile (et ses déclinaisons en espace de nom
> "*:type=*"), autant le déprécier a des conséquences sur pas mal
> d'implémentations où un filtre se fait sur la valeur du tag type=*. Ce
> serait un changement majeur, qui mérite une diffusion large (et du temps).
> Merci pour tes infos supplémentaires.
>
> vincent
>
> _______________________________________________
> 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/20160317/ecec579e/attachment.htm>