Inspiré du travail de SK53[1] j’ai ressorti les couverts et me suis relancé sur R (Un langage de programmation destiné au traitement de données). L’occasion d’à la fois me dérouiller un peu, de voir les interactions entre les communautés R et OpenStreetMap, et d’apprendre à jouer avec des données spatiales. Le code est fonctionnel mais nécessite encore un peu de peaufinage[2].

R n’est pas fourni par défaut sur ma distribution, ce qui a donc nécessité les bricoles d’usage pour l’installer avec l’interface RStudio – À défaut d’alternatives. Je ferai abstraction des installations de paquets nécessaires pour les librairies R par la suite (De tête il y en a eu pour pas moins de 2 Go).

En route

J’avais comme point de départ l’entrée de journal très succincte, ainsi qu’un morceau de code partagé sur le Fediverse :

qplot(x=area,data=ten,
geom="histogram",binwidth=25)
+aes(y=cumsum(
after_stat(count))
)

+labs(x="area of pitch", 
y="count", title="Area of Tennis Courts in Great Britain on OSM")

+scale_x_continuous(
breaks=seq(0,2500,250),
limits=c(0,2500)
)

Bien qu’utilisant une syntaxe qui ne me sied guère le code semble relativement propre – Spoiler, je ne l’utiliserai finalement pas –, reste à savoir comment générer le jeu de données : je n’ai pas trouvé d’explication sur le passage d’une requête Overpass vers le calcul de surfaces. Ni le nettoyage des données au passage, je suppose qu’il y a aussi bien des nœuds, que des polygones, que – sigh – des multipolygones.

Spatial R : Comme le Spécial K™ mais avec plus que des lignes

J’utilise les paquets suivants :

• dplyr : Manipulation de données générale ;
• osmdata, sf, et units : Géographie ;
• ggplot2 : Standard pour les graphiques.

Overpass dans R

En lieu et place d’un jeu de donnée externe, osmdata permet de directement faire une requête Overpass. Je l’utilise pour rechercher les chemins (ouverts ou fermés) qui portent les attributs leisure = pitch et sport = tennis.

À noter que la valeur de timeout ne suffit probablement pas pour le projet initial et qu’il faudra attendre un certain moment, je me limite au département du Doubs comme preuve de concept.

item <- area_boundingBox %>%
  opq(osm_types = "way", timeout = 180) %>%
  add_osm_feature(key = "leisure", value = "pitch") %>%
  add_osm_feature(key = "sport", value = "tennis") %>%
  osmdata_sf()

Nettoyage et calcul

Le code a généré une variable complexe avec des listes imbriquées, on peut de manière simple ne garder que les polygones – Ne me demandez pas de détails sur les autres éléments –, et calculer un nouveau champ area pour chaque élément correspondant à sa surface.

polygons <- item$osm_polygons

polygons <- mutate(polygons, area = st_area(polygons$geometry))

Ça donne quoi ?

Vient alors le fun, la révélation des résultats ! La fonction summary permet de simplement voir l’homogénéité du jeu de données, s’il y a des valeurs extrêmes ou non.

summary(polygons$area)

Min. 1st Qu.  Median    Mean 3rd Qu.    Max. 
61.09  536.55  634.11  640.94  682.94 2688.95

La valeur standard étant 260,87 m², on peut raisonnablement répondre à la question initiale de SK53 en retrouvant sa conclusion : non, les courts de tennis ne sont pas cartographiés unitairement mais plutôt par lot de 2 ou 3 si l’on se base sur les valeurs de 1er et 3eme quartiles (75 % des courts).

On pourrait s’arrêter ici, mais ce serait dommage de ne pas avoir au moins un joli graphique à encadrer chez soi :

• ggplot(polygons, aes(y=area)) + geom_boxplot() donne une version visuelle de tableau précédent : La majorité de terrains fait entre 540 et 680 m², 25 % se trouvent en dehors ;
• plot(polygons$area) donne un graphique brut mais néanmoins intéressant révèlant les différents éléments du jeu de données ;
• ggplot(polygons, aes(area)) + geom_freqpoly() est encore plus intéressant, on observe globalement deux pics correspondants à une centaine de terrains proches des 260 m² attendus, ainsi que de 640 m² potentiellement deux terrains et l’espace les séparant ;
• ggplot(polygons, aes(area)) + geom_histogram(binwidth = 50) idem que précédemment.

La fonction coord_cartesian(xlim = c(200, 700)) permet de mettre en valeur ces deux pics en zoomant dessus.

Pour étayer la réponse à SK53 : Non, les courts de tennis – dans le Doubs et jusqu’en date de l’analyse – ne sont pas cartographiés unitairement… mais par paire ! La distribution ici penchant plus vers les paires que les simples comme en Grande-Bretagne.

Ré-application : Passion bitume

Je n’ai que peu d’intérêt pour le tennis – pour ne pas parler de dégoût. Le code est cependant assez simple pour pouvoir être ré-appliqué à d’autres thèmes comme le golf et ses vastes gazons, ou, de loin un sujet que je préfère… les parkings. Il suffit alors de remplacer l’attribut de requête en add_osm_feature(key = "amenity", value = "parking") et le même code peut-être réutilisé sans vergogne !

On dénombre donc 11441 parkings surfaciques dans le Doubs, dont 75 % mesurent entre 100 et 830 m² – le maximum étant à 131176 pour le parking de PSA à Étupes rue Pierre Marti ! Le minimum est de 4 m², valeur plus que douteuse et en effet, cela vient d’éléments à côté de Murten (Suisse) où la valeur parking_space serait plus pertinente en plus d’avoir une géométrie sous-évaluée – Mes tracés sur images sont plus proches des 15 m² habituels.

Références

[1] Do people map single tennis courts?, SK53 2023

[2] R-OpenStreetMap_SurfaceArea, LeJun 2023

La conflation, également appelée appariement ou fusion de cartes, permet d’obtenir un jeu de données à partir de plusieurs. Cela vise en autres à une meilleure qualité, et à limiter la redondance des données. Différents outils et méthodes permettent cela sous OpenStreetMap, dont une extension JOSM.

Principe général

L’idée générale est simple, il suffit de prendre les deux jeux de données et comparer un à un chacun des éléments de part leur géométrie (position spatiale et forme) et caractéristiques. Manuellement, comparer des données spatiales revient à avoir chaque jeu de données sur un calque et superposer les deux pour mettre en évidence les différences géométriques avant de comparer les caractéristiques de chacun d’eux et voir si une version est plus précise que l’autre, ou si des données concurrentes apparaissent. Numériquement, le même principe est utilisé, seulement il est grandement facilité via des scripts automatisés qui apparient les données selon différent critères. Mais bien sûr, rien n’empêche de le faire manuellement avec les données sur deux calques, ce sera juste très long et répétitif.

Extension « Conflation »

L’extension repose sur la fonction « Remplacer la géométrie » de l’extension « UtilsPlugin2 » qu’il faut également installer. Cette fonction permet de fusionner les caractéristiques de deux éléments en ne conservant qu’une seule des deux géométries.

Les deux jeux de données auront un rôle de « Référence » et de « Sujet ». Le premier correspondant usuellement aux données à importer et le second aux données OpenStreetMap.

Prétraitement des données de référence

Par simplicité, je préfère travailler les données en dehors de JOSM via un tableur ou des commandes de remplacement. Il s’agit alors de transformer les données de manière à coller aux attributs OpenStreetMap en perdant le moins possible de détails. Les puristes le feront sous format GeoJson, Shapefile ou que sais-je encore, je suis un homme simple, j’aime les csv.

Pour l’exemple, je vais chercher à traiter les quelques 7819 emplacements de stationnement vélo recensés par l’Eurométropole de Strasbourg. Une version conforme à la Base Nationale de Stationnement Cyclable permettrait une transformation quasiment à 1 pour 1 des attributs mais j’ai préféré en faire une tâche d’intégration sur Osmose et réaliser cette harmonisation manuellement. Cette version disposant également de plus de détails concernant le type de stationnement – La conflation sert à gagner en qualité.

Le fichier dispose de 14 champs :

• ID Emplacement, qui correspondra à la clé ref selon le modèle BNSC ;
• Type d’arceau qui correspond directement à bicycle_parking ;
• Nombre d’arceaux qui me permettra de déduire capacity. Attention cependant, il est indiqué sur le jeu de données que c’est au « sens patrimonial » : cintrés et carrés comptent pour deux places tandis que ranges-vélos et attaches vélo-cargos comptent pour un. Ça devient complexe et je suis plutôt content d’utiliser un tableur plutôt que d’essayer en faire sens sous JOSM ;
• Abri vélo semble correspondre à l’idée d’un bâtiment building plutôt que simplement la couverture face aux intempéries covered, ce dernier sera logiquement inscrit puisque découle du premier ;
• Gestionnaire indique si l’emplacement dépend de l’Eurométropole ou non, operator ;
• Date d’installation correspond à start_date ;
• Date de dernier remplacement, a un sens abstrait, aussi je conserverai la date initiale d’installation ;
• Date de levée a également un sens obscur. Il apparaît que cela soit un nouveau format apporté par la suite. Seul 8 cas de chevauchement de l’installation et la levée apparaîssent. Dans le doute on va le mettre dans start_date ;
• ID sous tronçon indique l’identifiant du tronçon de route le plus proche. Inutile pour nous ;
• Source de l’information est explicite, cela reste inutile pour nous et on se contentera de citer le jeu de données en commentaire du groupe de modifications comme il est d’usage ;
• Date de MAJ semble correspondre au suivi de la maintenance, inutile pour nous tant cela reste abstrait ;
• Date de création semble être celui de la donnée et non de l’installation en elle-même ;
• Geo Point, donne les coordonnées géographiques de l’élément. C’est probablement ce qui est interprété par JOSM pour le positionner ;
• Geo Shape. permet de décrire la géométrie de l’élément. Il permet notamment d’indiquer la forme d’une rangée d’arceaux. Bien qu’intéressante, cet usage ne semble pas commun sur OpenStreetMap et on lui préfère un centroïde au milieu de l’installation ou un polygone s’il s’agit d’un bâtiment couvert.

Ainsi, le seul pré-traitement réel à effectuer est d’effectuer la correspondance des types d’arceaux ainsi que d’en calculer la capacité. Il semble dans les fait que cintré et carré soient utilisés pour distinguer deux modèles d’installation qui rentrent sous la catégorie des stands, il y a ici une perte de données qui pourrait être compensée à l’aide de la clé model si la référence venait à être trouvée. Dans le jeu, 478 emplacements sont indiqués comme abri-vélos, des opérations sont à prévoir dans l’étape suivante.

Mise en place du jeu de données « Sujet »

Dernière étape avant de réellement voir le jeu de données à importer, il faut trouver les données sur OpenStreetMap. En théorie il serait possible de simplement télécharger toute la zone couverte par les données « Référence » mais à moins d’avoir un ordinateur boosté aux hormones on va préférer faire une requête sur les éléments qui nous intéressent uniquement. C’est l’heure de dégainer Overpass. Rien de folichon ici,

Loin de moi la prétention de maîtriser l’art des requêtes, je vais plutôt tabler sur l’assistant pour qu’il me donne tous les amenity=bicycle_parking de Strasbourg… Ou plutôt de l’EuroMétropole de Strasbourg… 3421 éléments trouvés contre un jeu de données de 8000, la journée s’annonce longue.

 Traitement JOSM

Une fois la scène mise en place, ne reste qu’à fusionner. Ouvrez la fenêtre de Conflation et cliquez sur « Configurer ». Sélectionnez et figez – Aucune idée du sens – les données de la couche « Référence », puis la couche « Sujet » et générez les appariements. Veillez à bien, rendre le calque actif, sélectionner toutes les données (Ctrl+A) et de figer. Différentes méthodes d’appariement sont proposées, sans idée je pars avec les paramètres par défaut.

L’onglet de Conflation se remplit de lignes d’appariements. Une colonne colorée de façon criarde indique si la fusion peut se faire automatiquement où si des données sont en conflit. Pour chaque ligne, il suffira alors de valider ou non l’appariement – Toujours dans le sens « Sujet » vers « Référence » pour ce qui est de la géométrie – et de gérer les conflits au cas par cas. Les imprécisions des deux jeux seront mises en évidences.

Des éléments n’ont pas d’apparié et n’existent que sur OpenStreetMap ou dans les données communales. Ici encore, pas de traitement automatique, il faudra se dégourdir et analyser au cas par cas si l’intégration est justifiée ou non, et si nécessaire prévoir des sorties sur le terrain pour l’appuyer. Par défaut, je considère les données OpenStreetMap comme ayant plus de valeur, partant de cela, j’ai précisé lors de l’appariement dans le champ prévu à cet effet d’exclure la valeur capacity du jeu de référence. Les conflits ne demanderont pas de résolution mais seront tout de même mis en évidence en couleur jaune.

Sans surprise, une part importate des appariements est correcte : l’élément indiqué dans les données correspondent à ce qui est sur OpenStreetMap. Je peux sélectionner une suite d’éléments sans conflits et de score élevé dans ma liste pour les combiner. Des erreurs surviennent parfois, en particulier lorsque le nœud sur OpenStreetMap fait partie d’un polygône. À priori cela n’a pas lieu d’être et ce sont souvent une limite venant de l’appariement, mais également des données OpenStreetMap où un élément a été relié par erreur à un bicycle_parking. L’appariement peut ainsi être supprimé de la liste. Cela aurait pu être évité en filtrant de nouveau les données OpenStreetMap sous JOSM via un filtre ne conservant que les bicycle_parking.

Parmi les conflits pouvant survenir, on retrouvera où des erreurs de capacity ou de bicycle_parking. Le premier cas est plutôt courant selon la manière de diviser les stationnements. Là où il sera facile de ne voir qu’un lot de 60 places, celui-ci peut officiellement être divisé en plusieurs lots. Dans le second c’est plus complexe et il faudra déterminer au cas par cas. Ce que je considère comme étant une erreur de cartographie, bien qu’approuvé, est l’attribut bicycle_parking=building. Il ne permet pas de déterminer le type de mobilier à disposition pour attacher son vélo, et pourrait être remplacé par covered=yes, indoor=yes (répandu pour les défibrillateurs), ou encore building=yes.

Faute de raccourcis à l’extension, ma méthode est globalement de naviguer entre les éléments avec les flèches directionnelles (la touche Entrée permet de zoomer sur la sélection) et d’alterner entre appariements à supprimer et appariement valides. Cela permet de rendre le processus plus agréable – dans une certaine mesure – que la machine à clics que cela serait autrement.

Objective

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.

Criterias

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

JOSM

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.

Mapillary/KartaView

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.

Conclusion

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.

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)

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

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.

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

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.

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.

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.

“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

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

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.