NB: cross-posting of https://www.nobohan.be/2023/10/06/openardennemap-en-carte-web/ (in French there)

I finally set up a tile server for OpenArdenneMap! See this webmap, and this article for more details.

OpenArdenneMap is a cartographic map style dedicated to printed maps, so it does not render ideally in a web map server. It is built as a “cartoCSS/Mapnik” style and is also available as a QGIS style for some time now. Since it is based on Mapnik, this style can be used for generating map tiles, although it is primarily designed for printing.

If you’re looking for some ready-to-use maps to print, have a look at hiking.osm.be.

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.

Note: il y a une version française ici

From 2019, the cartographic style OpenArdenneMap is updated every 6 months. OpenArdenneMap is a cartographic style for topographic maps based on OSM data. Here are some notes for the last version.

OpenArdenneMap goes on QGIS

OpenArdenneMap was originally developed as a cartographic style with the imposm importer and a cartoCSS style derived from OSMBright. Later the osm2pgsqlimporter was used instead of the imposm. From 2023, the OpenArdenneMap is also available in QGIS, using the same osm2pgsqlimporter for building the map layers.

The tools used for making maps have some influence on the cartographic style itself. The aim of this QGIS support is to reproduce the same feeling than the maps produced with the Mapnik/cartoCSS style, even though the 2 solutions are not 100% equivalent.

Although it still requires a postGIS database, the QGIS style is much simpler to use for composing maps at various scales than the Mapnik/cartoCSS one. It was also much simpler to set up.

Here’s an extract with Mapnik

And here with QGIS:

And now some key findings when moving this style from Mapnik/cartoCSS to QGIS.

Much more simple rules for scaling in QGIS

QGIS supports the use of geographic units for defining the sizes of symbols (meters at scale, map units), whereas Mapnik/cartoCSS, as far as I know, only deals with pixels units. It means that, in QGIS, you can define a size which will be depending on the map scale. This is really useful for very high map scale (i.e., > 1:10000), where some elements such as road widths can take their “real” size on the map. For the same effect in Mapnik, we have to define different widths for every zoom level.

Use of QGIS variables

A key advantage of using Mapnik and cartoCSS is that we can define variables that are used throughout the project, typically for some dimensioning variables and colors. Hopefully, we can also define variables in a QGIS project (Go to Project > Properties > Variables) and use them in the style definitions.

Use filtered full Postgis table filtered vs SQL layers

The same layers used in Mapnik were used as QGIS layers. Often, these layers are not just some filters applied to a “planet_osm_points/lines/polygons” table but they do some data transformation. For instance, the layer for water labels is as follows:

SELECT way, waterway AS type, replace(name, 'Ruisseau', 'Rau') AS name FROM planet_osm_line WHERE waterway IN ('canal', 'river', 'stream') AND name IS NOT NULL UNION ALL SELECT ST_LineMerge(ST_ApproximateMedialAxis(ST_SimplifyPreserveTopology(ST_MakePolygon(ST_ExteriorRing(way)), 50))) AS way, water AS type, replace(replace(name, 'Etang', 'Étg'), 'Étang', 'Étg') AS name FROM planet_osm_polygon WHERE water IN ('pond', 'lake', 'basin', 'reservoir') AND name IS NOT NULL AND way_area > 10000

which combines linear ways from planet_osm_line with lines created from planet_osm_polygon using a bunch of PostGIS functions (ST_ApproximateMedialAxis, etc.).

These PostGIS queries were just defined as layers in the QGIS DB manager and then added to the map.

However, for some performances issues, it seems easier to filter directly from a PostGIS layer from the DB rather than defining a new SQL layer with the DB manager. Whenever possible, layers are full PostGIS tables that are just filtered for the required elements.

Known stuff to do

The work of porting the Mapnik style to QGIS is not quite finished, there are still some unresolved issues and/or limitations of QGIS compared to Mapnik.

For instance, I have a issue with overlapping, or at least too close symbols in QGIS maps. This is a core functionality of Mapnik, and a so common but also so hard issue in cartography: how do you prevent symbols that overlaps each other, either from the same layer or from different layers? The same applies to labels. Unfortunately, until now preventing overlapping symbols was not found in QGIS. For instance, a cluster of picnic tables in a park will be shown on the map with several symbols too close from each other, while we would like to have just one symbol for the cluster.

To conclude

This work of switching from Mapnik to QGIS is not finished. I do not yet know which software will be preferred in the future for OpenArdenneMap. Note that much of the mapping work is applied directly to the data via PostGIS queries. Automating this cartographic work on the basis of OSM data (automatic generalisation, displacement, …) is an area that is still little explored today.

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é!

Un projet occupe une poignée de contributeurs OSM en Belgique: l’import des batiments, c’est-à-dire compléter tous les batiments à partir des données officielles et ajouter la référence de ces données officielles aux batiments existants.

Depuis des contacts initiés fin 2021 avec le service public de Wallonie (SPW), cet import est également disponible pour la Wallonie, sur base des données du PICC: la base de référence pour les batiments en Wallonie.

Cet article expose brièvement la méthodologie suivie et des premiers résultats sur 3 sections administratives de la commune de Neufchâteau, principalement en repérant des nouveaux batiments et des batiments détruits.

Quid des batiments en Belgique?

À ma connaissance, il n’y a pas eu d’état des lieux récents de la complétude des batiments en Belgique. D’une manière générale, la majorité des batiments ont été cartographiés, souvent à la main, sur base d’images aériennes (ou du fond de plan du PICC en Wallonie). Les contributeurs trouvent en cherchant un peu des communes où il manque davantage de batiments que d’autres, ou bien des endroits où les batiments devant avoir une adresse n’en ont pas. On pourrait faire une analyse plus détaillée par commune pour estimer le taux de complétude des batiments.

Quoiqu’il en soit, voici une carte de l’état d’avancement de l’import: http://umap.openstreetmap.fr/fr/map/building-import-status_714473#8/49.792/5.823; Attention, comme dit plus tôt, une majorité de batiments ayant déjà été cartographiés par le passé, cette carte ne renseigne que sur l’import récent des batiments ainsi que l’ajout des références officielles.

Comment ça marche?

L’import se fait à partir d’un outil web, disponible sur https://buildings.osm.be/, en combinaison avec le programme JOSM. La page décrivant l’import est ici. Les instructions détaillées sont là. Je ne vais pas rentrer dans les détails du fonctionnement ici. Si vous êtes intéressés à importer des batiments, lisez ces pages et/ou contactez la communauté en Belgique, en particulier la “room element” (endroit de “chat”) dédiée à cet import.

Buts de l’import

Les buts de cet import sont multiples: d’abord remplir la carte de batiments existants, ensuite et surtout, avoir une base d’adresses à jour dans OpenStreetMap et enfin, avoir dans les batiments OSM la référence des batiments du PICC.

Ce dernier but a un intérêt pour la mise à jour future des batiments: quand le PICC évolue, on veut pouvoir rapidement déterminer si un batiment a déjà été importé dans le passé, et la meilleure façon de le faire est d’avoir son numéro de référence du PICC dans une étiquette OSM.

En outre, en faisant l’import, on peut détecter des différences entre le PICC et OSM qui vont pouvoir être remontées aux gestionnaires du PICC. Ces différences sont:

• des nouveaux batiments;
• des batiments ont été détruits;
• des batiments ont été modifiés.

La section “Dealing with errors in the source data” indique que faire dans ces cas.

Import des batiments à Neufchâteau

Un import des batiements a été réalisé sur une grosse partie de la commune de Neufchâteau: à savoir les sections de Neufchateau (ville), Longlier et Hamipré. Au total, 5883 batiments ont été importés avec l’outil buildings.osm.be et JOSM. Cela concerne des batiments avec adresses (maisons, appartements, batiments commerciaux) mais aussi des abris de jardins, des batiments agricoles, etc.

En faisant cet import, j’ai pu comparer le PICC et OSM, ainsi que les dernières images aériennes disponibles (printemps 2021). Le résultat:

• 76 nouveaux batiments, avec “source:geometry:ref=missing” (lien overpass): des nouveaux batiments, souvent avec un tag “building=construction” ou bien “start_date=20xx”, ou encore un tag “fixme=housenumber”, quand le numéro du batiment est inconnu.

• 17 batiments détruits, avec la clé “razed:building” ou “demolished:building” (lien overpass)

• un ou l’autre batiment modifié, pour lesquels j’ai omis de mettre l’étiquette “source:geometry=outdated”, mais qui était très peu nombreux.

La suite

Suite à des contacts avec le SPW, nous avons une liste de communes où le PICC a été mis à jour récemment. C’est sur ces communes qu’on peut concentrer l’effort. Toutefois, le plupart de ces communes ont déjà beaucoup de batiments dans OSM, et il est clair que réaliser un import de batiments du PICC là où des batiments OSM existent déjà prend beaucoup plus de temps que d’importer des batiments dans une zone vierge. La liste de ces communes, classées par le nombre d’adresses déjà existantes est:

	OSM building=*	OSM addr:housenumber=*	Point d’adresses ICAR	OSM/ICAR
Tenneville	2592	1346	1245	1.08
Villers-le-Bouillet	3877	2494	2461	1.01
Martelange	1581	820	831	0.99
Fauvillers	1756	1015	1036	0.98
Bièvre	2987	1549	1615	0.96
Faimes	2699	1432	1548	0.93
Bertrix	3608	2768	3765	0.74
Estaimpuis	3273	2302	4202	0.55
Ohey	1512	840	1850	0.45

Si vous êtes intéressé·e·s à réaliser des imports sur ces communes ou d’autres endroits, lisez la documentation, contactez la communauté et bonne cartographie!

Une connaissance cartographe m’a récemment transmis ce lien, d’un article daté de 2013 sur la cartographie participative et l’évolution récente de la cartographie en tant que discipline.

Il y a un paragraphe sur OpenStreetMap qui vaut la lecture. Et qui apporte sans doute un regard extérieur sur notre communauté (ce qui est rare). Voilà notamment un extrait:

“(…) le terme d’amateur peut difficilement être accolé au « mappeurs » d’OSM ! L’entreprise reste dominée par les développeurs informaticiens ou les geeks, passionnés du Web et des nouvelles technologies”

Même si l’accessibilité à OpenStreetMap s’est améliorée depuis 2013, je pense que ce jugement est toujours vrai. Bien sûr il y a probablement une majorité de contributeurs qui n’ont pas le profil “développeur” mais j’ai l’impression que plus les contributeurs sont impliqués dans OSM, plus ils correspondent à ce profil.

Note: this is an English version of my article in French here.

I’m a long time contributor of Mapillary and probably one of the top contributors in Wallonia. I have uploaded 59,7 k images to Mapillary, covering +1000 km. I have contributed of course with road imagery taken from my car, but also on the train and on several hundreds km of tracks and paths. While Mapillary has a good coverage in cities, it is usually poor in rural areas and I was happy to contribute on hiking trails, where I thought it has some potential for tourism applications. Beside Mapillary, I’m actively promoting OpenStreetMap as a hobby but also with my company as a GIS professional. With my colleagues or as OSM contributor, I made several trainings on OpenStreetMap to various publics: tourism agencies, urban planners, students, environmental agencies. At almost every OSM training / mapping parties, I also advocated for Mapillary, as an alternative to Google Street View, just as OSM is an alternative to Google maps. Two years ago, my colleague and I were invited as “open-source geo experts” to a meeting at the Walloon road administration to speak about the potential use of OSM and Mapillary for monitoring the 10k’s of signposts in the Walloon region (17,000 km²). So I was a also a advocate of Mapillary just like I’m a strong advocate of OSM, both in my local mapping community and professionally.

Was. Then I saw this news: Facebook acquired Mapillary. I had first mixed feelings. I took some days to think if I should stop contribute to Mapillary or not. I even still uploaded some guidepost images taken this weekend. But finally I took the decision to download all my images and delete my Mapillary account. Why?

I’m not against commercial uses of open-source software and data (this is even fully part of my job!), nor I’m a open-source ayatollah. I’m not rigorously against big corporations. It is a fact that Mapillary needs strong servers and that this costs money. BTW, I claim that the way that core infrastructure of OSM should be managed more professionally and that there are some limits when open-source projects are solely managed by a community. And I even recognize how Facebook is useful for strengthening social links in my rural community, like for organising events or for sharing objects between neighbours. But I won’t contribute to Facebook.

In my country like elsewhere, the most extremist parties are using Facebook to manipulate the opinion. The party that spend the most money last year for the elections in Belgium has alleged links to neo-nazis groups and have alleged neo-nazis members. Several members of this party were sued for sharing and promoting antisemitic and negationist ideas. No need to explain more that these parties are a direct thread to our societies. They don’t just advertise on FB: they use FB users data to make profiling and deliberately manipulate the opinion of large groups of people. This party spent at least 450k € from the beginning of 2020 (see https://www.facebook.com/ads/library/report/) on Facebook advertising. In my country, it is by far the largest party in terms of money spent on FB. I would not be surprised that this neo-nazi party is actually the first customer of FB in my country. And a company has always to listen to their customers. I don’t really blame FB for doing this. I’m pretty sure that most of FB employees are really annoyed that they favour neo-nazis political parties but how could they ignore a such big source of money? FB is a company: it has inherently no ethics. They need to make the server run, to pay their employees and to fund their stakeholders. IMHO, we must not only educate people to a better use of social networks but a strong public control (regulation, nationalization, whatever the way, …) on foreign companies such as FB is essential for our sovereignty and democracy.

Another reason for me, the core business of Mapillary is not to allow craft mappers to map things but is almost entirely geared toward monitoring road networks for the car industry.

Frankly, I’m not happy to give up with my commitment to Mapillary. This company have developed wonderful open-source tools to foster the participation to OSM. I just like to see a alternative to Mapillary re-born again, for the Common Good.

Note: I’m a not a native English writer and for this topic I’d be more comfortable writing in French, but I wanted to have a wider audience here. Please keep it in mind while reading.

OSM contributor for a while, I’m also working in a small company that use OSM data from times to times. To better promote OSM, I think we really need a better openstreetmap.org website. In this post, I’d like to suggest some points of improvement for the openstreetmap.org website.

My experience in promoting OSM

For some years, I’m doing a lot of promotion of OSM to various public, mostly as an OSM volunteer but also for my company. I have spoken about OSM to university students, municipalities representatives, the regional public sector (firemen, road network agency), associations (active in environment protection, local history, tourism) and some private companies (i.e., in electricity network management). At OSM-Belgium, we also set up a simple email address (community@osm.be) where any organisation which has a particular demand with respect to OSM can reach the community. Therefore I also get some requests from this address from companies or non-profit organisations for using OSM in their activities. Usually they only have a very vague idea of what OSM is, and it is not uncommon that they think of OSM as a software or another thing that OSM is definitely not (I’ve once read a student report where OpenStreetMap was compared to OpenLayers and LeafletJS!). So I’ve wrote plenty of emails presenting and explaining OSM, usually with links to some OSM Wiki pages, learnOSM, and/or overpass-turbo queries. Our incredible OSM ecosystem of software, maps, web services, projects is just amazing, but I sometimes feel frustrated that some core functionalities of OSM are actually not on openstreetmap.org.

Lack of integration of basic tools

For instance, last week it was my municipality which is interested in using OSM for their inventory of trash bins and benches. I’ve answered with sending an email with some links to overpass-turbo.eu with the ad-hoc queries, just to show them how well the trash bins and benches were already mapped in OSM. But why do we need to rely on overpass-turbo.eu for that? Why this strange name “overpass-turbo” ;-) ? If you are outside Europe, the “.eu” extension might just look weird (e.g., the recipient might reasonably think : Is it something funded by EU commission? Is it valid outside Europe?). If overpass is an API for OSM, why is there even no OSM logo or link on overpass-turbo.eu? I know that Overpass is an open source software and that there are other instances for this service (see here). But since overpass-turbo has become de facto the default OSM API, I think it really deserves to be on osm.org. for instance on overpass.osm.org or, even simpler, query.osm.org.

Overpass is not the only “OSM standard” that lacks integration with osm.org. While Nominatim and some routers have been progressively included on osm.org, the open source state-of-the-art geocoders solutions (Photon, OSMNames, …) are still not part of it. We should consider whether websites such as learnOSM, switch2osm, osmose.osm.fr and possibly others should be integrated to osm.org. Today, these websites are core elements of the OSM project, so they deserve to be recognized as core susbsystems of osm.org. Currently, the user interface of these websites is not harmonized with the one of osm.org. As a result, for the OSM beginner or for a potential user, it is hard to understand as a first sight if you can actually trust them or if they are really part of the OSM project.

You may think that stuffs like a web extension, lacking of user interface harmonization or the presence of a OSM logo or not are pure details but I think it is actually more important that we think, especially when we need to attract and retain people that have just heard about OSM. It is about encouraging newcomers to stay longer in the project. It is about trust in our project.

A better social network

As many of us, I’m passing a lot of time to monitor the activity of new contributors. For this, I can rely on a nice tool that was set up by the Belgian community, welcome.osm.be, that automatically detects all new users that make their first contributions in Belgium. I’m also monitoring the activities of my OSM “friends”, usually some active (or less active) mappers in my neighbourhood, to see how well we collectively progress on common or self-attributed goals toward a better OSM. But this “social” aspect of my OSM activities is not facilitated by the interface of osm.org. The pages osm.org/user/myusername lack many functionalities of a social network. There is a messaging interface which is not very user-friendly, and I’d love to see something more convenient, such as a geolocalised chat. Many times I had forgotten the exact spelling of a contributor username and, to my knowledge, there is no tool to search contributors by their username. BTW, finding active contributors in a given area is not easy: we can rely on this nice tool of Pascal Neis or this one from Martijn van Exel, but why the hell this is it not integrated to osm.org/user/myusername?

We all know maintaining the motivations of the OSM contributors is a key issue for the project. Tools that monitor the achievement of contributors, such as this one, are important for maintaining this motivation. It is true that some user rankings can have drawbacks such as people stupidly competing with others by pushing low-value changesets. We also have to seriously think about avoiding some hard-core contributors become toxicly addicted to contributing to OSM. At the same time, a friendly competition between mappers can help to have more useful and long-standing contributions. Again, why this kind of tool is not integrated to osm.org?

I’m usually not writing OSM-related stuff in my OSM diary. The editor for writing diary entry is not very user-friendly. It seems that we cannot insert images directly when writing posts, so you need to know how to host images or videos to write a post with some media. The editor is basic, with almost no text formatting. This is probably why many users prefer to post in their own blog instead on osm.org. This is not bad, but is quite a shame because the diary should be actually simpler than making a blog for the OSM contributors who have no blog. This adds another technological barrier for contributing to OSM, and my feeling and experience is that many enthusiast people about mapping does not feel comfortable enough with OSM because it is technically too hard to contribute and to participate in the project.

Lastly the overall user interface of osm.org does not look like a 2019-web interface. I don’t know if this is restricted to the French version of osm.org/user/myusername, but there are even some display bugs such as “ ” literally displayed on this page. The question of having a sober but fancy interface is is important, especially if we want to bring young contributors to OSM.

How to move forward?

I don’t know the technical or organisational implications of these suggestions. I even never filled an issue on https://github.com/openstreetmap/openstreetmap-website/, nor resolved a single one. Of course, it is easy to just complaining. I don’t want to blame the OSMF nor the current maintainers of osm.org: I’m sure they’ve made a huge work mostly on a voluntary basis, and I’d like to thank them for that. But since OSM is growing, I think, we, the contributors, and also the users of OSM, deserve a better front-door for our amazing project. This may probably need a huge work which, IMHO, should be community-deliberated and then subcontracted. This will let our community focused on what we can do the best: community building, crafting incredible applications with OSM and mapping.

In this page, a collection of infos about how useful is OSM for tourist operators. Mainly fed by weeklyOSM news.

• The tourism organisation of the Durmitor National Park in Žabljak, Montenegro, recommends the use of OSM on their mountain bike maps and also on their homepage with the wording “For successful orientation in the region of Durmitor and Sinjajevina, we recommend that you use OpenStreetMap and Open Cycle Maps which are regularly updated and new information is added every day” -> http://www.tozabljak.com/old/eKontakt.html

• A touristic map in UK: http://bexhill-osm.org.uk

• Touristic map tiles from Poland: https://en.mapy.cz/turisticka?x=5.5838643&y=49.7387028&z=14

• https://opentripmap.com/

Petit-compte rendu de cette rencontre, placée sous le thème OSM et (Grandes) Randonnées.

Cela fait un petit temps que l’idée d’une collaboration officielle entre OSM et l’association Sentiers de Grandes Randonnées (SGR) a été émise, à l’instar de la collaboration entre le Grote RoutePaden / OSM. Nous en avons rediscuté, sachant que le SGR est ouvert à rendre les traces des sentiers GR disponibles pour leur introduction dans OSM. Une introduction qui devra se faire en tenant compte de l’existant, étant donné que des relations partielles existent déjà pour cartographier les GR. On s’est d’ailleurs demandé si on pouvait faire une relation de relation.

Il y a eu quelques discussions autour des tags à utiliser pour bien caractériser les sentiers, la différence entre sentier (highway=path) et chemin (highway=track), qui est notamment conseillé sur cette page des conventions en Belgique. Une autre page utile est celle sur la manière de cartographier les itinéraires balisés. On a discuté aussi l’emploi du tag sac_scale pour caractériser la difficulté du sentier.

Deux outils utiles pour la cartographie en forêt, toutes deux disponibles dans les couches de l’éditeur JOSM :

• la couche Hillshade de la région wallonne, idéale pour les petites variations du relief : ruisseaux, chemins, levées de terres, aire de fauldes, etc.
• Les couches Strava, qui agrègent les traces GPS de milliers de coureurs à travers le monde. Elles sont malheureusement disponibles à une moins bonne résolution qu’auparavant depuis peu.

Enfin, deux responsables de Interface3Namur nous ont présenté le salon Evolutic où les contributeurs OSM tiendront un stand, et sans doute, une cartopartie. Evolutic est un salon destiné à faire découvrir le numérique au plus grand nombre, en particulier des publics qui n’y est pas habitué. OSM y aura donc toute sa place ! Le salon a lieu le vendredi 4 mai à Namur.

Compte-rendu et liens utiles suite à une agréable rencontre OSM à Namur ce 12 septembre 2017. N’hésitez pas à commenter s’il y a oubli.

Prochains événements

• Open day @ Fabspace, Liège, 10 octobre 2017
• FOSS4G.be, Bruxelles, 26 octobre 2017

Comment débuter dans OpenStreetMap (OSM)?

Une démo sur l’éditeur en ligne ID a été exposée. Lors de l’inscription, il est donc conseillé de suivre la démo proposée par l’éditeur ID. Sinon, ce lien explique relativement bien comment débuter sur OSM: http://learnosm.org/fr/beginner/start-osm/

La première source d’information sur OSM est le wiki. La page Belgique renseigne sur certaines conventions utilisées en Belgique.

OSM.be: son site web, ses membres, ses projets

–> http://www.osm.be/

Jonathan nous a présenté OSM.be (OpenStreetMap Belgium). OSM.be est liée à l’ASBL OpenKnowledge Belgium. Le but est devenir un “chapter” local de la fondation (internationale) OSM. Parmi les projets, retenons le cartographe du mois, l’étude sur la complétude du réseau routier et les tuiles OSM belges.

Qualité des données

Le niveau de qualité des données OSM est souvent questionné et il n’y a pas de réponse claire à ce sujet. En effet, il y a plusieurs facettes de la qualité des données géographiques:

• la complétude spatiale
• l’exactitude des infos attributaires
• la mise à jour
• la précision géométrique
• la précision/exactitude topologique
• etc.

Plusieurs études scientifiques ont évalué OSM. Il faut garder à l’esprit que l’état d’OSM évolue très vite et que les résultats d’une étude faite il y a un an sont probablement déjà périmés (en termes de résultats, pas de méthodologie).

Quelque système de qualité discutés:

• Système de détection d’erreur automatique osmose. Ce site reporte de nombreuses erreurs. Pouvoir corriger toutes les erreurs demande un niveau avancé dans la connaissance du modèle d’OSM. Ce site est néanmoins un bon moyen d’apprendre sur ce modèle.
• Il existe aussi un validateur dans l’éditeur JOSM.

Le géoportail et les géodonnées wallons

Vincent nous a présenté le géocatalogue et le géoportail wallon. Beaucoup de données sont disponibles pour l’édition dans OpenStreetMap:

• l’imagerie aérienne = orthophotoplans
• le PICC = projet de cartographie continue: contient les bâtiments et d’autres éléments “humain”
• les pentes (hillshade) : cfr http://www.nobohan.be/2017/08/29/relief-openstreetmap-pentes/

Les données Strava

La carte “heatmap” de Strava compile les traces des utilisateurs de l’application de course Strava. Cette donnée permet donc d’évaluer la fréquentation des chemins et de pouvoir suivre leur tracé (ce qui est souvent impossible par image aérienne en milieu couvert comme les forêts).

Cette donnée est disponible dans l’éditeur JOSM.

Voici un article de journal en anglais de Joost Schouppe sur la cartographie OSM avec Strava.

Mapillary et l’utilisation de Mapillary dans OSM

Mapillary est l’équivalent de Google StreetView en open data. C’est un projet indépendant d’OSM mais similaire: des contributeurs volontaires collectent des infos (ici des images de leur trajet, à l’aide d’un smartphone ou d’une caméra) et les envoient sur un serveur.

Les données de mapillary (càd des images de rues ou de chemins) peuvent être ensuite utilisées par les cartographes d’OSM pour ajouter des éléments à la carte, comme des panneaux routiers, le type de route, ou tout autre information visible sur l’image. Il existe un plugin Mapillary dans JOSM.

Comment éditer des circuits balisés (avec des relations)?

Ce point n’a pas été abordé. Qq infos malgré tout, car il y avait beaucoup de randonneurs, et OSM et randonnée font souvent bon ménage!

Les itinéraires balisés sous OSM

La communauté belge a éditée cette page pour guider la communauté de contributeurs OSM à cartographier les itinéraires balisés (GR mais aussi tous les autres itinéraires), ainsi que de lister les itinéraires balisés déjà cartographiés. Ainsi, le type de balisage utilisé (càd le signe, la couleur et forme du guidage) peut être renseigné pour chaque itinéraire (voir les conventions sur la manière de cartographier les “routes” ici. Une recherche rapide dans la base de données OSM montre qu’il y a déjà 702 itinéraires balisés de type “marche” (hiking) répertoriés en Wallonie sur OSM (http://overpass-turbo.eu/s/rrG).

L’intérêt d’OSM est que ces données sont utilisées pour différentes applications. Par exemple, les sites généralistes http://openwandelkaart.nl/, https://hiking.waymarkedtrails.org sont dérivés d’OSM. Des centaines d’applications mobiles de guidage GPS (MapsMe, OSMAnd, …) et de randonnées (par ex. Komoot, ViewRanger, MyTrails, etc.) utilisent également ces données.

Comment éditer des relations ?

Il y a un tutoriel ici pour JOSM.

Here’s my list of some scientific articles on OSM that I might read once retired:

• Schultz, M., Voss, J., Auer, M., Carter, S., & Zipf, A. (2017). Open land cover from OpenStreetMap and remote sensing. International Journal of Applied Earth Observation and Geoinformation, 63, 206-213.

• Neis, P., & Zipf, A. (2012). Analyzing the contributor activity of a volunteered geographic information project—The case of OpenStreetMap. ISPRS International Journal of Geo-Information, 1(2), 146-165.

• Neis, P., & Zielstra, D. (2014). Recent developments and future trends in volunteered geographic information research: The case of OpenStreetMap. Future Internet, 6(1), 76-106.

• Senaratne, H., Mobasheri, A., Ali, A. L., Capineri, C., & Haklay, M. (2017). A review of volunteered geographic information quality assessment methods. International Journal of Geographical Information Science, 31(1), 139-167.

• Barrington-Leigh, C., & Millard-Ball, A. (2017). The world’s user-generated road map is more than 80% complete. PloS one, 12(8), e0180698.

• Geographic Biases are ‘Born, not Made’: Exploring Contributors’ Spatiotemporal Behavior in OpenStreetMap, http://www.brenthecht.com/publications/group2018_spatialfootprints.pdf