Bonjour, Il y a deux discussions mélées dans ce sujet : les routes de substitution et l'utilité de route_ref.
Je m'adresse d'abord aux lignes. Moi je pense que la "substitution" applique aux relations, pas aux noeuds (arrêts). Normalement, le noeud désigne un endroit physique. Si je pense d'un arrêt de substitution et d'un arrêt "normale", dois-je les fusionner ? Si oui, le tag "subsitution=yes" a tort, parce que l'arrêt lui-même n'est pas un arret de subsitution. Alors, substitution:route_ref est preferable. Mais je pense que route_ref:substitution=* est meilleur. C'est les routes (et donc les route_ref) qui sont de substitution, pas les noeuds. Je ne trace pas les lignes de substitution, mais chacune a son route_ref. Par exemple, on peut dire pour le StopPoint:76:150 : name=Gare du Nord Surface route_ref:substitution=H SSB-PAR ... et pour la relation ... name=Bus H SSB-PAR : Travaux Sarcelles St Brice - Paris Est ref=H SSB-PAR substitution=yes Si l'on veut indiquer la ligne substituée, on peut ajouter sur la relation : substitution:route_id=800:H (ou substitution:ref=Train H ou Ligne H) ======= Deuxième chose : les route_ref si la relation existe. Moi je suis pour les route_ref, après avoir utilisé les deux methodes. 1. Il y a des arrêts où la desserte est secondaire, mais seulement la relation de la desserte principale existe dans OSM. 2. Cela ameliore la contrôle de la qualité. Si l'on trouve un desaccord entre la relation et le noeud, Osmose peut signaler un problème. 3. Le problème des données qui ne sont pas perennes existent dans les deux cas. OSM, comme Wikipedia, est toujours une approximation sujet à l'amelioration. Mais si les lignes changent, c'est plus facile de savoir si l'on a le route_ref. 4. Pour le consommateur, c'est plus facile de lire un tag "route_ref" que construire les relations. 5. Encore pour le consommateur, imaginez un noeud avec route_ref=1;2;3;4;5;6 qui est dans les relations avec ref=1,2,5,6. (Les relations 3 et 4 ne sont pas encore construit.) Si vous retirez juste les "doublons" on trouve route_ref=3;4. Mais si le consommateur regarde le noeud, et trouve route_ref=3;4, normalement il va penser qu'il n'y a que deux lignes qui desservent l'arrêt, non ? Cordialement, John On Fri, Oct 12, 2018 at 6:13 PM Florian LAINEZ <winner...@free.fr> wrote: > Hello, > Je suis d'accord avec Marc : l'utilisation d'une relation est à terme la > meilleure manière de faire. Et créer un tag qui devrait être une relation > est risqué pour la pérennité des données. > Néanmoins je suis aussi d'accord avec Charles : pour l'instant > l'utilisation d'un tag est le plus simple. > substitution:route_ref me parait en effet tout indiqué. > > pour moi l'élément clef qui nous pousse à ne pas utiliser les relations à > ce stade est que l'on ignore 1. les différents arrêts desservis par chaque > ligne de substitution 2. le trajet de ceux-ci. > Étant donné que l'on ignore tout des lignes à ce stade, je suis d'avis de > mapper directement avec des tags sur les arrêts. > > > Le ven. 12 oct. 2018 à 13:40, Charles MILLET <charlesmil...@free.fr> a > écrit : > >> Merci beaucoup pour tes précisions Marc ! >> >> Je suis globalement d'accord avec tes arguments pour ce qui est de la >> redondance, j'attends un peu d'avoir à nouveau les explications des >> "pour" avant d'avoir un avis définitif. >> >> Effectivement ce serait assez cohérent d'utiliser substitution:route_ref >> >> On 12/10/2018 12:58, marc marc wrote: >> > Bonjour, >> > >> > Le 12. 10. 18 à 11:24, Charles MILLET a écrit : >> >> Pour résumer tu n'est pas pour parce que tu n'est déjà >> >> pas pour le route_ref ? >> > oui en résumé c'est exactement cela. je suis contre subtitution:lines >> > permanent parce que je suis contre l'utilisation permanente de route_ref >> > >> > Si c'est un tag temporaire comme un étape intermédiaire renseignant >> > les informations destiné à la création des relations, c'est utile >> > mais autant garder la même logique et créer subtitution:route_ref >> > Et je passerai à la relation même imparfaite dès que possible. >> > >> >> https://wiki.openstreetmap.org/wiki/Key:route_ref et cette remarque : >> >> [route_ref=* can easily be added to individual bus stops without >> knowing >> >> the whole route a service takes. It can serve as a basis to add the >> full >> >> route relation LATER on] >> > je partage cet avis : >> > route_ref est utile quand il est utilisé temporairement "je suis passé >> > devant l'arrêt, il désert la ligne 42, je le renseigne pour l'ajouter >> > PLUTARD à la relation par ex avec un outil + adapté", c'est donc >> > à mes yeux signe de "ce n'est pas finit, il y a des choses à faire". >> > (même si je trouve qu'utiliser une clef spécifique pour une note/fixme >> > dédié aux lignes c'est une mauvaise idée, c'est "une chose de + à >> > requêter" et si chaque catégorie de donnée utilisait une clef >> > différente, ce serrait pas génial) >> > >> > mais quand il est permanent, c'est une donnée dupliquée avec la galère >> > que cela implique à chaque fois qu'il y a une différence entre les 2 : >> > si un utilisateur vire route_ref sans virer l'arrêt de la relation, >> > cela signifie-t-il que l'arrêt n'est plus desservit et qu'il faut >> > virer de la relation ? ou cela signifie-t-il qu'il a juste viré >> > une clef qu'il trouve inutile ? >> > Idem quand route_ref est présent mais différent des relations, >> > pour en avoir corrigé un bon paquet, quelle perte de temps à faire >> > une 2ieme fois les modifs en devinant le sens de la désynchro. >> > J'ai croisé des désynchro qui avait des années... c'est un peu >> > comme les notes non traitée, on a l'info mais faut quelqu'un >> > repasse une 2ieme fois pour que cela deviennent utilisable. >> > >> >> on est pas mal dans cette situation au final sauf qu'au lieu >> >> d'utiliser route_ref qui ne serait pas adapté et risquerait de >> parasiter >> >> cette clé, on propose d'utiliser : substitution=yes + >> >> subtitution:lines=* qui ont une vocation plus temporaire >> >> (1 an, 2 ans ?). >> > en temporaire oui pourquoi pas. >> > dans cette optique, autant aller jusqu'au bout avec >> > subtitution:route_ref qui dit clairement que cela a pour but >> > à terme d'être ajouté dans une relation de substitution. >> > mais il ne faudrait pas en arriver à "durabiliser" ce "fixme" >> > hors on va le mettre dans le wiki comme façon de tager un arrêt >> > de substitution >> > puis il y aura la tentation de faire un umap >> > ou n'importe quoi d'autre pour montrer l'avancement.. >> > et du coup le temporaire devient permanent... >> > Tu parles de 2 ans... >> > pq pas faire une relation imparfaite ? une relation ligne de bus >> > qui contient juste les quelques arrêts identifié dans le mois, >> > ce n'est pas complet mais c'est utilisable, un tag wiki sur >> > la relation vers la page qui explique l'expérimentation, >> > il serra toujours temps + tard d'affiner. >> > Mais je comprend/partage l'avis que la relation n'est pas >> > la priorité quand vous en êtes à l'étape d'identifier les arrêts. >> > >> >> Tu parles de la clé route_ref c'est ça ? Est-ce vraiment utile >> >> de la rejeter, perdre son utilité juste pour gagner en "pureté" >> >> de la données ? >> > Le problème principal ce n'est pas la pureté. >> > C'est le fait qu'avoir les données de 2 manières différentes implique >> > que par erreur ou par méconnaissance, certains contributeurs vont >> > modifié l'un, d'autre vont modifier l'autre et tu finis par avoir >> > des données de moindre qualité que si tu as une seule manière >> > de le renseigner. >> > Idem pour l'utilisation des données : certains vont utiliser l'un >> > parce que + présent au début, d'autre vont utiliser l'autre... >> > et donc les outils n'auront qu'une vision partielle des données, >> > sauf à devoir se farcir les 2 manières et donc le temporaire >> > devient "durable". >> > >> >> Bon voilà, j'oserai plus utiliser des notes ;) >> > :) à bon escient :) >> > >> > Cordialement, >> > Marc >> > _______________________________________________ >> > 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 >> > > > -- > > *Florian Lainez* > @overflorian <http://twitter.com/overflorian> > _______________________________________________ > 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
