[OSM-talk-fr] Arrêts de bus urbains communs avec ceux des cars régionaux

[Philippe Verdy]

Le 26 juin 2018 à 06:57, Mail Delivery System <MAILER-DAEMON at orange.fr> a
écrit :

> From: mga_geo <mga_geo at yahoo.fr>
> To: talk-fr at openstreetmap.org
> Date: Mon, 25 Jun 2018 23:57:03 -0500 (CDT)
> Subject: Re: [OSM-talk-fr] Arrêts de bus urbains communs avec ceux des
> cars régionaux



>

Bonjour à tous,
> Sur Rennes, le post-fixage a été utilisé très fréquemment pour les tags
> name
> et ref pour les arrêts communs, exemple
> https://www.openstreetmap.org/node/286360849
> Que le tag name ne corresponde pas exactement au terrain (ajout du nom de
> la
> commune, suppression des abréviations ...) rend très difficile
> l'utilisation
> pour des étrangers.
>

Pour un tel cas la faute revient plutôt à l'opérateur départemental
(Illenoo) qui utilise sur ses fiches horaires et son site d'information des
noms plutôt ambigus comme ici "Rennes/Trois Marches" qui n'est même pas à
Rennes et aurait du être "Vezin-le-Coquet/Trois Marches".

name <https://wiki.openstreetmap.org/wiki/FR:Key:name?uselang=fr>
Vezin-le-Coquet
(Trois Marches)
name:fr_illenoo Rennes/Trois Marches
Ceci dit même pour les arrêts officiels métropolitains (Illenoo n'a pas
d'arrêt officiel dans la métropole, il emprunte ceux de la métropole qui a
l'exclusivité administrative pour tous les services publics de transport,
et les a confié à la STAR, gérée par la filiale locale de la SNCF comme
opérateur exploitant et chargé de la gestion des besoins de toutes les
sociétés de transport), on a des arrêts ambigus par leur nom seul qui n'est
pas unique sur la métropole entière (exemple "Centre", ou "Mairie", ou
"Gares", si on n'ajoute pas le nom de la commune).

Il y a des cas d'arrêts multiples dans un même secteur et de même commune
mais ils sont assez proches pour former une même station de correspondance
(une même stop_area) et varier entre eux selon les horaires et conditions
de circulation. Je ne vois pas alors l'utilité de les rendre absolument
uniques pour ce cas.

Mentionner clairement la commune devrait être donc un minimum. Il me semble
que pour l'immense réseau bus de la RATP on a besoin de lever des
ambiguités pour permettre de trouver les arrêts (par exemple dans une
recherche sur le nom simple comme "Trois Marches" ici, avec Nominatim, on
devrait pouvoir avoir une liste claire d'arrêts, uniques au moins par
"stop_area".

Mais là l'erreur est chez Illenoo qui préfère mentionner "Rennes" que
"Vezin-le-Coquet". Ce n'est pas évident de répondre à tous les usages des
noms... et le suffixage lève les ambiguités pour permettre de reprendre les
noms des opérateurs, mais le nom par défaut devrait être clair en lui-même
et correctement désigner l'arrêt sur le terrain de façon non ambiguë pour
les recherches (on n'est pas obligé de mettre la commune partout).

Reste ensuite à décider comment afficher le nom sur une carte: à haute
résolution, ce nom devrait être fidèle à ce qu'on voit à l'arrêt, mais en
niveau de zoom faible (exemple: carte à l'échelle départementale ou
régionale), les noms précis sont moins utiles que la désignation d'une
ville majeure (exemple "Paris" pour toutes ses gares et aéroports, sinon
"Paris Orly"... ces difficultés ont amené les opérateurs aériens a utiliser
des désignations courtes codées comme "ORY" pour les billets et lever les
ambiguités, c'est une codification, une "ref:*" mais pas un nom et même pas
suffisant pour désigner un terminal comme "CDG 2" ou "Orly ouest").

Quel nom utiliser ? Difficile de faire des choix. Mais je pense que le
"name=*" par défaut doit être le plus proche du nom local en restant assez
clair, et pour les autres usages les name:*=*" suffixés par opérateur sont
appropriés (et ce n'est pas à nous de changer les noms utilisés par les
opérateurs et diffusés sur leurs fiches horaires), de même que les
"ref:*=*" suffixés par opérateur, et les éventuels "short_name:*=*"
suffixés par opérateur.
-------------- section suivante --------------
Une pièce jointe HTML a été nettoyée...
URL: <http://lists.openstreetmap.org/pipermail/talk-fr/attachments/20180626/fa8a56f1/attachment.htm>