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
