Le 23 août 2017 à 20:59, Noémie Lehuby <noemie.leh...@zaclys.net> a écrit :
> Le 22/08/2017 à 22:52, Philippe Verdy a écrit : > > L'ennui c'et que toutes les applications qui ont commencé à utiliser > network=* ont supposé que le nom indiqué derrière était unique, ce qu'il > n'est pas. En fait ils voulaient que ce soit bien un identifiant. > > > > On parle de quelles applications ? > Moi j'en connais pas bcp qui utilisent le tag network des relations route > ou route_master (voire même : pas bcp qui utilisent les relations route ou > route_master). > Dans les projets Taginfo, je n'en vois que deux : les presets JOSM et > Vespucci, c'est dire ... > Et hors tout : il parait qu'on ne cartographie pas pour le rendu :p > > Personnellement, quand je fais des extractions de données transports, je > ne m'attends pas à ce que le nom soit unique. > S'il y a deux réseaux STAR ou Arc-En-Ciel ou SITUS, ben je veux avoir deux > occurrences dans mes données. C'est la réalité du terrain, ça me semble > normal de retrouver cela dans OSM. Oui mais comment savoir alors les distinguer quand dans les deux cas ce sont des objets très étendus donc pas facile à délimiter clairement, et pas non plus totalement connexes (même s'il ya a de fortes proximités et de nombreuses interconnexions entre les routes d'un réseau) ? Oui on ne tague pas pour le rendu, mais même pour une appli de base comme une recherche d'itinéraire, un calcul de temps de parcours, un calcul tarifaire ou la recherche d'infos liées à un réseau qu'on ne trouvera pas ligne par ligne, il nous manquera toujours quelquechose permettant le rapprochement sans ambiguité. On peut commencer à collectionner les tags, mais ça devient vite lourd quand il faut mettre ces tags multiples sur des centaines ou des milliers d'objets éparpillés sur une surface très grande (où la sélectivité des requêtes est faible sur ce critère géographique). A coté de ça une ajouter une relation mère à un objet c'est sans ambiguïté, l'unicité est garantie et pas besoin d'inventer une codification de valeur de tag pour ça (d'autant qu'on n'a même pas réussi à se mettre d'accord dessus, le tag "network=*" pouvant contenir selon les endroits soit un identifiant supposé unique (mais pas lisible et pas garanti unique non plus), soit un nom lisible en clair (parce qu'on a tagué pour un rendu, mais pas adapté au cas des noms officiellement multilingues ni à la difficulté des mises à jour quand ces noms changent)... Si on compte sur Overpass pour faire les recherches, cela ne tient pas la route, l'application sera lente. D'une façon ou d'une autre il sera plus simple alors de créer une base tierce (propriétaire) pour y mettre ce qu'on n'aura pas voulu mettre dans OSM: la liste exhaustive des objets qui sont inclus dedans (presque toujours connue à l'avance dans tous les jeux de données OpenData et les sites et plans d'information des exploitants : on peut avoir une liste exhaustive contenant même des objets incomplètement tracés ou dont certaines parties ne sont pas assez précisément connues sans écrouler le "château de carte" de la "solution" des tags imprécis et non maintenus sur des centaines ou milliers d'objets très distants les uns des autres et rarement édités simultanément). Sans cette relation dans la base OSM (pourtant très économique et plus économique même que divers tags ou même un seul "network=<id>"), on se retrouve à gérer chacun de son côté des listes non coordonnées d'objets. On gaspille les ressources de travail de tout le monde qui en permanence ira "pêcher à la ligne" au hasard. Après on ne s'étonnera pas de trouver dans la base OSM des tas d'objets en doublons (des doublons de lignes de transport, il y en a des tas dans OSM, on ne sait même plus savoir la quelle est la plus à jour, parce que justement on n'a pas de concertation et chacun utilise ses listes personnelles sur divers outils, mais pas toujours aussi ouverts et coopératifs qu'une liste sur le wiki OSM, mais qui peut être aussi sur divers sites comme une uMap, une maproulette... ou chez MapBox où c'est devenue un jeu de données privées, ou encore moins ouvert quand c'est un fil IRC, une liste mail, une page Facebook ou un fil Tweeter qu'il faudra suivre en permanence et où il sera difficile de retrouver une historique et classer les interventions). OSM est une base de données mais on ne veut pas se servir de ses capacités même quand la solution est économique pour tout le monde (pour OSM sur ses serveurs comme pour les réutilisateurs), simple à expliquer et mettre en oeuvre, fiable, et totalement ouverte et collaborative. La présence de ces relations n'empêchera pas d'ajouter des infos rendondantes comme les tags pour ceux qui ne comprennent pas encore les relations (la redondance servant à la compatibilité et aider leur migration). Mais ces tags redondants sont automatiquement dérivables de la relation qui sert de référence, et les bots d'analyse disposent de moyens fiables de vérifier leur cohérence, et à terme on pourra déclarer ces tags obsolètes pour qu'ils soient purgés. Et mieux que ça, on ne dépend pas non plus du fonctionnement très intermittent et pas fiables de services comme Overpass (qui sont compliqués à maintenir en place pour autre chose que les travaux de contribution, et pas vraiment plus efficace que les outils de suivis de projets et autres listes externes)
_______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
