OpenStreetMap

Lejun's Diary

Recent diary entries

Parking_space micromapping JOSM method overview

Posted by Lejun on 1 September 2021 in English (English). Last updated on 2 September 2021.

Tag’s use

While the amenity=parking tag is used “de facto”, the amenity=parking_space micromapping oriented tag has been introduced and approved by vote on 2011-05-01. The main reason for it’s introduction is to help people, disabled or not, easily find parking spots inside parking lots without any important downside to it.

Other voted proposals introduced the parking:lane=* and parking=street_side tags and while those are quite useful (I’m still reserved concerning the first), I’d rather map parking spaces directly as those kind of parking’s capacity is generally quite low. The parking:lane proposal even adds:

Consider using parking:lane=* as a simple alternative if the streetside parking spaces are stretched over a longer section of the road and no micromapping of these areas is desired.

Ha! Which fool wouldn’t want some micromapping in its life? Micromapping is love, micromapping is but the purpose of life.

The tag is especially useful in combination with the footway=acces_aisle tag (not to be confounded with service=parking_aisle which is oriented towards vehicular routing) which is used for pedestrian routing in parking lots.

Tools

This tutorial makes use of the JOSM editor along with the BuildingsTools and Gridify plugins and the high resolution of aerial imagery in France. Some similar functions may be found on other editors that I don’t know of, feel free to try and find your own workflow in the journey for the slickest parking lot micromapping.

“Parking:orientation”

The main difficulty about mapping parking spaces comes from its typology. Up to now I have found four different kinds of geometry and I’ll go through them from the simplest to the hardest to map in my opinion. The overall pattern of those is implicit and it’s recommended to use the parking:orientation key to specify if necessary.

Straight (Parallel or perpendicular)

https://wiki.openstreetmap.org/wiki/File:Josm_screenshot_parking_spaces.png

The simplest of them. Just draw a four nodes’ polygon and split into equal spaces. If feeling finicky, you can align it with the nearby access way and/or the building. To do so, I use the BuildingTools plugin.

https://wiki.openstreetmap.org/wiki/File:BuildingTools_Alignement.png

One of its function is to create a four nodes’ polygon aligned to another element when at least two nodes are selected. Just select two nodes from the way (the furthest the two are the better for precision) and use the plugin’s tool. Do not forget to remove the building=yes tag before upload and replace with the necessary tag(s).

https://wiki.openstreetmap.org/wiki/File:Gridify_editing.png

To split the newly created parking spaces row, I use the Gridify plugin to replace the row with X identical spaces with the added tags, X being the number of spaces I counted from aerial imagery. Do check the count, simply a matter of checking if the spaces are aligned to the painted line on the ground, as it’s easy to lose track after a few hours adding hundreds of them. If necessary I then add specific tags to individual spaces such as parking_space=disabled to indicate a parking space to be used by disabled exclusively. Do note that this way of tagging isn’t part of any approved proposal and is simply “in use”.

Diagonal

This kind add one more step to the straight spaces method caused by the angle relative to the trafic flow. To do so the simplest way is to move two nodes from the row before splitting, or the entire line of nodes after splitting. After eyeballing the angle, I like to use the “line alignment” function from BuildingTools to maintain identical angles between parking row.

https://wiki.openstreetmap.org/wiki/File:BuildingTools_Alignement_Use.png

Select two nodes from the first angle and use the plugin tool to make similar angled shape to other rows. Place nodes at the intersections and delete both the constructed shape and unecessary nodes.

Herringbone

https://wiki.openstreetmap.org/wiki/File:HerringbonePattern.png

The method to map an herringbone style parking is similar to the diagonal method. One simply have to move the central nodes or the sides ones before splitting. Personnaly I do prefer the latter as I can make both sides symetrical. As before, I align the overall shape with the central line of the parking spaces and extend it to their depth. Then I create angled shapes after eyeballing one angle. One, pictured on the bottom, symetrical to the left side node, and a second one to have the central node on top. Using these two nodes I can then split each row.

Seesaw

This pattern is the most brainwrecking I encountered to date. While quite pretty, that is for a parking space, I just find it awful to map. The best method I have is to do it “manually” using the tools as alignment helpers. First create the overall shape of the spaces, angle it and split it.

https://wiki.openstreetmap.org/wiki/File:Seesaw_1.png

Then manually add middle nodes to every column (JOSM have a function for equal distancing nodes the shortcut being Ctrl+B). Select every other node and move it to one side.

https://wiki.openstreetmap.org/wiki/File:Seesaw_2.png

Select every “middle” nodes and move them to the other side as needed and congrats, you now have a kinda accurate seesaw pattern that you can use as a guide to outline every single parking space.

https://wiki.openstreetmap.org/wiki/File:Seesaw_3.png

The seesaw pattern on the left side requires supplementary steps to generate. Just use the same method as aforementioned that is the buildingTools plugin to create regularly spaced intersections.

Conclusion

Here is an overview of my method for micromapping individual parking spaces. The method described may lack accuracy, if you know of any better way please do share it in the comments. While not necessarely useful nor groundbreaking, micromapping is possible using existing tools and should be considered not only for routing but as a supplementary way to support OpenStreeMap adoption by organisations.

Location: ZAC de Châteaufarine, Chateaufarine, Besançon, Doubs, Bourgogne-Franche-Comté, Metropolitan France, 25000, France

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: Rue Battant, Besançon, Doubs, Bourgogne-Franche-Comté, France métropolitaine, 25000, France