Bonjour,Plusieurs personnes m'ont pokée pour que je donne mon avis sur ce sujet. Désolée d'arriver un peu après la bataille, je suis plutôt restée fidèle à la liste de diffusion transport <https://listes.openstreetmap.fr/wws/info/transport> ! Pour le contexte, j'ai pas mal mappé du bus dans OSM en France et à l'étranger. J'ai fait de la vulgarisation sur mon blog et IRL, et j'ai participé au développement de nombreux outils d'édition mais aussi pour utiliser ces données, que ce soit pour du plan géographique/schématique, imprimé/interactif, de la conversion en format de données standard pour le calcul d’itinéraire ou l'analyse de réseau, etc. Bref, même si j'ai d'autres troubles obsessionnels cartographiques en ce moment, disons que je connais un peu le sujet.
J'ai plein de commentaires sur pas mal de sujets, mais je ne vais répondre qu'au dernier mail de synthèse, histoire de ne pas remettre une pièce dans la machine et d'essayer de faire avancer le débat.
Je pense aussi que mettre à jour la doc est sûrement le meilleur levier d'action. À noter que les formules de précaution dans la doc (du type "largement utilisée") sont là pour rappeler qu'il n y a pas de consensus global et qu'il y a des endroits dans le monde où on a interprété la définition du tag différemment. Cela me semble toujours préférable d'avoir une doc honnête sur nos faiblesses, plutôt que des guerres d'éditions déportées dans le wiki où chacun va écraser la doc avec sa version qu'elle est mieux. Mais je suis d'accord sur le fait que c'est confusant et particulièrement complexe à comprendre même pour un non-débutant. On peut bosser sur une meilleure formulation pour toutes ces pages je pense.
À noter qu'il existe aussi cette page de doc : https://wiki.openstreetmap.org/wiki/FR:Bus Elle reprend pas mal de choses qui avaient été discutées dans la communauté lors du projet du mois de 2017 <https://wiki.openstreetmap.org/wiki/FR:Project_of_the_month/arr%C3%AAts_de_bus> et c'est celle vers laquelle je renvoie habituellement ceux qui ont des questions sur le mapping (mais elle aussi mériterait une petite mise à jour)
> La documentation du tag public_transport aka PTv2 [2] donne les indications suivantes :
> (...)> _Analyse personnelle _: on pourrait presque penser que ce schéma PTv2 ne sert donc à rien au final. Il n’est pas obligatoire, ne vient qu’en complément de ce qui existe. Pourtant le PTv2 a largement été adopté en France puisqu’une très grande majorité des relations de transports en commun utilise ce schéma PTv2 [8].
Oui ! on a même déjà eu un projet de proposal pour supprimer les tags public_transport introduits par PTv2. De mon côté, je ne suis pas aussi catégorique : autant il a ajouté bcp de confusion sur les objets arrêts et leurs définitions, autant il apporte des clarifications salutaires sur les relations en définissant des rôles explicites pour les différents types d'objets.
> La documentation du tag highway=bus_stop [3] donne les indications suivantes :
> (...)> _Analyse personnelle _: étonnant de trouver un usage seulement recommandé pour highway=bus_stop dans la page wiki highway=bus_stop. Il serait peut-être plus judicieux de placer le terme obligatoire. De fait cette description laisse, à mon humble avis, plusieurs interprétations : l’arrêt de bus / zone d’attente est tagué avec highway=bus_stop ou il est tagué avec public_transport=platform ou il est tagué avec les 2. Au vu des divers retours, il me semble que dans tous le cas (à partir du moment où les relations sont en PTv2) les 2 tags public_transport=platform / highway=bus_stop devraient être utilisés ou je fais fausse route ?
Oui, je partage l'avis : les 2 tags devraient être utilisés systématiquement ensemble. Mais en fait, l'enjeu est sur la définition qu'on donne à highway=bus_stop : si on est d'accord pour dire que c'est l'endroit où les gens attendent pour monter dans le bus, il doit toujours avoir public_transport=platform, qu'il soit dans une relation en ptv2 ou pas. Mais je comprends le choix fait dans la doc, il semble quand même important qu'on précise que la définition du tag n'était pas claire initialement et qu'il y a des endroits dans le monde (en Allemagne et en Suisse par exemple visiblement) où on positionne l'arrêt de bus sur la voirie (et donc dans ce cas, plutôt avec public_transport=stop_position).
Comment tu proposes qu'on reformule cette page ? > /Emplacement de l'arrêt sur la route/ > (...)> _Analyse personnelle _: étonnant de trouver un « il remplace la clé highway=bus_stop ». Devrait-on dans ce cas supprimer le highway=bus_stop de l’arrêt de bus est la première question que je me poserais. Il y a de fortes chances que ce ne soit pas le cas, mais pas évident d’y voir clair. De plus la page cite la zone d'arrêt mais avec un texte comme « Il est parfois intéressant de créer une relation de type type=public_transport et public_transport=stop_area » pas sûr que tous les contributeurs/contributrices soient motivé(e)s pour tagguer ce type de relation.
Complètement d'accord, à supprimer. Le tableau complet est à reprendre, il y a pas mal d'éléments confusants.
> _Analyse personnelle _: dans ce cas aussi apparait un problème qui est relaté dans la page wiki public_transport [2 chap. 3.1] : le problème du double taggage public_transport=stop_position et highway=bus_stop sur 2 nœuds différents qui peut poser problème (PS : ce problème n’existe sans doute pas avec la solution « germanique » puisque public_transport=stop_position et highway=bus_stop sont sur le même nœud). Dans ce cas on peut se rabattre sur la solution de ne mettre que les public_transport=platform / highway=bus_stop dans la relation de transport en commun avec le rôle platform comme indiqué sur la page wiki. Il faudra accepter une perte d’information puisque l’emplacement de l’arrêt du véhicule n’est plus indiqué, sauf dans le cas où la relation zone de l'arrêt (public_transport =stop_area) existe, mais celle-ci n’est qu’optionnelle. Et au regard des statistiques |6] et [7] je crains malheureusement qu’il n’y ait pas beaucoup de ce genre de relations. Donc pas forcément évident de basculer sur cette solution en gardant la même précision. Le PTv2 selon [2] était pourtant censé « […] donner de nombreux détails sur les arrêts (lieu où s'arrête le bus, l'emplacement de l'abri ou du quai...) ». Du coup sans public_transport =stop_area et sans public_transport=stop_position c’est un peu perdre l’essence même du PTv2 ou fais-je encore une fois fausse route ?
Là, je ne suis pas sure de comprendre ce que te chagrine 🤔En effet, ou bien tu ne mappes que l'arrêt à côté de la route, avec highway=bus_stop et public_transport=platform, et tu les mets dans la relation avec le rôle platform Ou bien tu ajoutes en plus un noeud sur la route avec public_transport=stop_position, et tu le mes aussi (en plus) dans la relation, avec le rôle stop. Il n'y a pas de doublon, puisqu'on a un seul objet avec highway=bus_stop et que chaque objet a un rôle distinct qui permet de bien les différencier, avec ou sans relation stop_area. Et ça ne me semble pas problématique non plus d'avoir des relations sans public_transport=stop_position du tout. La plupart des usages des données OSM que j'ai pu expérimenter fonctionnent parfaitement avec juste un arrêt de type platform (pour les bus en tout cas, c'est plus chiant pour d'autres modes où l'arrêt est traditionnellement plutôt un emplacement de véhicule qui s'arrête)
> N'en déplaise à mon opposant déplacer uniquement le highway=bus_stop de l’emplacement de l’arrêt sur la zone d’attente comme il l’a fait ne devrait résoudre qu’en partie le problème. Ceci devrait somme toute créer les doublons, évoqués plus haut, dans les relations de bus. J’en déduis que ce rattrapage ne devrait se faire uniquement qu’un créant la zone de l'arrêt / public_transport=stop_area et en rattrapant toutes les relations route=bus contenant cet arrêt pour retirer le nœud public_transport=stop_position des relations. Est-ce que les spécialistes de la question pourraient me donner leur avis sur cette affirmation ? Ça m’aiderait d’avoir un retour afin de savoir vraiment ce qu’il y à faire dans le cas où je rattrape la zone de la métropole de Nice Côte-d’Azur.
Pas nécessaire de retirer les stop_position des relations, on peut avoir les deux sans soucis tant qu'on a bien un rôle platform et un rôle stop, le tag public_transport:version=2 sur la relation, et bien sûr toujours un seul objet avec highway=bus_stop. Personnellement, je déconseille l'usage des stop_area, ça rajoute beaucoup de boulot, notamment pour la maintenance, sans avoir une valeur ajoutée énorme.
> Je comprends l’idée de ne plus vouloir indiquer les routes dans l’itinéraire pour simplifier au maximum, mais c’est un peu comme vider une relation de randonnée de son itinéraire.
Tout à fait d'accord. C'est vrai que c'est long et que ça nécessite un peu d'expérience avec l'édition OSM, mais ajouter les trajets a clairement de la valeur. Et je dirais même plus : bien plus que de se créer 2 ou 3 objets abstraits pour modéliser un malheureux arrêt de bus.
Et bravo au passage aux participants pour la qualité des échanges. Ces sujets sont souvent douloureux à faire avancer et j'avoue être agréablement surprise par la constructivité de cette discussion ;)
Bonne soirée, -- Noémie Lehuby
OpenPGP_signature
Description: OpenPGP digital signature
_______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
