OpenStreetMap

Lejun's diary

Recent diary entries

Des usages d'un trottoir

Posted by Lejun on 16 September 2020 in French (Français)

Le trottoir est une partie de la route située sur le coté pour l’usage des piétons, souvent séparée de la chaussée par une bordure

La cartographie est un travail subjectif, toujours à cheval entre structure et fonction, et OSM n’y fait pas exception. Sans parler du sujet brûlant du stationnement gênant officieusement toléré sur ceux-ci, on peut être amené à se demander où commence et se termine un trottoir Exemple photo d'une "fin" de trottoir

Historique

Brièvement, OpenStreetMap est un outil cartographique qui se veut objectif, ce qui n’empêche pas une forme de subjectivité. Aux débuts, les trottoirs étaient généralement indiqués à l’aide de l’attribut sidewalk=* destiné à être utilisé sur la route qu’ils bordent, on compte encore près de 180 000 utilisations (70 000 étant des ‘sidewalk=separate’ indiquant un chemin distinct). Il y aurait ainsi une hiérarchie plaçant les utilisateurs de véhicules au dessus des piétons, ce qui est son propre débat. La seconde méthode qui est légèrement plus utilisée consiste à créer un chemin distinct et d’utiliser la combinaison d’attributs ‘highway=footway’ + ‘footway=sidewalk’.

Chaque méthode a ses avantages et inconvénients, la première ayant une certaine élégance dans sa simplicité tandis que la seconde est plus versatile et ouvre à un usage plus avancé. L’approche scientifique d’atteindre l’objectivité est d’être exhaustif, pour cela, on favoriserait la versatilité de la seconde méthode sur la simplicité (qui est un défaut à partir du moment où elle ignore les possibles espaces entre la chaussée et le trottoir, comme des voies cyclables ou de stationnement). Cela n’est cependant pas une fin en soi et il subsiste de nombreuses limitations qu’il conviendrait de traiter notamment dans un contexte d’accessibilité.

La fonction du trottoir comme support de transit

Dans une “majorité” de lieux (qui pourrait tout aussi bien être une minorité occidentale surreprésentée par un accès aux outils de communication), le trottoir est la voie de circulation des piétons. Un espace est alors fragmenté en multiples îlots reliés par des passages cloutés et il est relativement simple de créer un algorithme de routage répondant de la théorie des graphes.

Dans les faits cela s’avère plus complexe, notamment à cause de cette hiérarchie des usagers par les aménageurs non pas sans être accompagnée d’une ignorance quant aux besoins des personnes à mobilité réduite. Exemple photo d'une "fin" de trottoir Ici, comment terminer le tracé du trottoir ? Strictement parlant, le trottoir prend officiellement fin et amène sur un cul-de-sac pouvant faire appel à l’attribut noexit=yes. Cela pose cependant problème dans la mesure où en tant qu’usager valide, il m’est tout à fait possible de descendre sur la chaussée à cet endroit comme le font probablement les habitants locaux et que l’algorithme précédant inviterait sûrement à passer ailleurs. À l’inverse, une personne en fauteuil roulant pourra difficilement descendre (pour potentiellement devoir remonter) la bordure. L’attribut, purement fonctionnel, noexit=yes ne permet pas la distinction entre la-dite bordure de trottoir ou le cul-de-sac bordé de murs de 2m de haut (et encore, certains viendraient me prouver qu’il est possible d’escalader les-dits murs). L’on pourrait également avoir la “jonction facile”, simplement continuer le trottoir parallèlement à la route qu’elle borde jusqu’à rejoindre la rue perpendiculaire et ajouter en complément la bordure adéquate. Seulement, cela serait contraire au principe de vérifiabilité, l’itinéraire n’ayant pas de réalité physique, et tout environnement deviendrait rapidement un sac de nœuds, et chemins.

La structure du trottoir comme support urbain

Par ailleurs, un trottoir ne se limite pas à un simple support de déplacements mais est également un espace pouvant accueillir, entre autres, du mobilier urbain. Cet espace défini entre d’un côté le bâti et de l’autre la bordure est naturellement hétérogène. De nombreux éléments sont sujets à variations tels que la largeur, la pente, le revêtement, … Si bien que la manière la plus exhaustive qu’il soit serait de ne pas utiliser un chemin mais un polygone pour représenter un trottoir (cela s’appliquant également aux autres types de voirie). Dans la mesure où sont disponibles des méthodes pour décrire la bordure de trottoir et le bâti, il devient plus approchable de dessiner l’espace occupé par le trottoir et l’infrastructure routière en général. Reste alors à savoir comment prendre en charge ce type d’élément pour les algorithmes d’itinéraires. Jusqu’alors il reste nécessaire de dessiner au sein des aires de circulation des chemins quand bien même ces derniers n’ont aucune existence physique.

Conclusion

Définir un trottoir comme un chemin est naturellement limité de par la nature du trottoir qui est avant tout une surface, un espace. OpenStreetMap est une base de donnée versatile qui permet de recréer l’environnement, la difficulté étant de restituer au mieux le caractère dynamique et graduel de la réalité. Où commence un trottoir et où s’arrête-t-il ? Est-il identique du début à la fin ? Une “limitation”, qui ne fait que répondre aux usages, est ce consensus à utiliser des nœuds et chemins. Parler d’éléments existants en trois dimensions à l’aide de dimensions moindres induit nécessairement une perte d’informations et il convient de se demander si cette perte est pertinente ou une simple conséquence d’un confort d’utilisation. Cette même notion de confort d’usage se retrouve dans la manière de représenter les éléments. Tandis on cartographiera une structure, tandis ce sera un usage. Que signifie un trottoir si ce n’est un volume artificiel à proximité d’une surface bitumée ? Que devient ce trottoir s’il n’est pas utilisé (du moins pas à son usage principal si tant est qu’il y en ait un) pour raison par exemple de sa faible largeur ?

PTv3 : bus_stop, position_stop, platform, shelter, stop_area, station et autres joyeusetés

Posted by Lejun on 31 July 2020 in French (Français)

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 :

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.

Location: Battant, Besançon, Doubs, Bourgogne-Franche-Comté, France métropolitaine, 25000, France