<div dir="ltr">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.<div><br><div>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).</div><div><br></div><div>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).</div></div><div><br></div><div>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).</div><div><br></div><div>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=*".</div><div><br></div><div>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=*".</div><div><br></div><div>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.</div><div><br></div><div>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)</div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">Le 17 mars 2016 à 16:32, Vincent de Château-Thierry <span dir="ltr"><<a href="mailto:osm.vdct@free.fr" target="_blank">osm.vdct@free.fr</a>></span> a écrit :<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Bonjour,<br>
<br>
> De: "Philippe Verdy" <<a href="mailto:verdy_p@wanadoo.fr">verdy_p@wanadoo.fr</a>><br>
<span class="">><br>
> J'ai vu à plusieurs endroits que le tag type=* serait déprécié dans<br>
> les relations, parce qu'il est en fait ambigu, et parce que les<br>
> relations peuvent en fait simultanément de plusieurs types<br>
> différents.<br>
<br>
</span>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.<br>
<br>
vincent<br>
<br>
_______________________________________________<br>
Talk-fr mailing list<br>
<a href="mailto:Talk-fr@openstreetmap.org">Talk-fr@openstreetmap.org</a><br>
<a href="https://lists.openstreetmap.org/listinfo/talk-fr" rel="noreferrer" target="_blank">https://lists.openstreetmap.org/listinfo/talk-fr</a><br>
</blockquote></div><br></div>