Re: [OSM-talk-fr] "type=*" déprécié dans les relations?
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 a écrit : > Bonjour, > > > De: "Philippe Verdy" > > > > 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@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-fr > ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] "type=*" déprécié dans les relations?
Un lien, s'il te plait ? Ou même deux ou trois, comme tu dis que tu en as vu plein ? JB. Le 17/03/2016 20:30, Philippe Verdy a écrit : Justement je commence à en voir un peu partout dans le wiki documentaire. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] "type=*" déprécié dans les relations?
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. Cela concernait la plupart des valeurs données à type=* dont - type=boundary : remplacé par le tag plus approprié "boundary=*" - type=land_area : remplacé par le tag plus approprié "boundary=land_area" voire même seulement "land-area=*" - type=route : remplacé (?) par le tag plus spécifique route=* - type=natural (quelques occurences) : remplacé par le tag natural=* - type=multipolygon : pas signifiant du tout, historique, mais encore généré par défaut dans les éditeurs, à priori inutile. Si le but est de bien indiquer que cela concerne la surface et non le seul contour, c'est le cas par défaut dans toutes les relations (sauf les "route=*" pour les itinéraires), sinon on a "area=yes/no" pour changer cette valeur par défaut Note: - "area=yes" n'est à priori pas utile pour les relations puisque c'est la valeur par défaut de toutes les relations, sauf route=* (et "route=*" n'a pas de sens en tant que surface, à moins que ce soit pour mentionner qu'un itinéraire passe par une zone où n'existe aucun sens de circulation ni aucun chemin spécifique) ; en revanche il reste utile pour les relations avec "highway=*" qui peuvent avoir besoin de mentionner une surface (exemple les zones piétonnes avec "highway=pedestrian"), et dans ce cas cette relation surfacique highway=* pourrait être un des membres d'un itinéraire piéton (route=*). - "area=no" n'est semble-t-il pas utile (c'est déjà la valeur par défaut pour les "highway=*" et pour les "route=*") Que se passe-t-il si on n'a QUE type=* et aucune des tags de remplacement (comme ceux-dessus : pour les utiliser il faut cependant leur donner une valeur et ce n'est pas si évident, en tout cas pas automatiquement. Tout au plus : - pour une relation "type=highway", le tag de remplacement "highway=*" pourrait utiliser une valeur "highway=unspecified" (et donc supprimer automatiquement "type=highway") - pour une relation "type=boundary", le tag de remplacement "boundary=*" n'a pas de valeur par défaut (même si la plupart du temps c'est "boundary=administrative", cela reste à vérifier. - pour une relation "type=route", le tag de remplacement "route=*" n'a pas de valeur par défaut non plus (même si souvent c'est "route=bus", il y a d'autres modes de transport possibles) A-t-on une analyse permettant de trouver les relations utilisant "type=" mais aucun tag "=*" ? Ces relations devraient être précisées (car en attendant on ne peut pas supprimer "type=XYZ". Est-il prévu une réelle obsolescence du tag "type=*" (y compris "type=multipolygon" qui ne sert à rien du tout) pour les relations ? Votre avis sur la question : faut-il encore mettre "type=*" dans les relations, au moins le temps d'assurer la migration des tags plus spécifiques manquants (même si cela fait doublon quand ce tag plus spécifique est déjà présent) ? ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] "type=*" déprécié dans les relations?
Je suis beaucoup de listes en plusieurs langues et ceci est le premier message que j'ai vu qui parle de décommissioner type= pour les relations. Polyglot 2016-03-17 22:55 GMT+01:00 JB : > Un lien, s'il te plait ? > Ou même deux ou trois, comme tu dis que tu en as vu plein ? > JB. > > Le 17/03/2016 20:30, Philippe Verdy a écrit : > >> Justement je commence à en voir un peu partout dans le wiki documentaire. >> > > > ___ > 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
Re: [OSM-talk-fr] "type=*" déprécié dans les relations?
Bonjour, > De: "Philippe Verdy" > > 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@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] "type=*" déprécié dans les relations?
Justement je commence à en voir un peu partout dans le wiki documentaire. Ce qui laisse penser que cela a été discuté quelquepart (sur une liste de discussion anglophone ou ailleurs). Mais avant de les nettoyer, il serait bon de faire le tour des applis qui peuvent en dépendre, et voir comment les convertir correctement. Ceci dit, je n'ai rien contre la dépréciation du "type=*" dans les relations (y compris "type=multipolygon" qui ne sert strictement à rien) Le 17 mars 2016 à 16:32, Vincent de Château-Thierry a écrit : > Bonjour, > > > De: "Philippe Verdy" > > > > 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@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-fr > ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] "type=*" déprécié dans les relations?
Pas tout à fait : Pour monsieur tout le monde une route c'est une route. Si tu vois une route "non spécifiée" tu vas naturellement essayer de la spécifier. Donc au tu pars de la même quantité mais à terme tu as moins de fourre-tout. JYL Le 2016-03-17 20:53, Philippe Verdy - verd...@wanadoo.fr a écrit : 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). ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
