Lejun's Diary

Recent diary entries

Journey searching for a facade survey app

Posted by Lejun on 24 October 2021 in English (English). Last updated on 25 October 2021.


For a while now I’ve been contributing in smallish countryside cities. While not small through their surface area nor their population count, they have a low proportion of active OpenStreetMap contributors and their urban development share a common pattern that is “downtown commercial arteries” leading me to classify them as “countryside cities” rather than “modern evolved and distributed cities”. Those commercial arteries are defined by a street network of mixed uses buildings with shops at ground level and housing at higher levels ; Walking down one of these street, one could model the facade as a succession of doors allowing access to either a shop or housings and that’s exactly what I am looking a software for.


I have searched and tested multiple solutions in my journey but haven’t quite found the ideal one so far. The criterias I am looking for are as follows:

  • Lightweight: I’m one of those still using old hardware limited both in memory and performance ;
  • Offline map: I’m a cheap guy, allow me to cache the mapping area through WiFi before leaving home ;
  • “Notes” creation rather than Waypoints: Most of the apps allows you to create “waypoints” on a GPS trace, while those have their use I definitely can’t use those as GPS function is rather battery intensive and high-rise buildings, or simply clouds, highly affects signal quality. Given a map (see aforementioned point) I would rather be allowed to pinpoint a location and add my own tags to it. Those data could then be exported to a computer to be processed through comparison with OpenStreetMap data.

While not dealbreaking, the app use could be extended through an uncluttered UI and workflow, a customizable presets to one-tap buttons function could make themed mapping parties a breeze, and pictures/voice records.

Tested solutions

Below are some solutions I tested with no success so far.

“Utility” solutions

Three applications stood out for their uses, having clear aims, they offer both mapping function and lightweightness. Sadly, none of them fill all my criterias.

  • Keypad Mapper 3: The last version of the Keypad Mapper suite, last updated in 2013, is explicitly oriented toward house numbering. While offering rather interesting functions such as “relative to position note location”, it doesn’t offer presets nor pinpoint function. It is GPS dependent and while one could use the pad to write comments instead of housenumbers the process would be painfully slow. Moreover, there seems to be an issue with the app making users share cell towers location to CellTowerID. While I do contribute to this database too, I would rather have the choice to do so ;
  • OSMTracker: One of the KeypadMapper successors, while not being perfect offers more flexibility and uses. As I see it, the application follows the same workflow of a buttons-filled screen but with the possibility to create presets. The so called custom layouts, while rather difficult to create, can easily be shared to multiple devices. The only downside in my opinion is the once again “waypoint GPS dependent” function rather than a pinpoint one ;
  • StreetComplete: While having many benefits, StreetComplete is too limited for my use. Its main aim could be described as “data refinement” rather than mapping. Furthermore, it only offers limited offline functions ;
  • GeoNotes (Suggested by GOwin): The closest app to what I’m searching so far. It is indeed very lightweight and run smoothly on my device allowing me to take notes and pictures to export. On the other hand it still insists on having my position without the option to disable it and offer no offline map. I still decided to keep it and give it a try in the future with a few workaround for the two point aforementioned. One can decide to not give it the permission to search for location, an option to disable it would still be welcomed for less tech-vocab users and experimenting different methods. It’s still possible to use WiFi at home to cache an area data, Not sure about the memory cap but will certainly test it.

“Maps” solutions

These solutions deliver a map-like experience, which can be extended with some freemapping functions at the cost of ressources use and device bloating. Using those for mapping require prior mapping experience and can be clunky for first time users.

  • Organic Maps: A fork developped by the MapsMe team, without any editing capabilities. I find it quite interesting in its own category, that is an offline map, and could use it as my main smartphone map application given some refinement. One thing I disliked while testing it is the absence of option to turn off GPS, launching the app automatically starts location search even before acquiring map data (that needs to be downloaded at first use). I have high expectations for this app in the future if given the option to turn off GPS (using it as a map exclusively) and some refinement to the search function ;
  • OSMAnd: One of Android OpenStreetMap based bigshots and my main smartphone map application. It offers both a map and editing functions but I find it quite cluttered and ressources heavy. Not using it daily, I often find myself lost in the interface. Some links directing to the same content while important ones are scattered among minor ones. I would prefer a standalone application to this, more lightweighted that could be installed on devices for mapping parties.

“Editors” solutions

Fully fledged map editors offer limitless tagging possibilities to users at the cost of being too complex for beginners and ressources intensive. I would rather have a lightweight data surveyal tool and a power editor at home than having under my, more often than not, frozen fingers a tool capable of nuking entire OpenStreetMap areas given an hazardous tap.

  • Vespucci: The community goldstandard OpenStreetMap mobile editor, offers a complete contribution solution on a smartphone. Tried it once and instantly made my device freeze and reboot, potentially because its ressource consumption or my device being outdated. For the glimpse I caught of the user interface, it seemed very bloated on my small screened device ;
  • OsmGo! (Suggested by jambamkin): While not being what I’m looking for it’s nonetheless interesting. I see it as a kind of light iD with more than enough editing capabilities to work with POIs and nodes. It doesn’t seem to feature offline maps nor export function thus wouldn’t fit in my expected workflow.

Special cases


My computer editor of choice for its capabilities and extensive addons library. On top of not being keen of the idea of laptop surveying, it would not be an acceptable solution for mapping parties and beginners. I would still use it to process surveys data, comparing with OpenStreetMap database.

Pen & Paper

Of course, the simplest, most accessible and lowtech answer would be to grab a pen and some paper onto which one could have printed the building footprint through OpenStreetMap. Using some kind of code it’s rather easy to have “presets”. Unfortunately that process is too time consuming, tinkering heavy and beginner unfriendly in my opinion.


Until recently, I considered buying an action cam to survey street facades and upload pictures to Mapillary and/or KartaView (previously known as OpenStreetCam). The two of them are the most known survey pictures hosting services, and while sharing them under open licences they aren’t fully opensource. The aquisition of Mapillary by Facebook back in 2020 has been a major dealbreaker to me while looking for a decentralized and fairer internet and the idea will be undefinitely pending until the next Mapillary.


During my journey I searched for a way to make street surveyal easier. So far, one have to stop at each doorstep to take notes while hoping to have a precise enough GPS signal. My main take on it would be to completely ditch the use of GPS location service for an offline map marker system. So far I found offline maps or marker solutions, but none offered both of them. The closest is GeoNotes, courtesy of GOwin, which isn’t perfect but fine enough for fieldtesting (I’ll try to come back and give an update once that’s done). Once again, the ideal workflow as I see it would be a lightweight smartphone application that allows its user to describe elements’ succession while walking down a street before exporting it to a computer for further processing. I am by no mean expert in UI, UX, software development nor even GIS. This diary entry simply aims to share my idea upon making data surveyal easier through a basic application that could be further extended by users feedback.

Edit: Formatting, typo and moved JOSM to “special cases” as someone who, didn’t liked me putting it next to Vespucci in the “Editor” category, nagged me to do so. Also added some users’ suggestions.

Location: Bourgogne-Franche-Comté, Metropolitan France, 25000, France

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.


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.


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)

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.

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).

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”.


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.

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.


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.


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.

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.

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.

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.


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


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.


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 ?

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


  • Un quai d’embarquement


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


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.


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.


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: Bourgogne-Franche-Comté, France métropolitaine, 25000, France