Note: there’s an English version of this there.
Depuis fin 2019, le style cartographique OpenArdenneMap est mis à jour suivant un cycle semestriel de livraison! OpenArdenneMap est un style cartographique open-source pour des cartes topographiques sur base des données OpenStreetMap. La livraison “hiver 2022-23” vient de sortir.
Cet hiver, OpenArdenneMap passe à QGIS
OpenArdenneMap a été initialement développé comme un style cartographique avec l’importateur imposm et un style cartoCSS dérivé de OSMBright. Plus tard, l’importateur osm2pgsql a été utilisé à la place de l’importateur imposm. A partir de cette livraison, le style OpenArdenneMap est également disponible dans QGIS, en utilisant le même importateur osm2pgsql pour construire les couches de la carte.
Bien qu’il nécessite toujours une base de données PostGIS, le style QGIS est beaucoup plus simple à utiliser pour composer des cartes à différentes échelles que le style Mapnik/cartoCSS. Il est également beaucoup plus simple à mettre en place.
Les outils utilisés pour réaliser des cartes ont une certaine influence sur le style cartographique lui-même. Le but de ce support QGIS est de reproduire le même rendu que les cartes produites avec le style Mapnik/cartoCSS, mais les 2 solutions ne sont pas 100% équivalentes.
Un extrait OAM avec Mapnik
Un extrait OAM avec QGIS
Voici quelques observations clés lors du passage de ce style de Mapnik/cartoCSS à QGIS.
Des règles beaucoup plus simples pour la mise à l’échelle dans QGIS
QGIS supporte l’utilisation d’unités géographiques pour définir la taille des symboles (mètres à l’échelle, unités cartographiques), alors que Mapnik/cartoCSS, à ma connaissance, ne traite que des unités en pixels. Cela signifie que, dans QGIS, vous pouvez définir une taille qui sera fonction de l’échelle de la carte. Ceci est vraiment utile pour les cartes à très haute échelle (c’est-à-dire > 1:10000), où certains éléments tels que la largeur des routes peuvent prendre leur taille “réelle” sur la carte. Pour obtenir le même effet dans Mapnik, nous devons définir des largeurs différentes pour chaque niveau de zoom.
Utilisation des variables QGIS
Un avantage clé de l’utilisation de Mapnik et de cartoCSS est qu’il est possible de définir des variables qui sont utilisées tout au long du projet, typiquement pour des variables de taille et les couleurs. Heureusement, il y a aussi moyen de définir des variables dans un projet QGIS (dans Projet > Propriétés > Variables) et les utiliser dans les définitions de style.
Utiliser des tables PostGIS filtrées par rapport aux couches SQL
Les mêmes couches utilisées dans Mapnik ont été utilisées comme couches QGIS. Souvent, ces couches ne sont pas seulement des filtres appliqués à une table “planet_osm_points|lines|polygones” mais elles effectuent une transformation des données. Par exemple, la couche pour les libellés des plans d’eau est la suivante :
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 chemin,
eau 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 > 10000qui combine les lignes de planet_osm_line avec des lignes créées à partir de planet_osm_polygon en utilisant une suite de fonctions PostGIS (ST_ApproximateMedialAxis, etc.).
Ces requêtes PostGIS sont simplement définies comme des couches dans le gestionnaire de base de données QGIS et ensuite ajoutées à la carte.
Cependant, pour certains problèmes de performances, il semble plus facile de filtrer directement à partir d’une couche PostGIS de la BD plutôt que de définir une nouvelle couche SQL avec le gestionnaire de BD. Dans la mesure du possible, les couches du projet QGIS sont donc des tables PostGIS complètes qui sont juste filtrées pour les éléments requis.
Problèmes restants
Le travail de portage du style Mapnik vers QGIS n’est pas tout à fait terminé, il reste quelques problèmes non résolus et/ou limitations de QGIS par rapport à Mapnik.
Par exemple, je n’ai pas trouvé comment éviter le chevauchement/la répétition de symboles ou d’étiquettes proches. Il s’agit d’une fonctionnalité essentielle de Mapnik, et d’un problème si commun mais aussi si difficile en cartographie : comment empêcher les symboles de se chevaucher ou de se répéter à courte distance, que ce soit dans la même couche ou dans des couches différentes ? La même chose s’applique aux labels. Un exemple est l’affichage multiple de symboles de table de pic-nic, souvent groupées dans un parc, et qui apparaissent côte à côte dans la carte.
Pour conclure
Ce travail de passage de Mapnik à QGIS n’est pas terminé. J’ignore encore quel logiciel sera privilégié à l’avenir pour OpenArdenneMap. A noter qu’une grande partie du travail cartographique est appliqué directement aux données via les requêtes PostGIS, et est donc commun aux 2 solutions. Automatiser ce travail cartographique sur base des données OSM (généralisation automatique, déplacement, …) est un domaine encore peu exploré aujourd’hui.
