Faut-il nommer les mairies dans OpenStreetMap ?

Comment faut-il nommer la mairie du village de Cuvat dans OpenStreetMap (OSM) ?

  1. Mairie
  2. Mairie de Cuvat
  3. Aucun nom ne doit être utilisé

Penchons-nous sur ce point d’arbitrage en apparence minime qui soulève en définitive de vastes problématiques.

Cet article reprend et développe les récentes discussions (voir cette discussion sur le forum et celle-ci) sur le sujet.

Bonnes Pratiques

Les règles de bonnes pratiques de la communauté constituent le premier phare évident dans notre décision.

Voyons voir comment elles s’appliquent au tag name utilisé pour nommer les lieux et les choses.

« Mappez ce qui se trouve sur le terrain »

On pourrait tout d’abord être tenté d’utiliser comme nom « Mairie », tout simplement. Après tout, c’est bien la mention qui est écrite sur le fronton du bâtiment.

Façade de la mairie du village de Cuvat, Haute-Savoie

Cette option est néanmoins une fausse piste. En effet, lorsque l’on cartographie une mairie, il est d’usage de faire référence au service et à l’administration qui l’accompagne, voir au bâtiment, mais jamais à la seule mention inscrite sur sa façade.

En conséquence, référencer cette mention spécifiquement peut éventuellement présenter un intérêt mais il dépasse le cadre de notre réflexion actuelle.

La manière la plus adaptée de cartographier cette inscription reste de créer un point indiquant l’entrée et de l’affluber du tag inscription=Mairie. C’est donc ce que j’ai fait, sans plus de cérémonial.
Cette solution est couramment utilisée pour indiquer les inscriptions sur les monuments aux morts.

« N’utilisez pas de tag name pour décrire des choses »

Une autre règle de bonne pratique, sans aucun doute la plus pertinente dans notre cas, est de ne pas nommer les choses lorsqu’elles peuvent être décrites par des tags dédiés.

L’objectif du projet OSM reste en effet de créer une base de données structurée, c’est-à-dire avec des tags dédiés décrivant précisément chaque objet.

Ainsi, en décomposant le name=Mairie de Cuvat :

  1. Le terme « Mairie » n’est qu’une redite du tag amenity=townhall
  2. « de Cuvat » n’indique que le territoire sur lequel se trouve l’établissement. Or, celui-ci est déjà positionné à l’intérieur du périmètre de la commune de Cuvat. Il est, comme toutes les communes de France, déjà bien délimité dans OSM ; son nom est donc déductible de l’objet « commune » dans lequel se trouve le bâtiment de la mairie.
Une recherche dans l’appli Organic Maps indique 1. le nom 2. le type 3. la commune.

Le name est en doublon avec des données déjà présentes. Il est donc possible de s’en passer totalement. Mais, est-ce vraiment réaliste ?

« Ne cartographiez pas pour le rendu »

Une autre règle de bonne pratique est de « ne pas cartographier pour le rendu », par exemple pour l’apparence de la carte sur openstreetmap.org

Or, c’est un secret de polichinelle que la majorité des contributeurs jugent de la qualité de leur propre contribution (et de celles des autres) en jetant justement un coup d’œil sur ce site web. Et c’est bien normal : il n’y a rien de plus simple pour voir le résultat !

Pourtant, la carte qui s’affiche par défaut sur openstreetmap.org – appelée dans le jargon un rendu cartographique – n’est qu’une manière d’afficher la base de données. De nombreuses variantes de rendus existent, et aucune n’a plus de légitimité qu’une autre pour définir la bonne manière d’afficher (et donc, a priori, de créer) les données.

Différents rendus (source : openstreetmap.fr)

La faute des rendus ?

Pire : la majorité de ces rendus poussent activement à nommer les objets en affichant ces noms.

En effet, au fil des années s’est ainsi installée une véritable course au nommage des objets, en contradiction avec l’objectif originel.

Les rendus qui affichent les noms de mairie incitent à … nommer les mairies, évidemment

Les objets autour de la mairie de Cuvat sont tous nommés

Quels objets nommer ?

Mais alors, quels objets faut-il nommer dans la petite bourgade de Cuvat ?

  • arrêt de bus : oui
  • église : oui, mais uniquement parce qu’elle est dédiée à un saint patron spécifique
  • aire de jeux : non
  • parking, école, mairie, salle polyvalente : ça se discute

On le voit, les règles de nommage sont complexes, a priori pour un débutant.

La faute des éditeurs ?

Pire : les éditeurs de données poussent eux-aussi au crime.

La première suggestion de l’éditeur iD, utilisable sur openstreetmap.org, est de nommer les aires de jeux (tout comme les écoles ou les mairies).
Le texte d’aide demande d’ailleurs « le nom le plus visible ou le plus courant »

Il est très aisé pour un contributeur non-avisé de renseigner un nom par erreur : c’est souvent la première information disponible dans les éditeurs.

La faute des hackers ?

Si nommer une mairie « Mairie », une école « École » ou encore une aire de jeux « Aire de jeux » est contraire aux bonnes pratiques, leur prolifération relève du bon sens paysan, entendu dans son sens mélioratif : c’est une solution évidente et efficace.

N’est-ce pas en effet le moyen le plus universel, le plus simple de cartographier ? Il existe une relation directe entre la donnée créé et l’usage qui en est fait. Cette pratique est solidement encrée : après tout, quoi de plus naturel que de nommer un lieu sur une carte ?

N’oublions pas non plus que le projet OSM s’est construit au fur-et-à-mesure, sans grand plan d’ensemble. La mentalité prédominante est celle du hacker, éternel débrouillard qui trouve des solutions élégantes avec les ressources limitées dont il dispose.

Banalisation des pratiques de nommage de facto

En conséquence, 126 894 mairies dans le Monde sont nommées, soit plus de 83% d’entre elles (source : taginfo consulté le 16/08/2023). En France, ce chiffre dépasse les 64% (source).

Répartition des mairies dans le Monde

On peut dire sans se tromper que nommer une mairie est devenu un comportement largement répandu.

Nommer une mairie est une pratique largement majoritaire, presque systématique dans le Monde entier

Pour une éthique de l’usage

La communauté OSM s’est historiquement focalisée sur la création même de la base de données, qui constitue naturellement sa raison d’être (et occupe bien assez nos journées et nos nuits comme ça !).

Son exploitation a posteriori est au mieux un sujet secondaire. La plupart du temps, c’est tout simplement hors de propos. Il existe en effet un riche écosystème technique qui exploite les données sans nécessairement avoir de lien avec la communauté.

Or, la construction technique de la base de données n’est pas un système en vase clos. Bien au contraire, elle se construit dans le cadre d’un mouvement politique d’émancipation par la technologie, d’ouverture et de libération (des logiciels, des données…).

Il parait improbable dans ce cadre holistique de se passer d’une éthique conséquentialiste.
Autrement dit, la communauté OSM ne peut faire l’économie d’étudier les conséquences de ses décisions quant à l’exploitation des données qu’elle produit, a fortiori sur la structuration de ses données.

Concrètement, supprimer aujourd’hui le nom de la mairie dans OSM a pour conséquence directe de dégrader l’affichage de la carte sur de très nombreux sites, à commencer par plusieurs sites web officiels.

Le site internet de la communauté de communes dont Cuvat fait partie affiche des cartes OSM

Supprimer le nom de la mairie dégrade à court terme de très nombreuses cartes

Pour cette raison, supprimer les noms à court terme serait une décision difficilement tenable. Au delà du défi de convaincre les mainteneurs des éditeurs, des outils de contrôle qualité et des rendus, une partie (voir la majorité) des utilisateurs ne comprendraient pas cette décision. Il est même à parier que certains d’entre eux ne la respecteraient pas.

Reconstruire les noms

Il est tout à fait envisageable de créer toute une chaine logicielle intermédiaire afin de recréer les noms de mairies a posteriori.
Cela nécessite plusieurs étapes distinctes :

En prenant en compte toute cette complexité, partir du principe que les données seront forcément retraitées pour une utilisation aussi évidente que la création d’un rendu cartographique est une gageure. Cela revient à exclure de facto les réutilisateurs sans compétences avancées.

Imposer un retraitement des données a posteriori défavorise les utilisateurs sans compétences techniques

En aucun cas le seul respect des règles de bonnes pratiques ne devrait justifier de transformer OSM en un projet aussi élitiste.

État final visé

Il n’existe pas de vision universelle pour le futur d’OSM. L’inexistence d’entité de décision centrale est constitutive à son approche « bazar » et non pas « cathédrale ». Cette organisation est solide : elle a prouvé au fil du temps son efficacité. Néanmoins, elle entraine parfois un manque de vision et un immobilisme préjudiciables.

Vers une meilleure exploitabilité des données

Une voie qui me semble souhaitable prendrait soin de :

  1. Améliorer la structure des données sur le long terme
  2. Ne jamais défavoriser les ré-utilisateurs de données peu expérimentés

Cette voie implique de créer la chaine logicielle intermédiaire que j’ai détaillée ainsi que l’adaptation des éditeurs et de nombreux outils techniques, sans parler, bien entendu d’une préalable discussion internationale complexe.

On pourrait pour cela étendre le principe de « tags implicites », qui existe déjà, à des tags déduits, construits. Dans l’idéal, il faudrait les intégrer pleinement à nos outils, notamment durant l’édition, le contrôle qualité et le rendu.

Et pour les mairies alors ?

Il est maintenant temps de répondre à la question « Faut-il nommer la mairie de Cuvat ? »

Mon avis personnel est le suivant :

  1. À court terme, homogénéisons les noms en France en suivant la structure du type « Mairie de Cuvat »
  2. Mettons-nous d’accord sur l’objectif, à terme, de supprimer ces noms
  3. Mettons en place toute l’infrastructure qui nous permettrait d’y parvenir avec une rupture minime de service, en portant une attention particulière aux réutilisateurs inexpérimentés

Et maintenant, on fait quoi ?

Nous avons toute légitimité pour prendre des décisions à l’échelle de la France puis se répartir le travail de mise en qualité lors d’un projet du mois.

La pire des solutions serait de maintenir le status quo, c’est à dire de ne pas réussir à se mettre d’accord. Je suis un ardent partisan de trancher les consensus mous, de mettre fin aux compromis historiques qui freinent le projet. Je préfère largement qu’une décision contraire à mes idées s’impose plutôt qu’aucune décision ne soit prise.

N’oublions pas que la vie et la mort des tags est un processus dynamique, une décision de cette année pourra être remise en cause en fonction de l’évolution du contexte plus tard.

Au vote !

Et vous, quel est votre avis sur le sujet ?

Votons et continuons à débattre sur le forum.

2 Comments

Ajoutez les vôtres
  1. 1
    a

    Pour une autre perspective, en Suisse, selon les cantons et les endroits, une Mairie ne s’appelle pas Mairie, mais Administration communale, Administration municipale, …etc. Donc plutôt difficile à reconstituer. Peut-être que dans ce cas loc_name est plus approprié ?

    • 2
      overflorian

      Dans l’idéal de la vision que j’ai proposé, chaque situation assez répandue dans un pays devrait être gérée par un tag dédié ; s’il existe des exceptions, elles pourraient être gérées par le « name ».

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *