Honnêtement, quand on aura plus que ca comme problème… Perso partisan de les laisser aussi longtemps qu’il le faudra.
Ajouter des noms afin de mieux les retirer ensuite ?
Difficile de suivre le raisonnement en effet !
Que sur certains POI on ajoute artificiellement un libellé dans le rendu du type « Mairie », ça me convient plutôt.
Je préfère largement ça à tordre des principes généraux pour tel ou tel cas qui donne du grain à moudre pour étendre l’exception et rendre tout de plus en plus confus.
@cquest Mon article ne t’aurait-il vraiment pas fait infléchir ta position ?
Tu es vraiment partisan de casser les rendus de tous les utilisateurs (du rendu mapnik standard notamment) à court terme ?
Je suis certain que l’on peut être plus malins que ça, quitte à ce que la solution soit plus complexe.
Comment ça ?
Ces name=* sont une forme de tagging pour le rendu… non ?
En tout cas pour moi « Mairie de Trifouilli » est le pire des choix du point de vue de la cohérence des données.
Extrapolons pour tester si c’est une vraie ou fausse bonne idée:
On étend avec « cimetière de Trifouilli », « gare de Trifouilli », « église de Trifouilli », « stade de Trifouilli », etc ?
Elle va être belle la carte, on saura bien qu’on est à Trifouilli… si on a la place sur le rendu pour tout ces « noms ».
Je pense que tu sera d’avis que ça ne va pas… alors ça ne va pas mieux pour la Mairie que le reste, d’où ma position de revenir à la base, c’est à dire au principe général du wiki et d’améliorer l’UX par des améliorations sur le rendu ou les géocodeurs plutôt que de bricoler dans les données parce que oui, pour les utilisateurs des services basés sur les données (je ne parle pas des réutilisateurs qui sont au milieu), il faut que ça ne les pénalise pas.
43 ans de fonction publique territoriale (retraite ), épouse secrétaire générale de mairie… Mon métier m’a amené dans des centaines de maire (ou de collectivités territoriales), 500 environ qui ont eu le malheur de me connaitre dans mon département ;). Tout le monde dit ou écrit « mairie de ». Pour les EPCI (communautés de communes, SIVOM…) il y a toujours un nom (dans mon secteur « Communauté de Communes du Volvestre » par exemple. Presque toujours pour l’établissement administratif principal on dit « Hôtel de laont exprimé ou du », les services annexes sont précisés par leur fonction suivi du nom de la collectivité « services techniques de ou du ». Mêmes pratiques pour les départements et les régions.
Les limites administratives, notamment en France, sous loin d’être des lignes droites, on a parfois une quasi imbrication. L’expansion urbaine fait d’ailleurs que certains secteurs de la commune de X sont parfois bien plus proches de la mairie de Y. Comme je le dis dans une autre réponse j’ai toute une carrière dans la Fonction Publique Territoriale (dont une dizaine d’années dans une grosse direction de la voirie) et j’ai vu pas mal de monde se tromper. Exemple concret : Le village dont mon épouse est SG a une bonne partie de son territoire sur la rive droite de la Garonne alors que le noyau historique et la mairie sont sur la rive gauche. Pour aller du territoire rive droite il faut traverser deux communes (avec un passage juste devant la mairie de l’une des deux) car un pont à traverser. On n’est rarement trop précis.
Suite à l’ajout d’un place=city + name=« Centre Ville de Liévin » ( voir Se baser sur l'administratif pour hiérarchiser les "place" (hamlet, village, suburb...)? - #8 par Kalepom) j’ai trouvé ceci sur Liévin:
- Way: Arena Stade couvert de Liévin (105095345) | OpenStreetMap
- Node: Micro-Lycée du lycée Henri Darras de Liévin (8791422107) | OpenStreetMap
- Way: Bureau de Poste de Liévin (105105416) | OpenStreetMap
- Way: Déchetterie de Liévin (1194671791) | OpenStreetMap
qui bien sûr sont tous à Liévin
Mais ausi…
- Node: Aire de Jeux du Jardin public (8630039607) | OpenStreetMap
- Way: Parking des employés (622107217) | OpenStreetMap
etc…
C’est ça le problème global, difficile à faire comprendre quand certains appliquent une autre règle hors consensus pour les mairies.
Bonjour,
@Rouzejp nous sommes bien conscients qu’il existe de très nombreuses exceptions. On peut imaginer à terme un système où seules celles-ci sont explicites dans OSM, les autres devenant implicites.
@cquest tes exemples sont limpides, merci.
C’est le bon sens paysan des contributeurs locaux qui abouti à utiliser le name
massivement, sur de très nombreux objets.
C’est en effet du tagging pour le rendu.
On peut considérer que ce n’est qu’un abus à corriger.
Mais on peut également considérer qu’OSM est une solution qui fonctionne pour le contributeur et le réutilisateur lambda :
- il mappe dans OSM, il constate que le rendu fonctionne bien
- il va convaincre sa mairie de changer son fournisseur de carte pour OSM
- OSM en ressort gagnant
Faire en sorte que ces petites mains continuent à apprécier OSM est ce que j’appelle « l’éthique d’usage » dans mon billet de blog.
Je propose de mettre en place les briques techniques qui permettent de retirer les name
sans jamais casser ce cercle vertueux.
C’est une vision stratégique et pas seulement technique.
On est bien d’accord, c’est le versant réutilisation qui doit être amélioré pour ne pas se retrouver avec cette tendance à ajouter des noms descriptifs pour que ça soit visible sur les rendus ou plus facilement trouvé par les géocodeurs.
Ceci n’empêche pas de limiter l’ajout de ces noms descriptifs, voir de supprimer ceux qui n’ont vraiment aucune raison d’être… je suis juste un peu plus maximaliste sur le sujet en incluant aussi les mairies plutôt que de faire une exception.
Ça me parait tout à fait approprié et justifié.
Je propose d’ailleurs un projet du mois pour supprimer les name
manifestement abusifs.
Oui, c’est bien ça. C’est une position que je comprends mais qui me semble trop rigide avec les réutilisations concrètes actuelles.
Consensus ?
Mon intuition est que l’on ne parviendra pas à un consensus tant qu’osm.org n’aura pas implémenté un rendu vectoriel par défaut.
C’est en effet le moyen le plus efficace pour se rendre compte que le name
fait doublon avec le type (et donc réconcilier tout le monde) :
(exemple avec Qwant Maps)
Actions envisageables
Pour avancer, on pourrait bosser sur les briques techniques que j’ai suggéré dans mon article :
On pourrait par exemple relancer l’idée d’OSM+ (j’ai créé un sujet dédié ici)
Après, on peut faire une infographie assez simple des name qu’il faut compléter et ceux qu’ils ne faut pas compléter en mettant plusieurs cas: mairie, école, terrain de sport, monument aux morts, arbre, banc,… Et on met ca sur le wiki.
Mais comme dit Florian, si on est pas aidé par les éditeurs comme ID, c’est comme pisser dans un violon.
Même chose sur Osmand que j’utilise pour les ajouts ponctuels tels que les bancs ou tables de piquenique. Il ne propose que 2 champs par défaut, et le premier (celui qui prend le focus) est le nom. Le second champ est le type d’objet, le reste se fait dans le mode « avancé ». Avec cette interface, une fois sur deux je commence à saisir involontairement dans le nom.
Je ne comprends pas ton exemple avec en dessous la copie d’écran de Qwant Maps ?
En quoi le vectoriel réglerait le problème ?
Je reprends l’exemple (mais c’est la même chose) avec Organic Maps :
Le fait que le tag amenity=townhall
et le polygone de la ville soient tous les 2 utilisés a pour conséquence que les informations du name
font doublon.
Pour un contributeur qui utilise ce rendu comme outil de contrôle qualité, il devient donc beaucoup moins tentant d’indiquer des name
abusifs à tout va.
Alors qu’au contraire, sur un rendu raster classique, le fait de n’avoir aucune interaction avec la carte pousse très fortement à mapper pour le rendu.
Je pense que cela est sur le chemin critique pour faire avancer « adopte une commune » et qu’on devrait donc commencer dès aujourd’hui. Quitte à faire des choix temporaires dans un premier temps.
Je vois bien ce que tu veux dire, mais une icône parlante au niveau de la mairie et des contours de communes plus visibles facilite le travail d’interprétation. Sur osm.org le rendu n’est pas sans interaction : si tu cliques, tu trouves ce qu’il y a ici, donc mairie et Cuvat.
Ce qui montre au demeurant qu’il ne faut pas pourrir la base pour de mauvaises raisons .
Il ne faut pas penser uniquement au rendu osm.org. Les données OSM sont extraites et exploitées par des géomaticiens qui les utilisent pour créer des cartes personnalisées. Si il faut qu’ils mettent en place une tambouille infâme pour afficher correctement des trucs de base comme les noms des mairies, ils vont rapidement faire le raccourci « bon hé bien les données OSM c’est merdique ». Et la plupart d’entre eux ne sont pas du tout des gros geeks donc il vaut mieux éviter de leur compliquer la vie !
Exactement, il faut penser aux consommateurs et ne pas les priver du choix de l’affichage du nom.
Par exemple s’ils veulent afficher le nom d’un arbre selon leur espèce, c’est à eux de faire le choix, pas à nous contributeurs de leur imposer en utilisant name=« Platane », même si certaines cartes thématiques l’afficheraient de la sorte. Mettre des names arbitraires pour aider certaines réutilisations empêcherait l’affichage de vrais noms.
Pour l’exemple spécifique des mairies, interroger les frontières administratives pour avoir le nom de la commune semble aisé vu que de nombreux consommateurs le font déjà, mais si quelqu’un a des exemples où c’est difficile il serait intéressant de les partager.
C’est malheureusement exactement le contraire que je soutiens concernant les mairies. La reconstruction des noms de mairie est extrêmement complexe comme l’a démontré le billet de blog d’overflorian. Et vouloir les supprimer d’OSM n’apporte strictement rien si ce n’est le plaisir de dire « nous respectons à la lettre les principes d’OSM dans tous les cas ». Ceux qui veulent enlever l’info et reconstruire des trucs avec des astuces de geek, tant mieux pour eux. Mais pour les gens normaux le nom de la mairie non fourni par OSM c’est un exemple de galère sans nom pour juste afficher quelques étiquettes sur sa carte.
Par contre dans le cas du « Platane » je suis totalement d’accord, ça ne sert à rien.
Intéressant : la rendu breton affiche Ti-Ker, non parce que c’est le nom de la mairie en question mais parce que Maire se dit Ti-Kêr en breton. Illustration au choix de la possibilit pour le rendu de créer des noms artificiles ou de la non pertinence de l’icône ou de son affichage trop tardif.