De la donnée à la carte : comment créer une carte Web en 2020 ?

Depuis l’arrivée de Google Maps en 2007, les cartes interactives en ligne sont devenues de plus en plus populaires pour les utilisateurs et pour les développeurs Web. Il est aujourd’hui rapide de pouvoir produire des cartes Web à travers des outils comme Google My Maps, Mapbox Studio, CARTO ou ArcGIS Online par des interfaces visuelles (GUI) pour des non développeurs, ou via des API pour les programmeurs. Cependant, ces solutions ont des contraintes particulières, principalement liées au coût de stockage des données et à la performance de la visualisation avec de forts volumes d’informations géographiques. Que faire en 2020 pour créer une infrastructure de données géographiques pour le Web?

Les services Web

Trois composants sont nécessaires pour créer une carte :

• une base de données;
• un moteur de carte;
• une librairie pour l’affichage cartographique.

En 2010, la plupart des développeurs tournés vers l’open source utilisait les piles suivantes :

• PostGIS comme base de données;
• MapServer ou GeoServer pour servir des tuiles;
• OpenLayers (puis Leaflet) pour afficher les services WMS (Web Map Service) et WFS (Web Feature Service) distribués par les moteurs ci-dessus.

Ce type d’infrastructure était stable, abordable, interopérable (il suffisait de remplacer une brique dans l’infrastructure pour s’adapter à plusieurs clients). Par contre, les standards WMS et WFS avaient de grandes lacunes… 

Le WMS diffuse les tuiles sous forme d’images (raster). Le serveur doit donc calculer et dessiner chaque image côté serveur (backend). C’est l’administrateur du serveur de tuiles qui a le contrôle sur le style des données affichées. Quand l’utilisateur voulait se renseigner sur un élément sur la carte en ligne, le client envoyait la requête au serveur qui revenait avec la réponse sur les données derrière l’élément…En plus de lenteur d’affichage et de temps d’accès, il était Impossible dans ce cadre d’avoir de l’interactivité poussée ou de calculer des statistiques à la volée.

Le WFS (en format XML ou GeoJSON) avait pour sa part l’avantage d’afficher les éléments vectoriels ainsi que d’envoyer toutes les données attributaires côté client mais le temps de service était extrêmement long et les navigateurs étaient incapables d’afficher plus de 1 000 éléments sur une carte.

C’est donc une combinaison de WMS / WFS qui restait la marche à suivre la plus courante … jusqu’à l’apparition de plusieurs éléments qui, mis ensemble, créé la magie d’afficher et interpréter des millions de données géographiques.

Le WebGL

Le WebGL permet d’afficher, de créer et de gérer dynamiquement des éléments graphiques complexes en 3D dans la fenêtre du navigateur Web d’un client (source : https://fr.wikipedia.org/wiki/WebGL). Depuis l’arrivée du HTML5, l’ensemble des fureteurs supportent ce standard qui permet à une librairie graphique de dessiner rapidement en 2D et 3D.

Au niveau cartographie Web, les librairies JavaScript ont donc évolué pour utiliser la puissance des cartes graphiques des clients et du WebGL notamment Mapbox GL JS, Deck.gl (ou leurs interfaces associées Mapbox Studio et Kepler.gl).

Les tuiles vectorielles

En parallèle des librairies WebGL qui permettent de dessiner rapidement des éléments graphiques, plusieurs ont travaillé sur des formats de diffusion de données qui permettaient de transférer rapidement les données du serveur vers le client. Les WMS et WFS étant trop lent, la compagnie Mapbox a alors développé le format .mvt (Mapbox Vector Tiles). Le MVT peut tirer profit du format protocol buffer développé par Google. Terminé les long temps de chargement et aller-retour incessant vers le serveur. Les tuiles vectorielles augmentent la vitesse d’affichage des WMS et sont capables d’interroger des millions d’entités (contrairement à quelques centaines pour le WFS). 

Pour diffuser ces tuiles, une multitude de nouveaux joueurs sont apparus pour servir et consommer des tuiles vectorielles. Le dépôt Awesome Vector Tiles permet de recenser les principaux outils qui tirent profits de ces technologies : https://github.com/mapbox/awesome-vector-tiles

Mais que faire avec des données dynamiques comme des données transactionnelles?

PostGIS + MVT

En 10 ans, les solutions disponibles serveurs et clients ont grandement évolué pour offrir plus de flexibilité et de performance. De nouveaux joueurs SQL ou NoSQL tels que MongoDB ou BigQuery sont apparus sur le marché mais force est de constater que rien n’arrive encore à la cheville de PostGIS pour les données géographiques (https://ual.sg/post/2020/07/03/a-comparison-of-spatial-functions-postgis-athena-prestodb-bigquery-vs-redshift/). Ce système de base de données relationnel spatial reste en avant en termes de composants disponibles pour le stockage, l’analyse et la diffusion de données spatiales. C’est principalement parce que la communauté de développeurs de PostGIS a fait évoluer le produit en même temps que l’avènement des tuiles vectorielles et du WebGL. 

C’est grâce à la fonction ST_AsMVT (https://postgis.net/docs/ST_AsMVT.html) que notre serveur de base de données favori est capable de servir les données dans le format souhaité. Et quand celui-ci est bien configuré en utilisant différents nœuds sur des environnements cloud performants (merci Kubernetes), on est capable de créer des cartes et d’analyser en temps réel plusieurs millions d’entités géographiques, sur n’importe quel ordinateur, tablette ou téléphone!

C’est la véritable magie qui s’opère ici.

Anagraph, un studio d’innovation en intelligence géographique

Chez Anagraph, nous testons, comparons, analysons scrupuleusement les dernières tendances en matière de Webmapping. Nous arrivons aujourd’hui au constat qu’il n’est pas nécessaire de “mettre en cache” les données par des processus de traitement de données (ETL) fastidieux et long. 

Rappelons qu’en 2010, la plupart des développeurs géospatiaux utilisait Mapserver ou Geoserver pour se brancher à PostGIS et servir des WMS et WFS vers OpenLayers. Il était conseillé de “cacher” les données raster pour optimiser l’affichage grâce à des outils comme GeoWebcache ou Tilecache. Il est aujourd’hui possible de procéder à ce même principe pour servir des données tuilées vectorielles. On peut le faire dans des fichiers bruts avec une arborescence de dossier ou dans des bases de données du type SQLite. Ainsi, l’utilisation de Tippecanoe pour traiter des GeoJSON et les transformer en MBTiles peut être une piste intéressante quand les données sont statiques. Mais il reste que PostGIS, bien configuré, couplé avec un serveur de tuile léger tel que Martin ou PGTileserv est capable de diffuser des données aussi rapidement que des tuiles mises en cache en MBTiles!

Conclusion

Il est facile d’utiliser Google Maps ou Mapbox pour cartographier des actifs (store locator,…) ou réaliser des cartes choroplèthes (cartes électorales, …) quand les volumes de données restent faibles (moins de 1 000 entités). Quand ce volume augmente (voire de beaucoup!), oubliez les  WMS, WFS ou GeoJSON et passez aux tuiles vectorielles! Elles sont maintenant supportées par tous les joueurs spatiaux propriétaires ou ouverts (ESRI a accepté rapidement le format MVT dans ArcGIS Server ou ArcGIS Online). Et même si ce volume atteint des millions d’enregistrements, PostGIS reste le meilleur choix pour conserver une infrastructure performante, légère et répandue!

N’hésitez-pas à contacter notre équipe d’expert pour vous accompagner dans la transition de votre infrastructure qui saura mettre en valeur vos données pour le bien de vos utilisateurs!