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