Les technologies dans le domaine du webmapping progressent à grande vitesse. Je me suis intéressé aux performances du rendu vectoriel  de données provenant directement d’une base de données.

L’objectif ici était de trouver le moyen le plus efficace pour afficher des données vectorielles de sur Leaflet, allant de la récupération des données jusqu’au dessin. Concernant la technologie d’affichage, un petit test a vite montré la supériorité du Canvaspar rapport au SVG. Il serait néanmoins intéressant de reproduire cela avec le WebGl qui arrive à grand pas dans notre monde du webmapping (MapboxGL, Openlayers 3, Google Maps…) . De même l’utilisation d’une base de données s’est montré plus veloce que l’utilisation d’un fichier JSON.

Les données étaient donc stockées dans MySql, et pour ce teste, deux jeux de données représentant les communes de l’Isère ont été utilisées.:

• un petit provenant de Geofla de l’IGN (7k coordonnées)
• un plus  gros venant d’Openstreetmap (200k coordonnées).

J’ai d’abord fait l’hypothèse que le moteur de stockage de Mysql pouvait influer sur les performances, mais en fin de compte,  je n’ai pas vu de réelles différences entre InnoDB et MyIsam. Il est donc préférable d’utiliser MyIsam qui prend en charge les index spatiaux.

Pour mes premiers tests, j’ai commencé par convertir les données en GeoJson côté serveur.

WKB to Geojson (coté serveur via geoPHP)

D’abord sans réinventé la roue en utilisant la librairie PHP GeoPHP en lui fournissant du WKB.Le GeoJSON obtenu pèse 6.5Mo (2.5Mo gzippé). Mais le délai entre la requête et la réponse était assez long, trop long.

WKT to Geojson (coté serveur)

Pensant que cette lenteur venait  de la transformation du WKB à la sauce Geojson, j’ai donc créé une petite classe PHP la plus simple possible pour faire cela à partir d’un WKT.

Le GeoJson étant identique à au-dessus, le poids est le même. Mais les différences n’étaient pas flagrantes.

WKT to Json  (traitement coté client)

C’est ce qu’il se passe entre l’envoi de la requete et l’obtention du résultat qui est le plus chronophage. Partant de ce constat,  j’ai donc changé d’approche en utilisant le client et JavaScript pour convertir les données envoyées par le serveur directement en Json sans autre traitement côté serveur (le champ géométrie en WKT).

Le résultat de la requête pèse alors 7Mo (2.9Mo gzippé)

Ensuite, pour rendre le WKT compatible Leaflet, j’ai utilisé la librairie Wicket.On on gagne environ 30% en termes de performance tout en sollicitant moins le serveur.

Géométrie encodée à la façon Google (traitement coté client)

Pour faire encore mieux, il faudrait alléger la géométrie que l’on reçoit du serveur, car elle représente l’essentiel du poids du résultat. Je fais donc écho àun article qui a tout juste un an où je m’étais intéressé à la façon dont Google procède pour transmettre ses données géométriques.

J’ai donc créé un nouveau champ dans ma base où j’ai stocké la géométrie encodée à la sauce google grâce a ce petit script PHP  et en utilisant cette classe.

Côté LeafLet, j’ai utilisé cette classe pour décoder la géométrie.

Et là le poids du résultat est divisé par 10! -0,6Mo (0.4Mo gzippé)-. L’efficacité rendue est donc nettement accrue tout en réduisant les ressources et la bande passante du serveur.

A noter, une fois n’est pas coutume, IE11 met deux fois moins de temps à afficher le résultat que Chrome ou FF…