<div dir="ltr"><div>Hello,</div><div>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.<br></div><div>Néanmoins je suis aussi d'accord avec Charles : pour l'instant l'utilisation d'un tag est le plus simple.</div><div>substitution:route_ref me parait en effet tout indiqué.<br><br></div><div>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.<br></div><div>É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.<br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr">Le ven. 12 oct. 2018 à 13:40, Charles MILLET <<a href="mailto:charlesmillet@free.fr">charlesmillet@free.fr</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Merci beaucoup pour tes précisions Marc !<br>
<br>
Je suis globalement d'accord avec tes arguments pour ce qui est de la <br>
redondance, j'attends un peu d'avoir à nouveau les explications des <br>
"pour" avant d'avoir un avis définitif.<br>
<br>
Effectivement ce serait assez cohérent d'utiliser substitution:route_ref<br>
<br>
On 12/10/2018 12:58, marc marc wrote:<br>
> Bonjour,<br>
><br>
> Le 12. 10. 18 à 11:24, Charles MILLET a écrit :<br>
>> Pour résumer tu n'est pas pour parce que tu n'est déjà<br>
>> pas pour le route_ref ?<br>
> oui en résumé c'est exactement cela. je suis contre subtitution:lines<br>
> permanent parce que je suis contre l'utilisation permanente de route_ref<br>
><br>
> Si c'est un tag temporaire comme un étape intermédiaire renseignant<br>
> les informations destiné à la création des relations, c'est utile<br>
> mais autant garder la même logique et créer subtitution:route_ref<br>
> Et je passerai à la relation même imparfaite dès que possible.<br>
><br>
>> <a href="https://wiki.openstreetmap.org/wiki/Key:route_ref" rel="noreferrer" target="_blank">https://wiki.openstreetmap.org/wiki/Key:route_ref</a> et cette remarque :<br>
>> [route_ref=* can easily be added to individual bus stops without knowing<br>
>> the whole route a service takes. It can serve as a basis to add the full<br>
>> route relation LATER on]<br>
> je partage cet avis :<br>
> route_ref est utile quand il est utilisé temporairement "je suis passé<br>
> devant l'arrêt, il désert la ligne 42, je le renseigne pour l'ajouter<br>
> PLUTARD à la relation par ex avec un outil + adapté", c'est donc<br>
> à mes yeux signe de "ce n'est pas finit, il y a des choses à faire".<br>
> (même si je trouve qu'utiliser une clef spécifique pour une note/fixme<br>
> dédié aux lignes c'est une mauvaise idée, c'est "une chose de + à<br>
> requêter" et si chaque catégorie de donnée utilisait une clef<br>
> différente, ce serrait pas génial)<br>
><br>
> mais quand il est permanent, c'est une donnée dupliquée avec la galère<br>
> que cela implique à chaque fois qu'il y a une différence entre les 2 :<br>
> si un utilisateur vire route_ref sans virer l'arrêt de la relation,<br>
> cela signifie-t-il que l'arrêt n'est plus desservit et qu'il faut<br>
> virer de la relation ? ou cela signifie-t-il qu'il a juste viré<br>
> une clef qu'il trouve inutile ?<br>
> Idem quand route_ref est présent mais différent des relations,<br>
> pour en avoir corrigé un bon paquet, quelle perte de temps à faire<br>
> une 2ieme fois les modifs en devinant le sens de la désynchro.<br>
> J'ai croisé des désynchro qui avait des années... c'est un peu<br>
> comme les notes non traitée, on a l'info mais faut quelqu'un<br>
> repasse une 2ieme fois pour que cela deviennent utilisable.<br>
><br>
>> on est pas mal dans cette situation au final sauf qu'au lieu<br>
>> d'utiliser route_ref qui ne serait pas adapté et risquerait de parasiter<br>
>> cette clé, on propose d'utiliser : substitution=yes +<br>
>> subtitution:lines=* qui ont une vocation plus temporaire<br>
>> (1 an, 2 ans ?).<br>
> en temporaire oui pourquoi pas.<br>
> dans cette optique, autant aller jusqu'au bout avec<br>
> subtitution:route_ref qui dit clairement que cela a pour but<br>
> à terme d'être ajouté dans une relation de substitution.<br>
> mais il ne faudrait pas en arriver à "durabiliser" ce "fixme"<br>
> hors on va le mettre dans le wiki comme façon de tager un arrêt<br>
> de substitution<br>
> puis il y aura la tentation de faire un umap<br>
> ou n'importe quoi d'autre pour montrer l'avancement..<br>
> et du coup le temporaire devient permanent...<br>
> Tu parles de 2 ans...<br>
> pq pas faire une relation imparfaite ? une relation ligne de bus<br>
> qui contient juste les quelques arrêts identifié dans le mois,<br>
> ce n'est pas complet mais c'est utilisable, un tag wiki sur<br>
> la relation vers la page qui explique l'expérimentation,<br>
> il serra toujours temps + tard d'affiner.<br>
> Mais je comprend/partage l'avis que la relation n'est pas<br>
> la priorité quand vous en êtes à l'étape d'identifier les arrêts.<br>
><br>
>> Tu parles de la clé route_ref c'est ça ? Est-ce vraiment utile<br>
>> de la rejeter, perdre son utilité juste pour gagner en "pureté"<br>
>> de la données ?<br>
> Le problème principal ce n'est pas la pureté.<br>
> C'est le fait qu'avoir les données de 2 manières différentes implique<br>
> que par erreur ou par méconnaissance, certains contributeurs vont<br>
> modifié l'un, d'autre vont modifier l'autre et tu finis par avoir<br>
> des données de moindre qualité que si tu as une seule manière<br>
> de le renseigner.<br>
> Idem pour l'utilisation des données : certains vont utiliser l'un<br>
> parce que + présent au début, d'autre vont utiliser l'autre...<br>
> et donc les outils n'auront qu'une vision partielle des données,<br>
> sauf à devoir se farcir les 2 manières et donc le temporaire<br>
> devient "durable".<br>
><br>
>> Bon voilà, j'oserai plus utiliser des notes ;)<br>
> :) à bon escient :)<br>
><br>
> Cordialement,<br>
> Marc<br>
> _______________________________________________<br>
> Talk-fr mailing list<br>
> <a href="mailto:Talk-fr@openstreetmap.org" target="_blank">Talk-fr@openstreetmap.org</a><br>
> <a href="https://lists.openstreetmap.org/listinfo/talk-fr" rel="noreferrer" target="_blank">https://lists.openstreetmap.org/listinfo/talk-fr</a><br>
<br>
<br>
_______________________________________________<br>
Talk-fr mailing list<br>
<a href="mailto:Talk-fr@openstreetmap.org" target="_blank">Talk-fr@openstreetmap.org</a><br>
<a href="https://lists.openstreetmap.org/listinfo/talk-fr" rel="noreferrer" target="_blank">https://lists.openstreetmap.org/listinfo/talk-fr</a><br>
</blockquote></div><br clear="all"><br>-- <br><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">
<p style="margin-bottom:0cm">
</p><p style="margin-bottom:0cm"><font color="#333333"><font face="arial, helvetica, sans-serif"><font style="font-size:11pt" size="2"><b>Florian
Lainez</b></font></font><br></font></p><img src="http://twitter.com/favicon.ico"><a href="http://twitter.com/overflorian" target="_blank">@overflorian</a><br></div></div>