Raphaël Bres - Parc national des Ecrins / Février 2020
Le Parc national des Écrins est organisé avec un siège à Gap et 7 antennes sur le territoire, localisées dans des maisons de parc dans les vallées. Plus de 40 agents manipulent des données géographiques avec le logiciel libre QGIS. Le SIG est organisé avec des couches de référence partagées en lecture et des données thématiques créées par les agents.
Le Parc national des Écrins souhaite trouver un format de données pour remplacer l’ensemble des couches vectorielles au format shapefile. La solution idéale de se baser sur une base de données PostGIS a été écartée à cause de l’éclatement des 8 sites de travail et de leur débit internet faible et irrégulier.
Nous avons donc étudié deux alternatives que sont le GeoJSON et le GeoPackage. Commençons par définir ces trois types de données avant de présenter les résultats de tests de performance et de conclure sur le format retenu.
Le format shapefile est le format le plus démocratisé de nos jours dans l’utilisation des SIG. Il a pendant très longtemps été la recommandation principale de l’OGC. Cependant, ce format dispose de plusieurs inconvénients comme la création de plusieurs fichiers pour une même couche (SHP, DBF, SHX, PROJ). De plus, ce format est réputé très lourd et est limité à 2 Go de stockage par fichier shapefile.
Le format GeoJSON est un format non préconisé par l’OGC pour traiter l’information géographique mais est largement utilisé pour du développement web à travers des librairies comme Leaflet, OpenLayers ou MapboxGL. Il est dit comme très performant concernant de petits jeux de données mais a de grosses limites lorsque le nombre de données augmente.
Le format GeoPackage est le format le plus récent recommandé par l’OGC pour les traitements sur les SIG. Il est par exemple le format de données par défaut de QGIS3. Ce format est basé sur une base de données SQLite qui est censée accélérer les requêtes spatiales et le temps d’affichage de la couche, principalement quand on a de gros volumes de données. Sa principale contrainte vient du fait que sa structure n’est pas adaptée à une mise à disposition sur un serveur.
Voir http://switchfromshapefile.org pour plus de détails sur ces 3 formats.
Maintenant que nous avons présenté les données, nous allons tester l’ensemble de ces formats pour savoir lequel est le plus performant. Pour cela, nous allons prendre un fichier « léger » avec environ 250 données et un fichier « lourd » avec plus de 600 000 données. Nous allons d’abord comparer la taille de ses fichiers avant de charger dans QGIS 10 fois chaque fichier afin d’avoir des données précises sur le temps de chargement de chaque format.
D’abord, évoquons la taille de chaque fichier selon son format. Ici, nous allons définir quel format de données prend le moins de place à stocker.
Tableau de comparaison des tailles de chaque fichier
GeoJSON | SHP | GPKG | |
---|---|---|---|
Fichier léger | 60Ko | 50Ko | 135Ko |
Fichier lourd | 400Mo | 2Go | 200Mo |
Dans ce cas, nous voyons que le format Shapefile est beaucoup plus volumineux que les autres lorsque l’on utilise un fichier lourd. La taille du fichier lourd est divisée par 5 pour le même fichier en GeoJSON et est divisée par 10 pour le format GeoPackage. Par contre, pour les fichiers légers, nous voyons que le GeoPackage est 2 fois plus lourd que les autres du à sa structure complexe. Dans ce cas, le shapefile est le fichier le plus léger. Pour conclure sur le volet de la taille, vu que le PNE dispose de gros fichiers de données, sur la faune et la flore par exemple, nous privilégions le GeoPackage du point de vue de la taille des fichiers.
Maintenant, nous passons au test dans QGIS. Il est important de noter que les temps présentés ici peuvent varier d’une machine à une autre. Le test compare le temps d’ouverture (en secondes) d’un fichier léger et d’un fichier lourd, stocké en local sur le PC et sur le serveur de fichiers. On présente ici le ratio entre deux temps de chargement.
Résultats de 10 itérations pour différents formats
Taille du fichier | Fichier léger | ||||||
---|---|---|---|---|---|---|---|
Local/Serveur | Local | Serveur | |||||
Extension | GeoJSON vs SHP | GeoJSON vs GPKG | SHP vs GPKG | GeoJSON vs SHP | GeoJSON vs GPKG | SHP vs GPKG | |
Ubuntu | Ouverture | 1,150 | 0,744 | 1,545 | 0,813 | 0,234 | 3,477 |
Windows | Ouverture | 0,706 | 1,050 | 0,672 | 0,905 | 0,927 | 0,976 |
Ecriture | Instantané |
Interprétation : Sur un système Ubuntu, pour ouvrir un fichier, le format SHP est 1,15 fois plus rapide que le format GeoJSON.
Taille du fichier | Fichier lourd | ||||||
---|---|---|---|---|---|---|---|
Local/Serveur | Local | Serveur | |||||
Extension | GeoJSON vs SHP | GeoJSON vs GPKG | SHP vs GPKG | GeoJSON vs SHP | GeoJSON vs GPKG | SHP vs GPKG | |
Ubuntu | Ouverture | 0,908 | 2,353 | ||||
Windows | Ouverture | 7,450 | 31,561 | 4,236 | 3,568 | 4,267 | 1,196 |
Ecriture | 37,046 | 58,950 | 1,591 | 0,190 | 2,120 | 11,129 |
Nous constatons que le GeoPackage présente des avantages indéniables quand on utilise un très grand nombre de données. Principalement en écriture de données, il est 11 fois plus rapide que le format shapefile alors que le format GeoJSON est lent à l’ouverture. Le problème majeur du format GeoJSON reste son inefficacité sur un poste avec un système d’exploitation Linux où l’ouverture d’un gros fichier de données entraîne le plantage de QGIS.
Pour conclure cette analyse, le format Shapefile peut être laissé de côté par rapport au format GeoPackage qui dispose de meilleures performances et prend moins de place lorsque l’on souhaite stocker de gros fichiers.
Pour automatiser la conversion de tous nos fichiers SHP en GeoPackages, j'ai développé un script Python dédié.