Rennes et Nantes l'utilisent, ce qui facilite le gros du chantier (même s'il y a une page wiki dédiée, mais tout le monde ne sait pas éditer le wiki non plus, c'est un autre outil de suivi). Les autoroutes françaises l'utilisent. Les routes européennes l'ont utilisé, mais ça a été supprimé depuis que les super-route ont été mises en place (segmentation par pays) au lieu de remplacer les "route" ou "route_master" par les nouvelles "super_route". (Eurovélo les a utilisé: même problème).
Visiblement certains n'aiment pas les relations network chez eux : chaque pays semble adopter ses méthodes de travail... une des raisons sans doute de la création des "super-routes" qui reporte le problème ailleurs mais n'aide pas du tout à garder une cohérence d'ensemble et la stabilité des outils et méthodes utilisées, comme si une seule méthode permettait de gérer ce chantier complexe et de longue haleine demandant beaucoup de travail sur des zones très étendues sur lesquelles il est difficile de maintenir la cohérence d'ensemble. Il semble que la priorité soit de gérer les transport agglomération par agglomération, mais le nombre d'interlocuteurs (collectivités, exploitants concessionnaires, exploitants fournisseurs, fournisseurs annexes) et l'intermodalité (multiples moyens de transport avec leurs propres règles internes et schéma de tagging) n'aide pas à gérer ça simplement avec des tags uniques. §Je vois mal comment se passer des relations, même si des outils pour les éditer, et travailler dessus mais aussi les utiliser commencent à apparaitre): supprimer directement sans s'intérroger sur les outils qui voudraient les exploiter (avec de bonnes raisons) est à mon avis une mauvaise idée: cela brise la volonté de structurer ça et ne fait que retarder la maintenance et évite bloque ensuite le développement des outils spécifiques et des réutilisations finales. Du coup, ce qui est régulièrement cassé (abusivement à mon avis, comme si ces objets n'existaient pas) est mis en oeuvre par des tas de bases externes déconnectées, maintenues séparément et à grand frais, en divisant les contributeurs en communautés plus petites et en favorisant l'émergence de solutions propriétaires sur ces bases tierces, qui elles font toutes l'effort de créer ces objets structurants. Cette suppression rend donc en fait service à d'autres sources cartographiques propriétaires qui elles vont vendre et restreindre les accès: Briser cet effort de rationalisation c'est aider Google à faire ce qu'OSM par son incohérence se refuse en core à faire.... Le 20 août 2017 à 12:13, Jo <winfi...@gmail.com> a écrit : > Pouvez-vous me pointer sur une relation network utilisé dans le schéma > public transport? Je n'en ai jamais vu et je n'ai jamais eu un cas où il me > semblerait utile. > > Mais j'ajoute network et operator sur tous les objets, les relations route > et route_master et les noeuds highway=bus_stop/public_transport=platform. > > Pas sur les noeuds public_transport=stop_position, car je n'ajoute jamais > des détails sur ces noeuds-là. Pas sur les ways > public_transport=platform/highway=platform > non plus. Et pas non plus sur les ways fermés > amenity=shelter/shelter_type=public_transport. > Leur operator ne m'intéresse pas du tout. > > Polyglot > > 2017-08-20 12:02 GMT+02:00 marc marc <marc_marc_...@hotmail.com>: > >> Le 20. 08. 17 à 11:20, lenny.libre a écrit : >> > 4- Bien que le wiki l'indique sur chaque objet, >> quelle page ? >> >> > est-il nécessaire de mettre "network" (et "network:wikidata") sur tous >> les objets ? >> >> selon moi, non c'est une mauvaise habitude. >> il faudrait le mettre sur la relation la + haute, éventuellement sur les >> variations des routes par facilité, mais pas sur les objets physiques. >> >> > - _relation "network"_ : le tag doit être présent >> même avis >> >> > - _relation "route_master"_ membre de la relation "network", il me >> > semble que la relation n'a pas besoin du tag supplémentaire "network" ; >> même avis >> >> > par contre si "route_master" n'était pas membre d'une telle relation il >> > faudrait le mettre ou créer la relation "network" ? >> si on a crée une relation network, c'est pour l'utiliser. alors il faut >> y ajouter les nouveaux membres dès que possible et/ou créer les >> nouvelles relations si un nouveau réseau apparaît. >> >> > - _relation "route"_ : le tag "network" ne me semble pas utile, sur >> > cette relation, puisqu'il est porté par la relation "route_master" >> même avis >> >> > - _"public_transport=platform"_ il me semble que les tags "network" >> > sont nécessaires, surtout lorsque l'objet n'est pas encore membre d'une >> > relation "route" ou "public_transport=stop_area" >> ce n'est pas "pas utile", c'est erroné que de dire qu'un trottoir ou un >> abribus fait partir d'un réseau de transport en commun. c'est du >> mobilier urbain. sinon à ce rythme là, on pourrait aussi ajouter les >> routes, les carrefours, les lampes qui éclairent la route, la station >> d'essence où le bus fait le plein, ... >> >> > - "_public_transport=__stop_position"_ ne me semble pas >> nécessaire, >> même incohérence >> >> > - "_public_transport=__stop_area"_ il me semble utile >> >> La seule utilité que je vois c'est une situation temporaire. tu passes >> devant un arrêt, tu notes les lignes de bus sur un node physique pour >> mémoriser l'info vu sur le terrain. >> Plus tard toi ou quelqu'un d'autre les migrera dans les relations. >> Dans ce sens là c'est utile puisque cela permet de retrouver facilement >> les ajouts à faire, les lignes à créer, les réseaux qui manquent. >> >> > ou bien vaut-il mieux être redondant pour favoriser la réutilisation des >> > données utilisation ? >> >> ce n'est pas de la redondance, c'est le chat qui se mord la queue. >> certains dupliquent cela sur tout les objets pour dire qu'ensuite c'est >> utile pour retrouver les objets afin de les rajouter dans les relations >> d’où proviennent l'info à la base. Si l'info était correcte au début, >> rien n'a été amélioré. si l'info était incorrecte, rien n'a été amélioré >> non plus. >> _______________________________________________ >> 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 > >
_______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
