C'est vrai que c'est un mauvais conseil, et en fait même ce tag n'est pas
nécessaire du tout puisque ce qu'il cherche c'est savoir si la relation
route a des membres sans rôles, ou si des rôles ont été définis avec le
nouveau schéma.

L'absence totale de rôle devrait automatiquement correspondre à l'ancien
schéma.
Pas de rôle pour les membres de la relation veut *déjà* dire
"public_transport:version=1" (et c'est la seule chose que teste JOSM, sans
même savoir quels rôles sont utilisés et pourquoi il en aurait besoin pour
lever des ambiguités, mais je me demande bien lesquelles !).

Les développeurs de JOSM n'ont pas réfléchi et à mon avis cette prétendue
"erreur" est à désactiver, au plus ce devrait être un warning pour le cas
où on aurait oublié des rôles:
Normalement si on a déjà au moins un rôle, les rôles doivent être partout.
Sinon aucun rôle nulle part :
* tous les chemins membres sont supposés être alors bidirectionnels sans
restriction forward=seulement dans la direction du chemin tracé, ni
backward=dans le sens opposé au chemin tracé)...
* hormi dans le cas des sens uniques (oneway ou junction=roundabout) où la
direction est imposée (a priori! car on a des rues à sens uniques pour les
véhicules, sauf pour les bus qui peuvent emprunter une voie réservée en
contre-sens).

Une fois les directions définies, JOSM devraient être capable de vérifier
que la route forme un chemin contigu pour la ligne entière sans emprunter
de sens unique en sens opposé pour lequel cela n'aurait pas été autorisé
explicitement par un tag supplémentaire sur le chemin.

Sinon JOSM se débrouille toujours aussi mal pour afficher le graphique
d'icônes quand une ligne se sépare en deux parties (voies de circulation
séparées) puis se rejoignent (par exemple sur un chemin unique de
rond-point fermé)

Le nouveau schéma ne résoud cependant pas encore correctement les lignes
ayant des branches en Y dont une des branches est parcourue dans les deux
sens en faisant demi-tour au bout de la branche pour continuer sur l'autre
branche: c'est toujours ambigu justement quand les branches du Y sont sur
un rond-point fermé.

Mais le sens de parcours reste ambigu même sans ce rond-point (rien ne dit
que le Y est parcouru en gardant la droite ou si la petite branche n'est
pas parcourue seulement dans l'autre direction en tournant à gauche. C'est
pourtant important pour savoir dans quel ordre se succèdent les arrêts et
calculer un temps de parcours, ou si le bus en fin de service parcourera
effectivement cette branche ou ne fera que passer devant puisqu'il ne fera
pas le trajet en sens retour.

La seule façon propre nécessiterait des rôles plus détaillés pour donner un
ordre des branches en Y.

Une autre façon de faire est de créer une relation route-master et créer
deux relations séparées pour chaque sens de la ligne (et aussi pour chaque
variante pour certains services à certaines heures ou certains jours, par
exemple le dimanche ou en service de nuit, où les lignes sont souvent plus
longues, et regroupées sur un trajet unique, mais moins fréquentes, et font
des raccourcis sans desservir tous les arrêts). Mais là il faut le nouveau
schéma de toute façon pour restreindre chaque route dans le route-master à
leur direction.





Le 4 mars 2014 00:55, Pierre-Yves Berrard <pierre.yves.berr...@gmail.com> a
écrit :

> Depuis peu, le validateur de JOSM indique avertit d'une absence du tag
> "public_transport:version" sur les relations de type=route+route=bus.
>
> Légèrement intrigué, j'ai cherché le pourquoi sur le wiki, sans succès.
> J'ai finalement trouvé la réponse sur le wiki de JOSM :
> https://josm.openstreetmap.de/ticket/9545
>
> En fait, public_transport:version=1 correspond à l'ancienne façon de
> cartographier et public_transport:version=2 au nouveau schéma.
>
> Que penser de ce tag complétement déconnecté des données ? (servant en
> fait uniquement au validateur de JOSM)
>
> Pierre-Yves/the_knife
>
> _______________________________________________
> 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

Répondre à