Re: [OSM-talk-fr] Cartographie des arrêts de bus de substitution de la ligne RER C

2018-10-12 Par sujet Johnparis
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  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  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 

Re: [OSM-talk-fr] Cartographie des arrêts de bus de substitution de la ligne RER C

2018-10-12 Par sujet Florian LAINEZ
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  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 

Re: [OSM-talk-fr] Cartographie des arrêts de bus de substitution de la ligne RER C

2018-10-12 Par sujet Charles MILLET

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


Re: [OSM-talk-fr] Cartographie des arrêts de bus de substitution de la ligne RER C

2018-10-12 Par sujet marc marc
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


Re: [OSM-talk-fr] Cartographie des arrêts de bus de substitution de la ligne RER C

2018-10-12 Par sujet Charles MILLET

Merci pour ton retour (plus des commentaires dans le corps).

Pour résumer tu n'est pas pour parce que tu n'est déjà pas pour le 
route_ref ?


Pourtant si on regarde cette page 
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]


...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 
?). Moi ça me semble plus adapté dans un premier temps plutôt que de 
mettre beaucoup d'énergie à mettre en place une relation (et j'aime les 
relations ;) qui sera encore plus difficile à maintenir. Je propose de 
voir ça dans un second temps.


J'attends aussi les arguments de Florian mais je crois qu'il est cloué 
au lit en ce moment.


On 11/10/2018 18:15, marc marc wrote:

Le 11. 10. 18 à 17:05, Charles MILLET a écrit :

Nous pensons utiliser quelque chose comme ça
substitution=yes

sur l'arrêt de bus, pour ma part je ne rajouterais pas de tag
en particulier, c'est un arrêt de bus, y dupliquer l'information
de tous les type de lignes pouvant éventuellement l'utiliser ne semble
à la fois peu pratique et surtout galère à maintenir (parce qu'à chaque
changement, il faut veiller à dupliquer le changement pour garder
la cohérence, faire une analyse osmose ou autre pour surveiller
les inévitables désynchronisation entre les 2 et avoir quelqu'un
qui passe du temps à resynchroniser les données).
Je pense que l'utilisation des données du type de ligne qui passe
à un arrêt doit se faire par les infos de(s) relation(s) de l'arrêt.
Mais je sais qu'on a au moins 2 champions de la duplication dans
la communauté qui ne manqueront pas de faire valoir l'inverse :-)
Oui il faudrait une relation pour décrire ces lignes temporaires mais là 
il s'agit de décrire que l'arrêt de bus fait aussi l'objet d'un arrêt de 
substitution


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 
? Je crois que c'est un autre débat, comme je n'y ai pas trop participé 
je donne rapidement mon avis à ce sujet :  je suis pour la redondance 
des lignes sur les arrêts dans la mesure où elle ne pose pas de 
problèmes et apporte des informations très utiles.





subtitution:lines=RER C

pour les relations représentant les lignes,
Une possibilité serrait d'avoir exactement le même nom
et donc j'aurais plutôt vu quelque chose genre
name=RER C (mais j'ai vu que le nom des lignes RER est un mix entre
le nom, le from, le to, la ref et la branche...)
substitution=only (la ligne n'existe que quand l'autre est en panne)
substitution:of=train (elle remplace une relation train)
et éventuellement sur la relation du RER C:
substitution:by=bus
en ajoutant l'itinéraire de substitution dans la relation route_master
on pourrait sans doute faciliter une utilisation futur + poussée.
le soucis que je vois c'est que c'est pas prévu d'avoir des route=bus
fils d'une relation route_master=train
ce serrait sans doute utile d'en discuter sur tagging
avec une exemple de relation bus comparable à la relation rer
histoire de rendre la chose compréhensible pour ceux qui n'ont
rien de semblable chez eux.
c'est sans doute un peu prématuré si pour le moment vous en êtes
aux arrêts de bus eux-même.
Les relations, si elles existent un jour, ne sont pas pour tout de 
suite, c'est un peu compliqué de me plonger dans une réflexion sur la 
façon de les taguer.



Ces tag pourrons être complétés par une note au besoin.

les notes peuvent être utile pendant l'expérience sur la première
relation mais à long terme, des outils/contributeurs considèrent
la note comme étant souvent le signe que c'est pas stable d’où
le besoin de transmettre une information et qu'il faut donc
un éventuel coup de main pour transformer la note en tag + adapté.
url=la page wiki sur le changeset serrait très utile pour le
contributeur qui veux en savoir plus sur le projet.

Bon voilà, j'oserai plus utiliser des notes ;)


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


Re: [OSM-talk-fr] Cartographie des arrêts de bus de substitution de la ligne RER C

2018-10-11 Par sujet marc marc
Le 11. 10. 18 à 17:05, Charles MILLET a écrit :
> Nous pensons utiliser quelque chose comme ça
> substitution=yes

sur l'arrêt de bus, pour ma part je ne rajouterais pas de tag
en particulier, c'est un arrêt de bus, y dupliquer l'information
de tous les type de lignes pouvant éventuellement l'utiliser ne semble
à la fois peu pratique et surtout galère à maintenir (parce qu'à chaque 
changement, il faut veiller à dupliquer le changement pour garder
la cohérence, faire une analyse osmose ou autre pour surveiller
les inévitables désynchronisation entre les 2 et avoir quelqu'un
qui passe du temps à resynchroniser les données).
Je pense que l'utilisation des données du type de ligne qui passe
à un arrêt doit se faire par les infos de(s) relation(s) de l'arrêt.
Mais je sais qu'on a au moins 2 champions de la duplication dans
la communauté qui ne manqueront pas de faire valoir l'inverse :-)

> subtitution:lines=RER C

pour les relations représentant les lignes,
Une possibilité serrait d'avoir exactement le même nom
et donc j'aurais plutôt vu quelque chose genre
name=RER C (mais j'ai vu que le nom des lignes RER est un mix entre
le nom, le from, le to, la ref et la branche...)
substitution=only (la ligne n'existe que quand l'autre est en panne)
substitution:of=train (elle remplace une relation train)
et éventuellement sur la relation du RER C:
substitution:by=bus
en ajoutant l'itinéraire de substitution dans la relation route_master
on pourrait sans doute faciliter une utilisation futur + poussée.
le soucis que je vois c'est que c'est pas prévu d'avoir des route=bus 
fils d'une relation route_master=train
ce serrait sans doute utile d'en discuter sur tagging
avec une exemple de relation bus comparable à la relation rer
histoire de rendre la chose compréhensible pour ceux qui n'ont
rien de semblable chez eux.
c'est sans doute un peu prématuré si pour le moment vous en êtes
aux arrêts de bus eux-même.

> Ces tag pourrons être complétés par une note au besoin.

les notes peuvent être utile pendant l'expérience sur la première 
relation mais à long terme, des outils/contributeurs considèrent
la note comme étant souvent le signe que c'est pas stable d’où
le besoin de transmettre une information et qu'il faut donc
un éventuel coup de main pour transformer la note en tag + adapté.
url=la page wiki sur le changeset serrait très utile pour le 
contributeur qui veux en savoir plus sur le projet.

Cordialement,
Marc
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


[OSM-talk-fr] Cartographie des arrêts de bus de substitution de la ligne RER C

2018-10-11 Par sujet Charles MILLET

Bonjour,

cartographions actuellement avec Antoine (Carto'Cité), Florian (Jungle 
Bus) et Stéphane (V4M*) les arrêts de bus de substitution de SNCF 
Transilien. Ce sont -souvent- des arrêts de bus classiques, utilisés par 
ailleurs pour la desserte de bus SNCF remplaçant les trains lors de 
perturbations.


Cette action a pour but à termes de permettre du routage mais ça n'a pas 
d'influence.


Pour les besoins du démarrage de cette opération on a commencé en 
utilisant le tag substitution=yes qui ne me parait pas vraiment 
explicite. Nous pensons utiliser quelque chose comme ça

substitution=yes
subtitution:lines=RER C

Ces tag pourrons être complétés par une note au besoin.

Est-ce que ça vous semble acceptable et sinon que recommanderiez-vous ?

Nous avons remarqué également que certains créent des relations 
classiques de bus pour cela, ce qui me parait adapté pour ces bus aux 
itinéraires prédéfinis qui opèrent de manière irrégulière.
exemple : 
https://wiki.openstreetmap.org/wiki/Caen/Transports_en_commun#Bus_de_substitution_du_Tram 



Sans aller dans ce niveau de détail, nous cherchons dans un premier 
temps à qualifier les arrêts de bus eux-même.


À très bientôt

Charles


___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr