C'était juste une remarque à djakk qui veut coller à ce que fait Michelin, pour faire un rendu "à la Michelin", qui lui non plus n'est pas cohérent et pas sans erreurs (ou défauts de mises à jour de ses propres données).
Je peux aussi faire remarquer à djakk que s'il veut expérimenter un nouveau tag, avant il doit s'assurer que le tag n'est pas déjà utilisé pour autre chose et que le nom choisi est clairement non ambigu. Un tag comme "legal=*" est très peu explicite et risque fort d'entrer en collision. On avait discuté de la **possibilité** d'utiliser d'autres données pour mesurer l'importance des villes : on a l'INSEE pour le découpage urbain (pour ça ce devrait être un "boundary=urban" ou "boundary=statistic" avec un sous-tag pour les différents types de découpes urbaines: agglomération, aire urbaine, unité urbaine), pour les zones d'emploi (là aussi ce sont des données statistiques établies par groupe de communes ou d'IRIS). Plutôt que surcharger les noeuds des villes je suis plutôt favorable à utiliser les découpages réels où on a des données pertinentes. Ensuite un moteur de rendu peut analyser les relations pour déterminer le statut des villes (ces découpes peuvent aussi avoir un "admin_centre", même si ce n'est pas réellement administratif, utilisant à nouveau le noeud de la ville. ça donne ensuite un moyen pertinent et objectif pour mesurer ces importances. Pour l'instant on s'est juste contenté des populations municipales (avec une mise à jour pas trop ancienne) et de "capital=*" et cela a suffi car pour le reste nos rendus pouvaient faire le tri quand il s'agit de montrer ou cacher une ville selon le zoom, ou d'adapter la taille de police de son libellé. Mais d'autres critères peuvent intervenir pour que le moteur de rendu puisse calculer une "note" propre à chaque noeud candidat et faire le tri de ce qui est "important" ou pas, et ensuite si la note est suffisante, d'augmenter sa taille de libellé. Et pour moi le découpage urbain de l'INSEE, ou les zones d'emploi sont des éléments sur lesquels on a de nombreuses données statistiques mises à jour et qui mériteraient de figurer dans OSM (reste à choisir le jeu de tags, et surtout ne pas taguer en fonction du rendu pour un niveau de zoom unique, comme on peut le voir même Michelin ne fait pas ainsi!). Le dim. 16 sept. 2018 à 13:01, Frédéric Rodrigo <fred.rodr...@gmail.com> a écrit : > Le 14/09/2018 à 18:46, djakk djakk a écrit : > > Salut ! > > > > Une autre chose me tarabusce au sujet des routes dans osm, c’est > > l’absence d’info sur le type de route joint par une bretelle > > (highway=*_link), c’est-à-dire qu’on sait qu’une bretelle joint une > > autoroute mais on n’a pas d’info sur l’autre côté ! Primary, secondary > > ? On ne sait pas directement. > > Il suffit de regarder à quoi c'est connecté. > > Par ex pour les bretelles d’autoroutes c'est tout à fait logique d'avoir > motorway_link, elles font vraiment partie du réseaux autoroutier., > l'autre coté de la bretelle importe peut et peut être multiple. > > > Et je trouve cette information plus importante. En effet, si on relie > > une autoroute à une autoroute, ou si on relie une autoroute à une > > tertiary, on pourrait choisir au niveau du rendu de ne pas afficher la > > bretelle. Impossible en l’état actuel. > > Une autoroute est une voie très important, une tertiary ne l'est pas. Si > on a une sortie d'autoroute c'est que faire une sortie en vaut la penne, > et donc que la voirie qui est connecté est importante, peut probable que > ce soit vraiment une tertiary. > > Après ça n’empêche pas non plus "l'usage" et d'avoir des sorties > d'autoroute directement connecté à des tracks. > > https://www.openstreetmap.org/#map=19/22.98842/-82.62353 > > > > Du coup je propose link_from et link_to : pour une bretelle dans le > > sens autoroute vers tertiary, on aura link_from=motorway et > > link_to=tertiary. > > Cette information peut être calculé depuis la topologie et là n'apporte > rien, même pas de la cohérence. > > > Frédéric. > > > > > _______________________________________________ > 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
