J’ai récemment repris l’entreprise de mettre à jour l’intégralité des lignes de transport en commun Ginko à Besançon. Je m’étais chargé de 24 lignes l’été passé sans finir le travail. Une année plus tard, la situation n’a pas été améliorée et j’ai décidé de terminer le travail. Étant seul sur la tâche, des erreurs sont possibles sur le réseau et je m’en excuse d’avance. Ayant bientôt terminé, j’en profite pour donner mon avis sur le modèle actuel autour des transports en commun. Cela pourra s’avérer utile pour quiconque souhaitera apporter des modifications ultérieures sur le réseau Ginko, son propre réseau local, ou s’intéresse aux transports en commun en général.

État de l’art

Au cours de son évolution, la méthode de cartographie des transports en commun a compté quatre propositions majeure à savoir :

• PTv1
• Modèle Oxomoa
• PTv2
• Modèle Affiné

Le wiki dispose d’un portail introduisant du thème. Il semble que les premiers efforts francophones datent de 2010, année de traduction de la page en français. Depuis 2015, la page redirige vers la page du modèle PTv2. Je ne ferai qu’un survol des modèles et vous invite à consulter chacune des pages citées pour plus de détails.

Modèle PTv2

Actuellement, une ligne de transport en commun est construite sur plusieurs échelles emboîtées :

• Les arrêts sont définis par des paires de nœuds pour localiser d’une part le quai où attend le passager et la position où s’arrête le véhicule sur sa voie :

public_transport=platform highway=stop_position

Autant le premier est généralement placé sur la borne indiquant l’emplacement de l’arrêt, autant le second peut difficilement répondre au critère de vérifiabilité sur lequel est basée OSM. Un argument en faveur de l’utilisation des deux attributs est qu’il existe des cas où le lieu d’embarquement, où s’arrête le véhicule, n’est pas situé au même endroit que le quai. Ce qui est entendable mais qui personnellement ne permet pas sa justification.

• Les deux nœuds sont ensuite intégrés au sein d’une relation stop_area, celle-ci a pour but de regrouper les éléments d’un arrêt et il est possible de l’utiliser pour associer des caractéristiques physiques du quai à savoir la présence d’un abri, d’un banc, d’une poubelle, etc. Cette relation est destinée au consommateur qui nécessiterait de renseigner ces informations sans avoir à chercher les éléments autour du quai d’embarquement. Cette relation repose cependant sur l’existence des deux nœuds précédents. Son utilisation reste cependant optionnelle et n’est nullement obligatoire.

type=public_transport public_transport=stop_area

• Une relation route permet de tracer l’itinéraire proprement-dit, en sélectionnant les divers tronçons de route prééxistants ainsi que les arrêts à la fois avec les quais et les positions d’arrêt. De cette manière on renseignerait tout de même le stop_area précédant, pourtant optionnel, ce qui rajoute d’autant plus de complexité lors de la création des itinéraires mais aussi de leur maintenance par la suite.

type=public_transport public_transport=route

• Enfin, toutes les relations route (spécifiques à chaque variation du trajet) sont entrées dans une relation route_master générale où les même informations que précédemment sont requises à savoir le type de véhicule, la référence de la ligne, le nom de ligne (différent de celui utilisé pour les routes), de l’opérateur, du réseau et de la couleur.

type=public_transport public_transport=route_master

Un point mis en avant de ce modèle et qu’il pourrait coexister avec l’ancien modèle. C’est selon moi une erreur, quand bien même on considérerait l’argument de compatibilité puisque rendant inutile un modèle commun pour préférer un environnement mixte où il faut prendre en compte deux méthodes plutôt qu’une qui a pourtant été validée au cours d’un vote. En conséquence, il est usuel de recommander l’utilisation d’un modèle hybride composé à la fois des particularités du PTv2 et PTv1 rajoutant encore en complexité à l’ensemble.

Modèle “PTv1”

Ce premier modèle résulte d’une proposition visant à unifier les méthodes de cartographie des réseaux de transport en commun sur la base du standard Transmodel utilisé à l’échelle européenne. C’est un aspect non négligeable dans l’optique du projet OpenStreetMap à savoir de rendre libres des données, puisque le format est déjà utilisé par de nombreux opérateurs. Transmodel définit des points importants à savoir le type de véhicule et le stop place. Ce dernier se définit simplement par le lieu où un passager pourra monter ou descendre d’un véhicule aux horaires prévus et n’implique aucun aménagement physique spécifique. De cette façon, l’idée colle à l’usage de la relation stop_area bien que pouvant aisément être simplifié à l’usage du stop_positon où le véhicule est à l’arrêt.
Bien que simpliste, ce modèle est un premier pas dans la cartographie des réseaux sous la forme de trois éléments simples et accessibles à la plupart. Il ne nécessite en effet que :

• Le point d’arrêt du véhicule sur la voie

highway=bus_stop

• Un quai d’embarquement

highway=platform

• Une relation les unissant en zone d’arrêt

site=stop_area

On comprend de ce fait comment les deux versions décrites peuvent coexister, bien qu’il y ait une redondance d’attributs différents que ce soit pour le quai ou le point de halte.

Modèle Oxomoa

Ce modèle très proche du PTv2 est aujourd’hui obsolète. Il propose d’étendre le PTv1 notamment autour des véhicules se déplaçant le long de lignes tels que des tramways. En parallèle de quoi la structure des arrêts est revue de manière à intégrer la possibilité qu’un arrêt soit utilisé par plusieurs réseau à l’aide de la relation stop_area_group. Cela ouvre la possibilité de cartographier des échangeurs tels que les pôles à Besançon par exemple en créant une relation unissant les arrêts bus et tram d’un même lieu.

Modèle Affiné

Proposition datant de 2018 pour unir PTv1 et PTv2, certains parlent de PTv3 bien qu’il est à éviter de le préciser dans l’idée que ce soit un consensus et pas une couche supplémentaire. Le PTv2 complète le PTv1 mais met en évidence les limites de la méthode en introduisant des situations à l’utilité discutable tels que la multiplicité des attributs et objets transformant la cartographie des réseaux en une tâche fastidieuse et complexe. Ainsi, l’amélioration majeure serait la création d’un objet centralisant les attributs d’un arrêt. Toutes les informations seraient données à l’aide d’un nœud unique représentant l’idée d’un arrêt, celui-ci n’ayant pas toujours de marqueur physique.

highway=bus_stop

Bien que cela soit contraire au principe de vérifiabilité, cette pratique me semble acceptable et même bienvenue : la multiplicité des éléments d’un arrêt est résolue, il sera toujours possible de placer le nœud sur un marqueur physique et OSM serait rendu accessible aux lieux en développement où on observe une nette différence avec les pays développés, que ce soit au travers de l’infrastructure ou l’accès aux technologies. Ce faisant, la relation stop_area gagnerait en utilité puisque liant l’infrastructure physique à l’usage.
Pour une raison que j’ignore, cette proposition semble avoir été mise de côté et n’a toujours pas été soumise à un vote.

Conclusion

La question des transports en commun est primordiale dans le développement d’OSM. Une telle collaboration permettrait de toucher un large public ce qui ne peut être que bénéfique, mais l’évolution a rendu la méthode actuelle relativement complexe et inaccessible à la fois pour les contributeurs mais également les consommateurs. Ces derniers disposent déjà d’un format structuré de données qu’il n’est pas possible d’importer entièrement sous OSM, on peut néanmoins en capter l’essentiel à savoir les lieux d’arrêts et les horaires.
Le modèle affiné propose de rendre optionnel les tronçons empruntés au sein d’une relation route. Je trouve cela surprenant étant donné l’importance de cette information dans le cadre notamment d’évènements affectant la voirie où il est indispensable de pouvoir dévier la circulation pour maintenir au mieux le service.
Au delà de la simplification de la structure, je souhaite encore une fois appuyer l’importance des termes utilisés. Un quai (ou platform) est une structure physique de la même manière qu’un bâtiment, les attributs doivent être au plus proches de leur sens de manière à rester accessible aux nouveaux contributeurs. Pour cette raison, l’association de bus_stop sous highway me parait inapproprié et ma préférence irait pour public_transport sans que cela ne pose de problèmes de compatibilité avec PTv2.
Plus accessoire, l’attribut name est défini depuis le PTv2 par :

< vehicle type > < reference number >: < initial stop > => < terminal stop >

Cette pratique me déplaît d’une part par la redondance en utilisant des informations déjà renseignées sous la forme :

type, ref, from et to

De plus, elle limite la possibilité d’utiliser le nom officiel de l’itinéraire utilisé par la compagnie de transport. En résumé peut importe la raison, il existe une grande diversité de méthodes actuellement à l’usage ce qui doit être résolu et je suis impatient de pouvoir voter sur le PTv3 et peut être voir de nouveaux contributeurs locaux de manière à ne plus me sentir aussi seul à travailler sur le réseau.