lucidiot's cybrecluster

D'autres expériences avec OSM

Lucidiot — Informatique — 2021-08-08
Un tour d'horizon de quelques autres sujets auxquels je me suis intéressé en contribuant à OpenStreetMap.

---

Cartographier les réseaux Wi-Fi n'est pas ma première contribution à OpenStreetMap, mais c'est le projet où j'en ai vraiment appris plus sur le fonctionnement d'OSM. J'avais fait une dizaine de petites contributions depuis 2013, notamment pour corriger des fautes d'orthographe ou rajouter des tags manquants assez simples, et j'ai vraiment commencé à agir sur la carte il y a trois mois.

Le groupe local OpenStreetMap de Grenoble est assez actif, comme de façon générale les initiatives citoyennes et les projets FOSS à Grenoble. Du coup, la carte est plutôt bien détaillée, et c'est moins sur les bâtiments, rues, parcs, etc. qu'on pourra agir mais plutôt sur des détails comme les arbres, les boîtes à lettres, les poubelles, etc. qu'on peut agir. Ce sont ces détails qui font d'OpenStreetMap un outil vraiment utile pour moi, notamment pour le géocaching urbain ; pouvoir appuyer sur le bouton de navigation sur c:geo et voir immédiatement que la cache se trouve sur un banc à côté d'un arbre particulier est très utile.

Je compte aussi dans cette catégorie la cartographie intérieure (indiquer les couloirs d'un bâtiment public, l'emplacement d'un guichet, etc.) et les aménités ; que ce soient des restaurants, des commerces, des distributeurs de billets, des relais colis, etc., ce sont des choses qui sont utiles dans la vie de tous les jours et qui font la différence entre Google Maps et OpenStreetMap : les infos sur Google Maps sont souvent incomplètes, dépendent du bon vouloir des commerçants, et la seule autre source de ce genre d'informations, ce sont des pages Facebook. J'aime beaucoup pouvoir rechercher une supérette actuellement ouverte, ou ouverte durant le confinement, etc. Et puis comme vous avez pu le voir précédemment, ce n'est pas sur Google Maps qu'on pourra indiquer le nom du réseau Wi-Fi d'un restaurant.

Voici quelques uns de ces détails sur lesquels je me suis penché dans mes contributions pour diverses raisons…

Bancs et tables

Il y a rarement vraiment besoin d'une carte pour trouver un banc ; il faut chercher des rues piétonnes, des places, des parcs, et on finira forcément par y trouver des bancs. Mais j'ai commencé à m'intéresser à leur cartographie en pensant plutôt aux tables de pique-nique : je sais qu'il y a au moins une table de pique-nique dans Grenoble, et pour diverses raisons, entre autres faire du télétravail étrange avec des amis, je voulais voir où se trouvent toutes les tables dans Grenoble.

Il y a deux façons d'indiquer des tables de pique-nique dans OpenStreetMap : le tag leisure=picnic_table, pour indiquer une table de pique-nique sur un point séparé, ou la clé picnic_table=yes qui est à utiliser sur un autre point, comme par exemple un parc, pour indiquer qu'une table de pique-nique est incluse. Il existe aussi picnic_table=no pour indiquer qu'une table de pique-nique n'est pas présente à un lieu où on pourrait s'y attendre, comme un site désigné officiellement comme une zone de pique-nique par exemple.

On peut utiliser l'API Overpass pour faire des recherches sur la carte, et Overpass-turbo permet de faire ça assez facilement. Vous pouvez cliquer ici, déplacer la carte sur la zone qui vous intéresse, puis cliquer sur Exécuter pour lancer la recherche. Des cercles apparaîtront tout de suite autour de toutes les tables de pique-nique dans la zone.

Pour ce qui est des tables qui ne sont pas des tables conçues pour le pique-nique, on utilise amenity=table. Pour les bancs, on utilise amenity=bench, ou la bench=yes/no pour indiquer que quelque chose a un banc ou non (notamment les tables). On peut indiquer sur les bancs et les tables moult autres détails : la présence ou non d'un dossier, le nombre de places, la couleur, le matériau, les dimensions, la disponibilité si l'accès n'est pas possible en permanence, la direction dans laquelle est le banc ou la table, etc. Il est également possible d'indiquer une table pour jouer aux échecs avec sport=chess.

Boîtes à livres

Depuis quelques années, les boîtes à livres pullulent dans les villes. Des boîtes à livres maintenues par la mairie grenobloise ont été installées en 2016, et il y en a d'autres gérées par des associations, des entreprises, etc. Elles sont déjà plutôt bien cartographiées, mais comme elles font partie de ces petits détails que j'aime bien voir, je prends parfois le temps de m'arrêter 30 secondes et de vérifier qu'elles sont bien là.

On peut cartographier une boîte à livres avec amenity=public_bookcase, et un grand nombre d'autres tags peuvent être ajoutés, pour la capacité estimée de livres, l'éclairage, l'accessibilité, le type de livres s'il y a des restrictions (par exemple une boîte à livres ne contenant que des livres pour enfants), ou le type de boîte à livres (bâtiment dédié, vitrine, boîte en métal, cabine téléphonique rénovée, une étagère à l'intérieur d'un bâtiment, etc.).

Fontaines à eau

Aux États-Unis, le paradis des mauvaises idées en termes d'urbanisme, on entend parler du concept d'architecture hostile ; le mobilier urbain ou les bâtiments sont conçus de telle sorte à nuire aux populations. Le principal exemple est l'installation de pics ou de poteaux à des endroits où on sait que des personnes sans domicile fixe iraient s'installer pour dormir, ou la suppression de bancs. Le remplacement de bancs par des barres où on peut s'appuyer sans s'assoir, ou l'installation d'accoudoirs au milieu des bancs pour empêcher de s'allonger, sont des exemples encore plus vicieux. On commence à voir ce genre de choses s'installer en Europe, parce qu'il est toujours plus simple de juste se voiler la face et cacher le problème des gens à la rue en les forçant à aller ailleurs plutôt que de trouver des solutions.

Les fontaines à eau publiques sont un peu l'opposé de l'architecture hostile ; alors qu'un banc est suffisamment courant pour que n'importe qui puisse penser à en installer, tout le monde ne pense pas toujours aux fontaines à eau, notamment aux États-Unis où tout est vraiment centré autour de la voiture, et où le pays entier est trop récent pour avoir une époque où les fontaines à eau étaient nécessaires à la majorité de la population. En Europe, les fontaines à eau sont plus fréquentes ; celles de Grenoble et Lyon ont même un article Wikipédia dédié. Je ne me souviens cependant pas avoir vécu dans une ville disposant de fontaines à eau avant d'arriver à Grenoble. Je sors quasiment toujours avec une bouteille d'eau, mais quand j'oublie ou quand elle est vide, je suis bien content d'en avoir dans le coin.

Un de ces jours, j'essaierai de vraiment créer ce bouton « J'ai soif » que je voulais faire pour mon téléphone, qui ouvrirait immédiatement OsmAnd avec un itinéraire vers la fontaine à eau la plus proche. C'est une idée que j'ai en tête depuis un moment, et je me suis rendu compte que les fontaines à eau n'étaient pas très bien cartographiées, alors j'ai commencé par améliorer un peu ça.

Les fontaines à eau sont assez compliquées à cartographier, parce qu'une arrivée d'eau potable est utilisée dans beaucoup de contextes, et cela conduit à pas mal d'erreurs. Voici une liste des moult clés et attributs qu'on peut rencontrer :

amenity=drinking_water

Le tag le plus simple. Si on l'ajoute sur une carte, il est automatiquement considéré qu'on parle d'une fontaine d'eau potable.

amenity=water_point

Un tag qui porte souvent à confusion : c'est un point d'eau souvent potable conçu non pas pour juste boire ou remplir sa gourde, mais pour les caravanes et camping-cars. Il m'est arrivé de voir des fontaines à eau taguées comme ces points d'eau pour caravanes en plein centre-ville.

man_made=water_tap

Un tag supplémentaire qu'on peut utiliser pour indiquer en particulier un robinet d'eau. Ce n'est pas un tag officiellement recommandé, mais il est régulièrement présent. Le robinet n'est pas forcément contrôlable ; s'il y a un tube pointé vers le bas par lequel l'eau sort, ça compte.

man_made=drinking_fountain

Un tag non officiel pour un type particulier de fontaines à eau que je n'ai pas encore croisé en France, où un jet d'eau peu puissant est orienté vers le haut. L'eau forme alors une petite parabole et retombe dans une coupelle en dessous, et il est très facile d'y mettre la bouche pour boire, mais ce n'est pas adapté au remplissage des bouteilles d'eau.

drinking_water=yes/no/conditional

Un tag qu'on peut ajouter à autre chose, par exemple une fontaine classique, pour indiquer que l'eau est potable ou non. S'il y a seulement un panneau « Eau non potable » mais que l'eau semble tout à fait potable, alors on met conditional pour indiquer de boire à ses propres risques et périls.

drinking_water:legal=yes/no

Un tag qu'on peut ajouter à amenity=drinking_water ou drinking_water=yes pour indiquer s'il est officiellement autorisé ou interdit de boire cette eau ; un panneau « Eau non potable » suffit pour dire no.

cold_water=yes et hot_water=yes

Pour indiquer si l'eau est chaude ou froide. Il existe aussi le tag warm_water=yes, mais il n'est pas officiellement autorisé.

bottle=yes/no

À n'utiliser que sur amenity=drinking_water pour indiquer qu'il est possible relativement facilement d'utiliser la fontaine d'eau potable pour remplir une bouteille d'eau.

fee=yes/no

Pour indiquer si la fontaine est payante ou non.

Un bon nombre des fontaines actuellement cartographiées à Grenoble n'inclut quasiment aucun de ces tags, donc je prends le temps de m'arrêter aussi devant les fontaines déjà indiquées pour ajouter les bons tags. Toutes ces confusions font qu'il est plus compliqué de juste sélectionner "Eau potable" sur OsmAnd pour trouver la fontaine la plus proche, ou font que les fontaines restent masquées sur la carte.

J'ai récemment reçu beaucoup de compliments dans le fediverse, et ai été nommé « Paladin de l'Église de l'Eau Divine » et un « modèle de justice » juste pour ces quelques contributions, tant certains américains regrettent le manque de fontaines à eau ou de toilettes publiques dans leurs villes.

Le magazine de la ville a récemment inclus une carte dans un numéro comprenant tous les endroits où on peut trouver de la fraîcheur en plein été, et il inclut beaucoup de fontaines qui ne sont pas encore cartographiées, donc j'ai du pain sur la planche !

Éléments abandonnés

Je fais occasionnellement de l'urbex, et je sais qu'OpenStreetMap inclut des tags pour les bâtiments abandonnés ; ça peut être utile de savoir qu'un bâtiment est « tellement abandonné » et tellement connu que quelqu'un a pris la peine de l'indiquer sur la carte, donc qu'il ne sera pas aussi bien préservé que les lieux que préfèrent les adeptes de l'urbex. On peut rechercher abandoned=yes, ou préfixer n'importe quel tag par abandoned:. Par exemple, pour une fontaine à eau à l'abandon, on utiliserait abandoned:amenity=drinking_water. Il existe d'autres préfixes de ce genre, appelés préfixes de cycle de vie : proposed:, planned:, construction:, emergency:, disused:, etc.

J'ai récemment ajouté une cabine téléphonique hors service, qu'on m'avait pourtant annoncé comme étant la seule cabine téléphonique encore en service de Grenoble, avec disused:amenity=telephone, et j'ai vu une boîte à lettres détruite par un incendie et taguée destroyed:amenity=post_box. Ces éléments sont généralement cachés sur la plupart des cartes et exclus des recherches, puisque la plupart des gens ne seront pas intéressés de savoir qu'ils auraient pu avoir une boîte à lettres ici si des gens ne s'étaient pas amusés à la crâmer, mais plutôt par trouver une boîte à lettres encore en état…

Feux piéton accessibles aux personnes malvoyantes

Juste après avoir ajouté une boîte à livres manquante dans OpenStreetMap, vu qu'elle était juste à côté d'une intersection que je connais assez bien avec des feux de signalisation assez particuliers, j'ai voulu voir comment ils étaient cartographiés. La clé traffic_signals et les autres clés commençant par traffic_signals: permettent d'être plutôt spécifique, ce qui est compréhensible vu que les feux sont des éléments déterminants dans beaucoup de calculateurs d'itinéraires. On peut indiquer si le feu est un feu tout à fait classique d'intersection, si c'est un feu qui clignote orange au lieu d'être vert, s'il est vert en permanence, si le feu est éteint la plupart du temps mais peut parfois clignoter lors d'urgences ou d'événements particuliers, s'il donne la priorité aux transports publics, etc.

On peut aussi indiquer les feux de passage piéton destinés aux piétons, qui indiquent si on peut traverser ou non, avec crossing=traffic_signals. Là aussi, on peut utiliser beaucoup de tags spécifiques, et notamment indiquer si le passage piéton peut être contrôlé avec un bouton (button_operated=yes), si feu émet du son (traffic_signals:sound) ou cause des vibrations dans le sol (traffic_signals:vibration) pour indiquer qu'on peut ou non traverser, pour les personnes malvoyantes.

L'accessibilité des feux de passage piéton est un domaine assez particulier et il n'y a rien de très consistant entre chaque pays. Par exemple, à certaines intersections à Bruxelles, je me souviens avoir entendu des feux faire du bruit quand on pouvait traverser, et ce n'importe quand dans la journée. Il est possible sur OSM d'indiquer qu'un feu émet du son ou non, mais aussi d'indiquer qu'il n'y a qu'un son qui permet de localiser le feu, ou qu'un son qui permet de savoir quand on peut traverser, et pas les deux : traffic_signals:sound=yes/no/locate/walk). Il n'est cependant possible de cartographier correctement les feux accessibles en France, parce qu'on a des spécifications plus complexes.

En France, l'implantation des feux piétons est régie par l'article 110-2 du livre I de la sixième partie de l'instruction interministérielle sur la signalisation routière :

Les signaux pour piétons R12 associés doivent être complétés par des dispositifs tactiles ou sonores. Ces dispositifs sont conformes à la norme NF S32 002. Des messages sont émis par ces dispositifs spécifiques, qui fonctionnent de façon permanente, semi-permanente, par activation manuelle ou par activation par télécommande.

J'ai mis en gras la dernière partie de cette citation car elle est la plus importante pour OpenStreetMap. La clé traffic_signals:sound n'indique pas si le son est présent de façon permanente, intermittente, ou s'il peut être activé d'une façon ou d'une autre. Indiquer simplement qu'il y a du son sur le feu implique en fait que le feu émet du son en permanence, ce qui n'est quasiment jamais le cas. Je n'ai jamais vu de feux dont les dispositifs sonores sont activés automatiquement en France, bien que ce soit visiblement autorisé par la loi. Cela passe soit par un bouton installé sur le feu (notamment à Paris), soit par l'utilisation d'une télécommande émettant des messages particuliers sur 868.3 MHz. Cette télécommande peut aussi activer d'autres équipements, notamment dans les gares SNCF où toutes les portes peuvent se mettre à parler, ou aux arrêts de bus où les afficheurs d'horaires peuvent indiquer le passage des prochains bus.

OpenStreetMap a déjà une clé pour indiquer que quelque chose est opéré par un bouton : button_operated=yes. On peut l'utiliser sur des feux de circulation ou des feux piétons pour indiquer que le droit de passage nous sera accordé seulement quand on appuie sur le bouton. Il est cependant noté sur le wiki qu'il est généralement difficile de vérifier la réalité du fonctionnement de ce bouton ; le signal peut être complètement ignoré par le contrôleur de feux, le bouton peut être débranché, ou le feu ne passe pas immédiatement au vert parce que le boîtier de contrôle des feux veut garder un minimum de synchronisation, ou ça pourrait ne fonctionner que la nuit par exemple, etc.

Je voudrais pouvoir ajouter un tag traffic_signals:sound:button_operated=yes pour indiquer que le son d'un feu est activable avec un bouton, et traffic_signals:sound:remote_operated=yes pour indiquer que c'est avec une télécommande. La vérifiabilité sera encore plus difficile pour remote_operated puisqu'il faut disposer d'une télécommande. J'en ai eu une alors que je ne suis pas malvoyant en demandant gentiment à l'exploitant d'un réseau de transports en commun qui n'a rien à voir avec Grenoble, et en usant du coup de mensonges pour justifier d'envoyer une télécommande à l'autre bout de la France. Il est possible pour des personnes malvoyantes de se procurer des télécommandes gratuitement à leur mairie sur présentation d'une carte d'invalidité, et sinon on peut acheter des télécommandes en ligne ; la moins chère que je connaisse, un modèle proche de la mienne, est à 56 €.

J'essaierai de voir prochainement comment on peut proposer à la communauté de nouveaux tags, ou au moins où aller pour pouvoir en discuter. J'ai déjà mis un message sur la page de discussion de traffic_signals:sound, mais je ne m'attends pas à ce que quelqu'un prête attention à ce message avant un moment, donc je vais voir s'il y a des moyens de communication plus actifs. J'aimerais bien pouvoir documenter le niveau d'accessibilité des feux en ville ; tous les feux installés ou rénovés après 1999 doivent avoir des équipements sonores ou à vibrations, mais je vois encore énormément de feux qui ne fonctionnent toujours pas avec ma télécommande.

En attendant, je peux suivre un des principes philosophiques du projet et juste cartographier ce que je veux sans me poser de questions…

Chargeurs USB

Il existe un tag amenity=device_charging_station, et une proposition avait été débutée mais a été abandonnée pour inactivité il y a quelques années, pour indiquer des bornes de recharge notamment pour les téléphones. Cela se distingue des bornes de recharge existantes pour les véhicules électriques (amenity=charging_station) par le fait qu'on recharge difficilement une voiture en USB. On peut y indiquer le type de prise (USB-A, USB-C, etc.), la tension et l'intensité électriques, le nombre de prises, le nombre de prises utilisables simultanément (qui peut être inférieur), etc.

J'ai remarqué récemment que des abribus et des stations de tramway à Grenoble ont des panneaux publicitaires avec des prises USB disponibles, et je pensais donc à utiliser ce tag pour les indiquer. Cela dit, le tag était conçu pour ajouter un nouveau point sur la carte et indiquer que c'est un chargeur ; je ne sais pas si je dois du coup ajouter un point pour le panneau publicitaire qui est intégré à l'abribus et ajouter dessus que c'est aussi un chargeur USB, si je dois ajouter le chargeur USB entièrement séparément, ou indiquer que l'abribus lui-même a un chargeur USB. Mais le tag amenity ne devrait être utilisé qu'une seule fois, car on ne peut pas dire « c'est à la fois un abribus et un chargeur USB », on peut dire soit « c'est un abribus qui fait aussi office de chargeur USB », soit « c'est un chargeur USB qui fait aussi office d'abribus ».

En suivant la logique de amenity=drinking_water et drinking_water=yes, je devrais du coup ajouter device_charging_station=yes suivi de tous les tags pertinents. Encore quelque chose à discuter avec la communauté…

---

Voilà un peu l'étendue de mes contributions actuelles sur OpenStreetMap. Ce sont beaucoup de petits détails, et j'ai l'impression que l'esprit de beaucoup de contributeurs se focalise beaucoup plus sur le fait de cartographier à plus grande échelle, mais ces petits détails sont utiles au quotidien et font d'OpenStreetMap et des applications clientes une alternative viable et intéressante à Google Maps. Peut-être que si l'opportunité se présente, j'irai cartographier de nouvelles rues ou des nouveaux bâtiments, mais ça ne sera probablement pas pour tout de suite à Grenoble même.

---

Commentaires

---

Soumettre