fait pour le département Saône & Loire

fait pour le département de Saône & Loire

Today, I made my first big modification on the town of ath

that consisted by correcting a whole neighborhood :

• I added buildings
• I also removed/modified some of the originals buildings to make them fit to the PICC wallonia layer
• I also changed the position of some nodes to place them just on the door of each shops

here is the changeset link : ath

Ps : My main goal is to reshape the entire town of ath.

Suite à l’import des batiments et adresses en Belgique, j’avais comparé, dans un article précédent, le nombre d’adresses par communes entre OSM et la source de référence en Wallonie, le PICC, en septembre 2022.

Quelques mois plus tard, une mise à jour des principales figures.

En Wallonie, 1,097,519 adresses sont répertoriés dans OSM, contre 1,634,840 dans ICAR (67.1%). On était à 64.4 % en septembre 2022.

Voici une carte choroplète, montrant, pour chaque commune, le degré de complétion des adresses dans OSM par rapport à ICAR. Les limites de provinces sont soulignées par un trait plus gras.

Et une carte de l’évolution des adresses depuis septembre 2022.

Les 10 communes où les adresses ont le plus progressé sont:

1. Frasnes-lez-Anvaing
2. Rumes
3. Lens
4. Le Roeulx
5. Hélécine
6. Antoing
7. Binche
8. Ellezelles
9. Braine-le-Comte
10. Court-Saint-Etienne

Et les communes où les adresses sont le moins complètes sont:

1. Manage
2. Dour
3. Ecaussines
4. La Louvière
5. Braine-le-Comte
6. Le Roeulx
7. Celles
8. Flobecq
9. Quevy
10. Soignies

À noter que dans beaucoup de communes, toutes les adresses sont complètes (par ex. Saint-Ode, fait récemment), mais que le rapport est toujours en-dessous de 100%, parce qu’ICAR affiche des numéros d’adresses pour des parcelles loties, mais non encore construites.

RDV sur cette page de discussion et sur cette carte pour continuer à compléter les adresses.

département de l’Aube

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

Je suis sur le point de partir pour le GR 10 et je m’apperçois qu’il manque un grand nombre des horaires d’ouverture des magasins dans les villages que traverse le GR 10. C’est une chose qui peut être très importante; aussi mon objectif est-il de compléter un maximum ces données. Si d’autres veulent se lancer dans l’aventure, ce serait formidable.

Le mercredi 12 avril 2023 de 18h00 à 21h00

Droit au Vélo – ADAV et l’OMJC vous invitent à une rencontre autour d’Openstreetmap à la MRES.

Cet événement a lieu dans le cadre de l’opération “Libre en fête” qui propose des opérations de découverte du Logiciel Libre et de la culture libre à destination du grand public.

Avec OpenStreetMap, vous pouvez participer à la construction d’une carte en ligne libre, gratuite et partagée avec le monde entier !

Programme de la soirée

• Tour de table, présentation des contributeurs et contributrices

• Démonstration de l’usage d’OpenStreetMap par l’ADAV

• Discussion et questions diverses

Lieu de la réunion: MRES Maison Régional de l’Environnement et des solidarités – Salle Yser, 5 rue Jules de Vicq, Lille Fives

Plan: https://osm.org/go/0EgKBuXuR?m=

Note de l’éditrice: Écrit à l’origine par Heather Lesson, Dinar Adiatma, et Can Ünen. Ceci est une traduction.

Disposer des données cartographiques les plus récentes et les plus précises est crucial pour les interventions d’urgence. La communauté OpenStreetMap et ses partenaires ont créé ceci pour soutenir les humanitaires. Les données OSM sont partagées sur la platforme Humanitarian Data Exchange et sont utilisées pour développer des produits de gestion de l’information pour les décideurs répondant aux urgences.

Cette courte note a pour but d’aider les nouveaux mappers à démarrer et d’encourager la qualité des données. La communauté turque locale, Yer Çizenler, et HOTOSM coordonnent cette activation. Pour la Syrie, la cartographie est plus complexe puisqu’il s’agit d’une zone de conflit. HOT travaille en étroite collaboration avec certains collègues et partenaires pour évaluer soigneusement toutes les tâches HOT en Syrie. Comme il s’agit d’une zone de conflit, nous collaborerons pour nous assurer que les contributions OSM du Gestionnaire de Tâches HOTOSM ne causent aucun dommage. Nous sommes là pour assister ceux et celles qui portent aide.

Nous savons que beaucoup veulent aider. Nous vous demandons de parler avec d’autres mappers pour apprendre et aider les intervenant.e.s tout en respectant les directives locales.

La qualité des données est importante dans OpenStreetMap (OSM) car elle affecte directement la précision et l’utilisation de la carte. Toutes les données doivent être adaptées à l’objectif, et pour qu’elles correspondent à l’objectif, il faut le moins de lacunes possibles. Une mauvaise qualité des données peut conduire à des informations incorrectes ou obsolètes, ce qui a un impact négatif sur les personnes qui comptent sur OSM pour la navigation, la planification et la prise de décision. En savoir plus ici.

Contacts - Les contacts des Coordinateur d’Activation de HOT peuvent être trouvés sur le wiki OSM

Nouveaux mappers

Êtes-vous nouveau sur OSM? La situation est une urgence complexe et nous sommes heureux de vous aider à démarrer:

1. Regardez les vidéos de base sur la façon de cartographier via Map Give
2. Consultez Learn OSM et consultez le guide wiki OSM pour cette urgence
3. Observez les livestream quotidien et rejoignez un mapathon
4. Participez aux défis MapRoulette de Yer Çizenler pour marquer les bâtiments effondrés à partir d’ensembles de données vérifiés
5. Rejoignez les canaux slack HOTOSM pour #disastermapping et #mappersupport
6. Demandez de l’aide - la communauté est là pour soutenir votre parcours OSM

Mappers Intermédiaires et Experts

Bienvenue! Voici comment commencer:

1. Voici les tâches du Gestionnaire de Tâches de HOT - À JOUR
2. Petites tâches sur MapRoulette via Yer Çizenler et la page principale de MapRoulette
3. En raison de la largeur du projet, la cartographie assistée par IA est encouragée à l’aide de l’éditeur RapiD
4. Rejoignez les mapathons
5. Surveillez les canaux du slack HOT
6. Lisez tous les conseils sur le wiki
7. Aidez les nouveaux mappers, donnez des commentaires aimables et soutenez les équipes de validation/qualités des données

Resources

• Comment les données sont-elles utilisées via Pete Masters
• Participez à un mapathon - en personne et en ligne
• Livestream quotidien de Yer Çizenler
• Page wiki OSM avec tous les détails
• Guide pour utiliser l’éditeur RapiD pour les utilisateurs débutants et expérimentés

Après 3-4 mois à dégommer du mauve dans le 22, voilà une image satisfaisante. Je me suis attelé à combler les vides dans les Côtes d’Armor à la fin de l’été 2022.

Plusieurs remarques:

1. Un département c’est grand. Le chantier est énorme, surtout dans les zones rurales. J’ai pas connu les débuts d’OSM, mais je suis passé sur des zones où il manquait carrément des routes entre des villages, je savais pas que ça existait encore sur la France.
2. Je suis du genre à vouloir micro-cartographier tout ce que je vois, mais même en enrichissant la carte à la vitesse d’une commune par semaine il me faudrait 7 ans pour aller d’un bout à l’autre du département (et clairement j’ai pas ce rythme).
3. Ce qui me prend le plus de temps c’est l’occupation des sols et la correction des bâtiments, ce qui n’est vraiment pas le plus utile mais je suis accro au rendu (ci-dessous les zones rurale en bocage avec la couche Thunderforest Landscape)
4. Donc je me suis fait une liste de choses à cartographier en priorité, comme les routes, les adresses, les lieux de la BD Topo, etc. J’ai mis tout ça dans un tableur Calc pour visualiser mon avancement et pas perdre ma motivation trop vite.

Je vais maintenant essayer de dégommer du rouge (noms de rues manquantes sur la couche BANO) + adresses mais n’étant pas sur place, je vais surtout pondre une flopée de notes et de fixme.

Voilà pour les premiers mois,

A la prochaine !

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.

Les adresses ont toujours été un réel problème pour tout nouvel utilisateur OSM. C’est encore plus problématique lorsqu’en tant que contributeur, l’on veut s’y attaquer – tellement l’entreprise est immense et les pièges nombreux.

Heureusement, les astuces et outils mis en place par la communauté de longue date couplés à l’obligation légale récente pour les communes de création d’une base adresse vont bouleverser cet état de fait.

Dans cet article, je m’attacherai à faire le point sur les outils qui sont à notre disposition pour cartographier les adresses, mais aussi à expliquer les différences entre BANO, BAN et BAL et leurs ressources associées. Pour finir, je vous exposerai ma façon de renseigner les adresses de la manière la plus complète possible.

Outils d’adressage de masse

PIFOMÈTRE (pifo pour les intimes) : la Page d’Interconnexion Fantoir-OSM pour Minimiser l’Énorme Tas de Rues Égarées, ou plus simplement, l’outil ultime développé spécialement pour intégrer les voies et adresses en France. Vous trouverez une démonstration de son fonctionnement ici.

HouseNumberTaggingTool qui est un greffon JOSM très abouti, mais n’ayant aucun lien avec les Bases Adresses qui nous intéressent dans cet article.

On peut aussi citer StreetComplete, qui depuis peu, permet de saisir les adresses directement depuis le terrain. Idéal pour un lotissement neuf. Cela nécessiterait la présence d’une incrémentation automatique pour être vraiment efficace, mais l’outil étant jeune, on va laisser le temps au temps.

BAL, BAN, BANO : mise au point

Lexique et Historique

BANO : Base Adresse Nationale Ouverte initié par OpenStreetMap France en 2014 en scrapant les adresses des planches cadastrales

BAN : Base Adresse Nationale en réponse à la BANO associant LaPoste, l’IGN, Etalab et OSM France

BAL : Base Adresse Locale. Depuis la loi 3DS de février 2022, chaque commune se doit, à partir de la BAN, de créer, vérifier et certifier sa propre base adresse.

Pour ceux qui veulent découvrir plus en détails l’historique et les enjeux économiques, stratégiques et politiques qui se sont joués à l’époque BANO/BAN, je vous conseille cette étude passionnante (https://www.cairn.info/revue-reseaux-2021-1-page-151.htm)

Comment est construite la Base Adresse Nationale ?

La Base Adresse Nationale est constituée commune par commune, sur le principe suivant : si la commune dispose d’une Base Adresse Locale, ce sont ces adresses qui sont incluses dans la Base Adresse Nationale ; dans le cas contraire, la liste des adresses est générée par défaut à partir des meilleures sources disponibles (DGFiP, IGN, ARCEP, Guichet Adresse). source : https://adresse.data.gouv.fr/donnees-nationales

La BAN, le film (director’s cut) : https://ghost.adresse.data.gouv.fr/content/media/2022/06/Vide-oBANv6.mp4

Côté Base Adresse Locale

Modèle d’attribution

Pour comprendre comment est construit une base adresse locale : https://aitf-sig-topo.github.io/voies-adresses/files/AITF_SIG_Topo_Format_Base_Adresse_Locale_v1.3.pdf

Ce qui est intéressant avec ce modèle est qu’une adresse peut correspondre à plusieurs points telles que délivrance postale, entrée, bâtiment, etc. (attribut position p.13) Il permet en outre de renseigner les toponymes en langue locale. Pour l’instant, je n’ai pas eu l’occasion de tomber sur des BAL aussi finement renseignées.

Et pour le commun des mortels ?

L’idée étant de simplifier le travail des communes, il leur faut un outil user-friendly. En voici un aperçu :

La documentation vidéo officielle de prise en main de l’outil : https://peertube.adresse.data.gouv.fr/

On peut aussi tester directement l’outil en mode bac à sable : https://mes-adresses.data.gouv.fr/new?demo=1

État des lieux de l’avancement

L’état du déploiement des BAL : (https://adresse.data.gouv.fr/deploiement-bal)

Intégration BAL

Considérations

L’idée pour intégrer des adresses dans OpenStreetMap est de cibler les communes ayant certifiées à 100% leur BAL. Si on exclut le terrain, c’est la source la plus fiable (en théorie, car on a déjà vu des BAL certifiées 100% désastreuses…). Inutile de perdre son temps sur des communes sans BAL, il y a bien assez à faire avec les communes ayant certifiées leur BAL à 100%. Les points sont souvent bien, voire très bien placés ce qui rend le travail bien plus agréable et rapide. Ceux qui ont l’habitude de Pifomètre et des points adresses foireux de la BAN comprendront. Enfin, si vous intégrez des adresses non certifiées, vous rajoutez du travail aux futurs contributeurs qui, une fois la BAL certifiée, devront s’embêter à évaluer la qualité des données déjà présentes. Il est beaucoup plus pratique de travailler sur une commune vierge.

En France, il est d’usage d’utiliser un point adresse placé à la frontière entre l’espace public et l’espace privé. Par exemple, au niveau de la porte d’entrée pour un immeuble de centre-ville, ou au niveau du portail/portillon pour un pavillon de quartier résidentiel.

En France, il est inutile de renseigner le code postal et la ville : ces informations se trouvent déjà dans le contour géométrique de la commune.

Avertissements

Cette procédure est adaptée pour des petites communes sans aucune adresse dans OSM avec des BAL certifiées à 100%. La méthodologie que je décris ici n’est pas la meilleure, mais correspond à mes besoins. Je dois avouer que j’ai souvent du mal à comprendre les différentes colonnes de Pifomètre quand c’est un peu le bazar sur le nom des rues.

Soit j’utilise uniquement le fichier BAL, soit je l’utilise en complément de Pifomètre. Tout dépend de la BAL que je récupère et de la qualité des infos déjà dans OSM.

Inconvénients

• nécessite de mettre en conformité le fichier BAL avec la nomenclature OSM (rapide)
• nécessite parfois de corriger l’accentuation, les apostrophes et la casse du nom des voies (variable suivant les corrections à apporter et le nombre de voies)

Intérêts

• permet d’avoir une vue générale et d’apprécier la qualité du positionnement des adresses assez rapidement
• traiter le fichier d’un coup évite le côté clicodrome de pifo
• nom des voies à jour
• permet d’adresser les lieux-dits avec addr:place (ce que ne permet pas encore Pifo)
• la BAL peut contenir des informations qui ne remontent pas dans pifo (certaines voies, le nom des quartiers, résidences, lieux-dits, etc)

Si vous avez des doutes quant à cette procédure, basculez sur l’outil Pifomètre, et une fois l’adressage terminé, jetez un coup d’œil dans le fichier de la BAL pour voir s’il n’y a pas des informations à récupérer en plus.

Méthodologie

0. Au préalable

Dans JOSM, il vous faudra :

• le greffon JOSM OpenData
• le style de coloriage ColouredStreet (découverte express du CapitaineMoustache)

Attention aux doublons si des adresses sont déjà présentes. Pour vérifier la présence d’adresses sur une commune : (https://overpass-turbo.eu/s/1mHQ) en renseignant le nom de votre commune au bon endroit de la requête.

1. Vérifier le nom des voies

Il faut vérifier que les noms des voies soient à jour dans OSM : imagerie BANO dans JOSM ou via ce lien https://tile-a.openstreetmap.fr/~cquest/leaflet/bano.html#6/47.000/2.000 (source : commune)

Sachant que même si la correspondance est parfaite, il se peut que le nom des voies ne soit pas complètement à jour par rapport à la BAL. Si je ne me trompe pas, la BAL alimente la BDTopo qui sert de référence et de comparaison à l’outil ci-dessus et à Pifo. Malheureusement, la mise à jour BAL > BDtopo semble longue.

Par exemple, une BAL datant de février 2022 possède des noms de voies absents de la BDtopo en décembre. C’est aussi pour cela que je préfère travailler directement avec la BAL.

2. Choisir une BAL et repérer les informations utiles

Rendez-vous à cette adresse :Déploiement BAL puis recherchez une BAL certifiée 100% et téléchargez-la au format BAL. Vous obtenez un fichier .csv.

Je glisse ce .csv directement dans JOSM avec une imagerie aérienne pour évaluer la qualité du positionnement des points. Je me suis arrêté à cette étape pour 2 BAL certifiées abusivement. Mention spéciale à la commune de Boule d’Amont qui a certifié ses 39 adresses à la même position, perdue dans la forêt.

Ensuite, j’ouvre la BAL avec LibreOffice Calc, mon premier réflexe est de regarder si elle contient des informations enrichies, c’est-à-dire des renseignements autres que les points adresses. Pour ce faire, je trie la colonne numéro par ordre décroissant. D’expérience, j’ai déjà rencontré des nombres 9999 ou 5000 qui renseignent sur le nom de lotissements/quartiers (voire même leurs points d’entrée/sortie), de résidence ou encore de POI municipaux.

J’en profite aussi pour repérer si elle contient des noms de lieux-dits : colonne lieudit_complement_nom et à quoi correspond la position des points (entrée, bâtiments, etc)

3. Mise en conformité du fichier .CSV

Le schéma BAL contient beaucoup d’informations inutiles à OpenStreetMap et ne suit pas la même nomenclature ni la même structure.

Par exemple, le nom des voies doit être écrit en minuscules accentuées, mais on trouve de tout, les communes ne s’embêtant pas trop là-dessus. C’est un champ sur lequel il faut être vigilant. La règle sur OSM étant de respecter la charte de toponymie de l’IGN (tl;dr -> majuscules partout sauf pour les petits mots).

Autre problématique, les numéros et suffixes sont 2 champs distincts au format BAL contre 1 seul dans OSM. Il faut donc regrouper ces 2 champs en 1 en veillant à espacer les bis, ter du numéro et les écrire en minuscules alors qu’il faudra accoler les A, B, C, D écrits en majuscules.

1. Créer une nouvelle colonne addr:housenumber pour concaténer les colonnes numero + suffixe =CONCAT(I2;” “;J2) Je traite les cellules contenant des suffixes A, B, C au cas par cas quand il y en a.
2. Renommer la cellule voie_nom en addr:street
3. A priori, le champ du lieu-dit pourrait se remplacer par addr:place.
4. Vérifier/corriger la présence d’accents et la casse du nom des voies (il convient ici de jouer sur le menu format > texte pour la casse et/ou d’utiliser la fonction rechercher/remplacer)
5. Remplacer les apostrophes typographiques (courbées) par des apostrophes dactylogrpahiques (droites) ’ -> ‘
6. Enregistrez le fichier.

Un petit script pour automatiser tout ça serait pas mal, mais hors de mes compétences. On m’a orienté vers ce projet que je n’ai pas encore regardé (https://github.com/osmlu/csventrifuge).

NB. Si la BAL comprend de nombreux numéros spéciaux (5000 ou 9999), on peut faire 2 fichiers BAL distincts :

• le premier contenant uniquement les adresses
• le deuxième contenant uniquement les points spéciaux

4. Place à l’action

1. Effectuez un glisser-déposer de la BAL modifiée dans JOSM. Choisissez la projection Lambert 93.
2. Sélectionnez tous les points (Ctrl+A), puis dans la table d’attribution de droite : ne gardez dans un 1^er temps que les champs addr:housenumber et addr:street, voire addr:place. L’attribut position peut avoir son utilité.
3. Téléchargez les données OSM de la zone concernée puis fusionnez les calques. Certains préfèrent ne charger que les voies et y rajouter les adresses. Personnellement, je préfère charger toutes les données, car j’en profite pour recaler ou (re)tracer des routes ce qui peut créer des conflits si des données sont invisibles. J’en profite également pour vérifier que les Rue de la Mairie / des écoles / de la Poste / du lavoir / de la fontaine ont bien une mairie / une école / etc renseigné dans OSM.
4. Chargez une imagerie aérienne ou 2. Chez moi, les BDOrtho et Bing sont complémentaires.
5. Dans le menu Affichage > Coloriage, activez le coloriage ColouredStreet et désactivez le coloriage JOSM par défaut. Éventuellement, jouez des filtres pour dégager la vue.
6. Ce style de coloriage permet de repérer assez vite si les noms de rue ne coïncident pas avec les adresses ou si le nom d’une rue ne se poursuit pas jusqu’à l’adresse la plus éloignée. Corrigez en fonction.
7. Ne pas oublier de s’occuper des points spéciaux (numéros 5000 et 9999) comme il se doit : les intégrer avec les bons tags ou les supprimer.
8. Si vous avez gardé l’attribut position, ne pas oublier de le supprimer en masse.
9. Pour les contributeurs pointilleux, on peut toujours améliorer le positionnement des points adresses, notamment avec une bonne imagerie :)
10. Envoyez les changements en précisant la source : BAL du MM/AAAA

5. Les finitions

• Vérifier le lendemain si osmose ne remonte pas d’erreurs attributs manquants > numéros de rues
• Importer le bâti cadastre manquant

Après-coup

• Établir un suivi sur le Wiki pour soi mais aussi pour les autres contributeurs du secteur ou la future génération. Personnellement, j’utilise un tableur perso et je crée une page wiki par commune avec un tableau de suivi généraliste.
• Communiquer sur les réseaux sociaux en mentionnant la commune et @adresse.data.gouv.fr
• Valoriser la réutilisation en envoyant un courriel de remerciement à la mairie (l’occasion de faire remonter les erreurs trouvées s’il y en a et de sabrer le champagne si quelqu’un vous répond)

Bonjour,

Je vous écris en tant que contributeur bénévole au projet OpenStreetMap qui est un projet collaboratif mondial de cartographie qui vise à produire des données libres par tous et pour tous (citoyens, collectivités, entreprises).

Par ce message, je tiens à vous remercier pour la publication de votre Base Adresse Locale. Ces adresses ont été intégrées à notre projet (visualisation ici) et alimenteront en cascade les nombreux services et applications qui en dépendent.

Cordialement,

Conclusions

Si l’enthousiasme autour des BAL a pu soulever la question d’un import automatique, cela ne me semble pas judicieux. Chaque BAL étant gérée séparément sans organe de vérification, la qualité et le respect des normes du schéma sont variables. Néanmoins, la gestion des bases adresses par les communes constituent assurément une avancée majeure, tant dans la qualité générale de la BAN que dans son évolution et sa pérennité dans le temps.

Ce transfert de compétences étant tout récent, certains points restent à améliorer côté BAN, comme une harmonisation des données renseignées ou une synchronisation rapide entre les voies déclarées dans la BAL et la BDTopo.

C’est d’ores et déjà une opportunité indéniable pour tous les services liés de près ou de loin à l’adressage sur le territoire français. Il convient de nous en emparer intelligemment et avec la méticulosité qu’on connaît aux contributeurs OSM.

La première étape majeure sera de renseigner les adresses de communes vierges, grâce à Pifomètre ou à la méthode ci-dessus que je trouve plus précise.

Le deuxième challenge sera de gérer le différentiel lorsqu’une commune déjà traitée mettra à jour ses adresses pour y intégrer les nouveaux lotissements. Pifomètre sera certainement l’outil le plus adapté !

Un grand merci aux pionniers d’OSM-Fr qui ont mis un franc coup de pied dans l’inertie étatique il y a déjà presque 10 ans !

Yapluka, la BAL est dans notre camp !

PS: tout retour est le bienvenue afin de continuer à améliorer le processus ou de corriger les erreurs/imprécisions que j’aurais commises.

This happens on 15.11.2022, somebody mapped the 100’000th kilometer of nordic ski piste. .

These are the trails tagged piste:type=nordic. They describe several practices : backcountry touring, classic style on prepared rails or skating on large groomed pistes. In OSM, they are distinguished thanks to the key piste:grooming=backcountry/scooter/classic/skating or classic+skating.

Yves - Opensnowmap.org

Bonjour à toutes et à tous. S’il vous plait est ce que quelqu’un peut m’aider à travers des explications comment faire pour créer un réseau OSM (groupe de 10 restreint dans lequel des personnes peuvent échanger). comment appartenir au réseau OSM de son pays?

genea togny berton

Intro

En navigant les données de la Sibra dans les différentes cartes (Apple Plan, Google Maps, OSM…), je me suis rendu compte qu’il y avait pleins d’informations qui n’était pas à jour ou alors pas unifier sur chaque platform.

J’ai donc commencer à modifier les arrêts de bus sur OSM puis j’ai trouver les données GTFS de la Sibra sur transport.data.gouv.fr mais il y a pleins de chose qui ne vont pas dans le fichier stops.txt: stop_id incohérent, arrêt dédoublé, lat/lon incorrecte, manque d’info… Et ce genre de problème sont dans tous les fichiers. J’ai donc décider de créer un repo GitHub Sibra-GTFS dans lequel je met toutes les données de manière uniforme et à jour au fur et à mesure que je fait les modifications sur OSM.

L’objectif final est de refaire tout le réseau Sibra (ouf…) sur OSM ainsi qu’au format GTFS.

Mise à jour OSM

Pour être sûr que les données soient cohérentes sur l’ensemble du réseau Sibra, j’ai mis en place une nomenclature des différents éléments du réseau:

Emplacement ou s’arrête le bus

Un point sur une route qui désigne l’emplacement d’arrêt du bus. Les attributs suivant le désigne (exemple Meythet Centre):

• bus=yes
• highway=bus_stop
• public_transport=stop_position
• ref=MTC1
• name=Meythet Centre
• network=Sibra
• network:wikidata=Q3488417

Arrêt de bus / Platform

Généralement une ligne qui désigne la zone d’attente (sur le trottoir) des voyageurs. Il y en à un de chaque côté de la route. Les attributs suivant le désigne (exemple Meythet Centre):

• bus=yes
• highway=bus_stop
• name=Meythet Centre
• network=Sibra
• network:wikidata=Q3488417
• public_transport=platform
• ref=MTC1

Des attributs supplémentaires peuvent être ajouter:

• tactile_paving=yes
• wheelchair=yes

Abri de transport en commun

Surface de l’abri d’un arrêt de bus. Les attributs suivant le désigne (exemple Meythet Centre):

• amenity=shelter
• building=yes
• name=Meythet Centre
• shelter_type=public_transport

Des attributs supplémentaires peuvent être ajouter: - bin=yes - lit=yes - bench=yes

Zone d’arrêt

Zone d’arrêt avec comme relation tous les éléments d’un arrêt de bus créer précédemment. Les attributs suivant le désigne (exemple Meythet Centre):

• name=Meythet Centre
• network=Sibra
• public_transport=stop_area
• type=public_transport

Ensuite chaque relation est de type:

• Emplacement ou s’arrête le bus: stop_position
• Arrêt de bus / Platform: platform
• Abri de transport en commun: shelter

Je n’ai pas encore refais un itinéraire complet mais je mettrais à jour la nomenclature et la méthode quand je le ferais.

Création du GTFS

Comme dit dans l’intro, j’ai créer un repo GitHub Sibra-GTFS.

A chaque fois que j’édite un arrêt de bus dans OSM, je créer dans le tableau stops.txt plusieurs lignes. Une ligne par arrêt de bus / platform (en général 2 car une de chaque coté de la route), ainsi qu’une ligne pour la zone d’arrêt qui est parent des platform. Exemple des lignes pour l’arrêt Meythet Centre:

• stop_id stop_name stop_lat stop_lon location_type parent_station wheelchair_boarding
• MTC1 Meythet Centre 45.91452 6.09196 0 MTC 1
• MTC2 Meythet Centre 45.91463 6.09192 0 MTC 1
• MTC Meythet Centre 45.91455 6.09199 1 0

Comme pour OSM, quand je referais un itinéraire complet je mettrais à jour la méthode.

En attendant, n’hésitez pas à participer et à faire un pull request sur le repo.

Comment la caractériser objectivement ? Telle était la question que je me posais avant d’interroger les sources spécialisées (voir ci-dessous les principales) Il s’avère que la question porte très vite à débat, et cela a une certaine logique : la perception du caractère cyclable d’une route dépend du cycliste qu’il soit adulte sportif au quotidien ou enfant.

Moi je veux obtenir une carte pour un(e) enfant de douze ans. Pas de réponse claire : alors il faut militer pour obtenir des aménagements cyclables, ou la réduction de la circulation automobile.

Sources

• Discussion sur le forum OSM France - 2017-2021
• Carte de la cyclabilité de l’association Droit au vélo (Nord) - 2016
• Article du blog de l’association Trégor Bicyclette - 2017
• Article du Wiklou
• Article du blog Urbanisme cyclable - 29/08/2022
• Article de l’association Vélo et Territoires - 11/05/2022

Le changement climatique affecte la morphologie des arbres et leur résistance à la sécheresse. En effet, en cette année particulière, les végétaux ont subi un stress plus important que les années précédentes et que cela se retrouve au niveau de leur croissance.

Ce qui est dommage dans OpenStreetMap, c’est qu’il n’existe aucune entité institutionnelle ou commerciale qui a pour objectif d’assurer la présence d’informations de base.

Ce que j’entends par informations de base :

• routes
• bâti
• cours d’eau
• bâtiments essentiels (église et mairie par exemple)

Finalement, un peu ce que propose l’IGN.

---

Ce qui est très appréciable en revanche, c’est de trouver un endroit pauvre en données qui attise en nous une folle envie d’inverser complètement la donne.

En parcourant les PO dans le but d’intégrer les défibrillateurs du CD66, je suis tombé sur quelques villages délaissés d’OSM.

Ici, à La Bastide, grâce au site internet de la mairie, à l’IGN, à Mapillary et à Wikimedia, j’ai pu apporter pas mal de nouveautés sans bouger de chez moi. Attention, la cartographie de salon est réservée à un public expert, merci de ne pas reproduire cette cascade chez vous sans un minimum de retenue et d’esprit critique vis-à-vis des sources : de leur qualité et de leur temporalité.

C’est une sorte de travail de détective que j’aime bien compléter par une visite sur le terrain pour peaufiner.

Dans les ajouts :

• la mairie (et oui)
• l’église (aussi !)
• infos sur la voirie (type et nom)
• les endroits notables
  • lavoir
  • salle poly
  • camping municipal
  • gîtes municipaux
  • café restau
• divers équipements
  • terrain de boules
  • boite aux lettres
  • défibrillateurs
  • point d’eau
  • oratoire
  • arrêt de bus
  • jeux pour enfants
  • bbq

Ne manque plus que des contributions de terrain !

J’ai rapidement comparé les adresses d’OSM en Wallonie avec la base d’adresses de référence, ICAR par commune. La commune la moins bien cartographiée en termes d’adresses est à 12% d’adresses. C’est surtout en Hainaut et dans le Brabant Wallon qu’il manque le plus d’adresses.

Comment ?

J’ai compté le nombre de points d’adresses dans ICAR et dans OSM par commune en Wallonie, en utilisant QGIS. Auparavant, j’ai transformé les bâtiments OSM (polygones) qui ont une adresse (addr:housenumber) en point, et je les ai fusionnés avec les points d’adresses OSM seuls. J’ai finalement calculé le ratio entre le nom d’adresses dans OSM et dans ICAR.

Résultat

En Wallonie, 1,025,540 adresses sont répertoriés dans OSM, contre 1,634,840 dans ICAR (64.4%).

Voici une carte choroplète, montrant, pour chaque commune, le degré de complétion des adresses dans OSM par rapport à ICAR. Les limites de provinces sont soulignées par un trait plus gras.

Le top 10 des communes les plus complètes:

• Olne
• Tenneville
• Geer
• Rouvroy
• Soumagne
• Dalhem
• Anthisnes
• Tinlot
• Blégny
• Fexhe-le-Haut-Clocher

Et le flop 10:

• Manage
• Dour
• Ecaussines
• La Louvière
• Braine-le-Comte
• Le Roeulx
• Frasnes-lez-Anvaing
• Rumes
• Flobecq
• Soignies

Quelques notes/observations:

• le fichier ICAR utilisé a au moins 2 ans!
• Certains communes ont plus d’adresses dans OSM que dans ICAR (vert foncé): cela s’explique parce que le fichier ICAR en ma possession semble manquer certaines adresses (ex: Tenneville), ou parce que ma méthode ne supprime pas les duplicas venant d’OSM (ex: une adresse sur un bâtiment et la même adresse sur un restaurant dans ce bâtiment) ou pour d’autres raisons (séparation d’adresses en points multiples dans un même bâtiment d’appartements ou non).
• la carte indique où travailler pour améliorer les adresses dans OSM mais pas la quantité de travail, vu la densité d’habitat très différentes d’une commune à l’autre (commune urbaine vs rurale).

Si vous êtes intéressé·e à compléter les adresses en Belgique, rdv sur cette page et sur le chat dédié!