Dessiner une carte
Juillet j’écrivais à propos d’adaptations à panikweb (le module qui fait tourner les sites de radio panik et radio esperanzah!) et j’incluais un vague « (surtout que d'autres projets sont à l’horizon) ». La réalité juillet c’était des inondations, ça a mis d’autres priorités mais aujourd’hui, sans être encore public, ça a repris et comme on en est à une page « À propos » on peut se dire que ça va bientôt être prêt.
Sur cette page il y a suggestion de mettre une carte pour montrer la localisation et paf lien Google Maps et intégrer ça ce serait totalement moche, déjà Google en soit, mais aussi d’un point de vue style ça fait une carte pleine de marqueurs, je n’ai vraiment rien contre Woopy’s Snack mais ça n’a pas de rapport. Heureusement avec OpenStreetMap on a un projet collectif de cartographie et si le rendu par défaut reprend quand même trop d’infos il y a tout à fait moyen d’obtenir une carte allégée. « Tout à fait moyen ».
Direction la page des tuiles sur le wiki d’OpenStreetMap pour essayer d’en trouver une qui ne soit pas chargée et excellent dans la liste il y a Stamen Toner qui est légère et qui surtout a un style noir et blanc qui s’intégrera parfaitement au site.
C’est vraiment sympa mais il est annoncé qu’il n’y a pas de mise à jour des données, c’est quand même assez dommage et comme j’ai à peu près sous la main une base de données à jour je me dis qu’il doit sans doute y avoir moyen d’y brancher le style de tuiles et ainsi obtenir des tuiles actualisées.
Il y a des instructions d’installations mais elles ne correspondent pas aux logiciels que j’ai sous la main, ça utilise TileMill qui s’annonce comme "modern map design studio" alors que je voudrais juste brancher ça sur mod_tile, un module web (apache) de génération de tuiles.
Je plonge et m’égare un peu dans le millefeuilles technologique de la carto mais pour faire très court de ce que j’ai compris on a mapnik pour faire le rendu, qui part d’un fichier XML, comme ce fichier est imbuvable, il y a un projet CartoCSS qui part d’autres fichiers qui ressemblent un peu à des CSS pour le générer.
Il y a un tas d’outils écrits en JavaScript, pas packagés pour Debian, mais dans Debian on a quand même la bibliothèque mapnik et les modules Python associés et nik4 qui est un petit programme Python permettant de faire le rendu.
Ça ne marche pas. Ça ne démarre même pas.
~ $ nik4 Traceback (most recent call last): File "/usr/bin/nik4", line 33, in <module> transform_lonlat_webmerc = mapnik.ProjTransform(proj_lonlat, proj_web_merc) RuntimeError: Cannot initialize proj_transform for given projections without proj4 support (-DMAPNIK_USE_PROJ4): '…'
Donc nik4 dépend de python-mapnik, qui vérifie que mapnik a été compilé avec la capacité d’utiliser proj4 qui est une bibliothèque pour gérer les projections cartographiques, qui est bel et bien disponible dans Debian mais dans une version qui a retiré les bouts dépréciés utilisés par mapnik ce qui fait qu’elle n’est pas détectée (passage dans un fichier SConstruct qui tente de compiler un bout utilisant proj_api.h qui est le fichier qui n’existe plus) et comme surprise pouvoir transformer des coordonnées apparait essentiel pour faire du rendu de carte, on est bloqué là .
À peu près à ce moment j’abandonne l’idée de pouvoir générer en local quoique ce soit (je pourrais installer mod_tile mais ça amène apache, ça entre en conflit avec nginx qui tourne déjà , donc je ne poursuis pas) et donc ça sera moins pratique et c’est toujours moche mais je me laisse aller à me dire que tant pis je vais travailler directement sur le serveur.
Comme le code vu plus haut ne pouvait pas tourner et que dans le tas je ne trouve pas trop comment juste produire un fichier mapnik.xml de style, je cherche ailleurs. Il y a un dépôt mapnik-styles qui contient un style "toner-lite" qui pourrait être une base mais c’est juste un fichier abandonné là il y a sept ans et c’est 10000 lignes dans un fichier XML. Je tente quand même à grand coups de remplacements sauvages mais ça échoue lamentablement sur des questions de base de données.
Interlude sur mapnik.xml : il y a tout dans ce fichier, aussi bien la couleur d’une route que les paramètres de connexions à la base de données et les requêtes à y effectuer.
<Parameter name="table"><![CDATA[(
SELECT
name,
type,
geometry,
area
FROM osm_green_areas
WHERE geometry && !bbox!
) AS _
]]></Parameter>
C’est un peu mieux réparti côté CartoCSS où il y a un fichier qui va contenir les informations de la base de données et faire référence à des styles posés dans d’autres fichiers mais ça n’est quand même pas la gloire, il reste un mélange paramètres de connexion et requêtes.
Et ces requêtes, elles dépendent du contenu de la base de données et celle-ci change selon les projets, qui peuvent venir avec un fichier d’adaptations pour créer leurs propres tables pour faciliter derrière les requêtes. L’intention est louable mais ça rend très compliquée l’utilisation d’une même base de données pour différents styles, par exemple toner-lite.xml a besoin d’une table "planet_osm_line_z11" :
"planet_osm_line_z10": {
"source": "planet_osm_line_z11",
"sql_filter": "highway in ('motorway', 'trunk', 'primary', 'secondary')",
"tolerance": 76
},
Petite ambition à ce moment de partir de zéro mais ça semble le truc que personne ne fait et zéro info et bravo j’ai réussi à avoir une tuile bleu océan mais j’en reste là . La conclusion du point précédent c’est que je dois partir du style qui tourne actuellement sur le serveur, pour avoir un style qui correspond à la structure de la base de données.
C’est un style basé sur HDM-CartoCSS et je télécharge donc le dépôt et bien sûr ça ne fonctionne pas parce que même affaire il y a eu des évolutions côté base de données, c’est mineur et ça s’ajuste rapidement.
Après tout un tas de fausses pistes voilà enfin le moment où je peux modifier le style et obtenir des tuiles adaptées.
HDM-CartoCSS c’est un projet pour créer des cartes utiles dans des moments de catastrophes humanitaires, on y trouve donc des informations essentielles comme les lignes à haute tension et les groupes électrogènes, les puits et citernes, etc. C’est assez bien rangé et pour mes besoins vraiment facile de simplement retirer les points d’intérêts et autres.
Par contre il y a des particularités dans le style Toner, l’utilisation de motifs sur certaines zones, plutôt que des couleurs unies, et ça se prête assez mal, pas possible de remplacer
@park: #D0DCAE;
par quelque chose qui ferait utiliser un motif plutôt que la couleur unie, et la suite est structurée selon une répétition du style,
[type='park'] { polygon-fill: @park; }
[type='garden'] { polygon-fill: @park; }
[type='village_green'] { polygon-fill: @park; }
alors que j’aurais plutôt besoin d’un style unique qui s’appliquerait aux différents types de parcs, jardins, etc. Ça se fait facilement :
[type='park'],
[type='garden'],
[type='village_green'] {
polygon-fill: #FFFFFF;
polygon-pattern-file: url(./patterns/halftone2.png);
polygon-pattern-alignment: global;
}
mais on perd le contrĂ´le via un fichier central des styles.
Pas nécessairement des plus propres côté code mais vite fait ça donne un rendu satisfaisant et je peux passer à un autre sujet majeur, les routes. C’est étonnamment galère, principalement je pense parce que le style Toner a une utilisation exclusive du noir et blanc, dépend notamment très fort de l’épaisseur des traits, et du choix entre afficher juste un gros trait, ou afficher la route et les traits sur le côté.
Pour comprendre comment sont dessinées les routes, j’ai eu du mal à tomber sur cet article Navigating the Maze (part 1) qui reprend un schéma très utile avec la manière dont sont nommées les différentes parties du rendu. (l’auteur est Christoph Hormann et il y a quantité de choses intéressantes sur la technique mais aussi sur l’organisation de la fondation OpenStreetMap).
Avec ces informations, j’ai pu poser les derniers éléments essentiels pour obtenir un rendu me satisfaisant, ça donne ça :
Comme différence importante il y a le placement des noms de route, qui est bien mieux géré dans le style d’origine, en posant le libellé à côté de la route, il y a aussi une meilleure adaption du style aux autres niveaux de zoom, particulièrement les niveaux moins élevés (où se grisent les routes moins essentielles) mais également les niveaux plus élevés (où les routes changent de mode pour avoir les bords tracés et le fond blanc).
C’est assez dommage d’avoir à tant galérer avant de pouvoir commencer à travailler le rendu et publier mon petit fork du style ne va rien changer à ça mais il est quand même évidemment disponible, hdm-toner-cartocss.
Je n’y passerai sans doute pas beaucoup plus de temps.
Et merci aux contributeur·ices d’OpenStreetMap, c’est quand même top de pouvoir faire tout ça.