Le 24 août 2017 à 12:04, Jo <[email protected]> a écrit : > Salut Lenny, > > J'espère que je vais pas troubler encore plus "l'eau"... > > Pour l'exemple de l'application: > http://www.overpass-api.de/api/sketch-line?network=DLVB&ref=318&operator= > http://www.overpass-api.de/public_transport.html > > Ce que moi je préfère avec la solution de tagger les objets c'est qu'il > n'y a pas de relation à entretenir. > > Maintenir des relations est moins évident que cela ne le semble. S'il y a > quelqu'un qui enlève un membre, combien de temps se passe-t-il avant que > l'on s'en rend compte? >
Concernant les relations "type=network" on se rend compte **immédiatement** qu'il manque une ligne à la liste qui est très synthétique: ses membres sont chacune des lignes numérotées (et normalement classées dans des numéros de ligne, bien que ce ne soit pas une obligation), et on en connait le nombre avant même d'avoir commencé à les tracer ou les chercher. On sait immédiatement quelles lignes sont fermées et qu'on peu retirer. Si toutes les lignes ont leur relations réseau attachées (et il ne doit y encore qu'une sauf cas exceptionnel des lignes cogérées sur plusieurs réseaux et qui reconnaissent sur ces lignes la validité des titres de transport émis par l'un ou l'autre des réseaux...), on ne peut pas créer de doublon sans que ça se voit aussi **immédiatement** dans la relation parente. > Les mettre dans les tags implique que des fois un object (arrêt, route) > appartient à plusieurs réseaux, mais cela ne pose pas de problème. On peut > les séparer par ; > - un unique tag "network=<id>" par route (dans les liste de ses tags) ne suffit pas on l'a vu, et n'est pas clair du tout, souvent erroné. - une seule relation parente "type=route" par route (ou bien une seule relation parente "super-route" ou "route_master", jamais simultanément) suffit à tout et est clairement identifiée, on ne fait pas d'erreur et en cas de doute on peut cliquer dessus pour en voir le contenu et les tags de description et toutes ses références utiles. Ce n'est pas plus long ni plus compliqué à éditer et jamais ambigu. - la présence de l'un n'empêche pas l'autre mais en cas de doute ou conflit, l'ambiguïté intrinsèque du tag (historique issu du schéma v1) ne résout rien facilement, et le tag n'est pas nécessaire si on a la relation parente, c'est juste une redondance pour la compatiblité v1, alors que la relation parente est toujours non ambiguë. Quant à la présence aussi bien du tag "network=*" ou d'une relation parente "type=network" ailleurs que les relations "type=route" (ou "type=super_route" ou "type=route_master"), elle ne se justifie pas dans aucun des deux cas : - Les arrêts et plateformes et sont référencés par les relations "type=route" ou "type=stop_area" qui les incluent. - il n'y a aucun arrêt ou plateforme dans une super_route ou route_master dont les membres ne sont que des relations routes ou super_route. Donc aucun ajout de tag ou ni de relation network nécessaire sur les arrêts et plateformes (s'il y en a c'est de la redondance pour la compatibilité v1 sur les "highway=bus_stop" qui sont en fait des plateformes en v2, mais le plus souvent les plateformes ne font pas partie directement d'un réseau mais ne concernent qu'un "operator=*" exploitant).
_______________________________________________ Talk-fr mailing list [email protected] https://lists.openstreetmap.org/listinfo/talk-fr
