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 :

https://wiki.openstreetmap.org/wiki/Tag:qplot(x=area,data=ten,
geom="histogram"https://wiki.openstreetmap.org/wiki/Tag:,binwidth=25)
https://wiki.openstreetmap.org/wiki/Tag:+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(
https://wiki.openstreetmap.org/wiki/Tag:breaks=seq(0,2500,250),
https://wiki.openstreetmap.org/wiki/Tag: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

… See full entry

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.

… See full entry

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

… See full entry

Tag’s use

While the https://wiki.openstreetmap.org/wiki/Tag:amenity=parking tag is used “de facto”, the https://wiki.openstreetmap.org/wiki/Tag: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 https://wiki.openstreetmap.org/wiki/Key:parking:lane and https://wiki.openstreetmap.org/wiki/Tag: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 https://wiki.openstreetmap.org/wiki/Tag:footway=acces_aisle tag (not to be confounded with https://wiki.openstreetmap.org/wiki/Tag: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”

… See full entry

“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

… See full entry

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.

… See full entry