Pasq.fr

Parce-qu'il y a forcément du sens à tout ce bordel !

FlatGeoBuf : soyons binaire !

Rédigé par Alain 2 commentaires
flatgeobuf

Aucun lien avec le genre, juste un format qui, parait-il, fait gagner de la place et du temps.

Vous connaissez cette sensation, lorsque que tout le monde parle d'une série que vous ne connaissiez même pas, ou quand vous avez découvert une musique et que vous vous rendez compte que tout le monde la connait depuis 6 mois. Et bien, je viens de vivre cela avec FlatGeoBuf. Je viens de découvrir ce format et revisitant la page que j'ai traduit  : shapefile-doit-mourir et en relisant le site original : http://switchfromshapefile.org/).

FlatGeoBuf

Qu'est-ce que c'est : FlatGeobuf est un codage binaire optimisé pour les vecteurs, basé sur Flatbuffers, qui met l'accent sur les performances de lecture/interrogation en exploitant un index spatial Packed Hilbert R-Tree, qui permet un filtrage spatial rapide par boîte englobante. Les performances de FlatGeobuf ont contribué à en faire l'un des formats choisis pour le streaming de données spatiales via HTTP / "le nuage".

FlatGeobuf est un format ouvert, basé sur des normes, indépendant de la plate-forme, portable, autodescriptif, performant et compact pour le transfert d'informations géospatiales.
FlatGeobuf est actuellement pris en charge par GDAL 3.1 et QGIS 3.16. Une implémentation TypeScript/JavaScript de référence est disponible et peut être utilisée par exemple dans OpenLayers et Leaflet.
Il est recommandé FlatGeobuf comme remplacement de Shapefile pour les scénarios où les performances sont critiques et les intégrations de système à système. En raison de ses capacités de streaming, il convient également comme format de sortie WFS alternatif et est disponible comme extension officielle de GeoServer et documenter dans Mapserver.

De mes yeux

Alors, oui, cela parait performant. Mais si je teste avec mes moyens, est-ce que je trouve la même chose ?

Alors prenons une couche simple : la couche des communes de l'admin-express de 22h43 en provenance de Babylone, pardon, juste de mars 2022.

Ma config de machine est la suivante (oui, j'ai un vieux pc d'occaz !) :

config PC

Je suis sous MX-linux 21.1, avec QGIS 3.22 installé depuis flatpaks. Configuration de base de QGIS (pas d'accélération graphique, simplification par défaut).

Je charge la couche .SHP de l'IGN dans QGIS, et j'exporte en geopackage, GeoJson, flatgeobuf, et intégration dans POSTGIS (POSTGRES 13 / POSTGIS 3 - aucune modif des config par défaut de ma part) via gestionnaire de base de données.

Je n'ai eu aucune erreur à la création, et je n'ai pas relevé de vitesse, mais rien ne paru exagérément long (sauf GeoJSON). J'en profite pour signaler que je ne suis pas un spécialiste des tests, je vous donne les chiffres bruts. Si vous voyez un biais, une erreur, ou un truc bizarre, dîtes le en commentaires.

La taille des fichiers

Si on additionne pour le shp : 401 Mo.

Dans POSTGIS  : 

POSTGIS

  1. POSTGIS
  2. MATCH NUL entre SHAPEFILE et FLATGEOBUF.
  3. Geopackage
  4. GeoJSON dans les choux (la version NEWLINE DELIMITED est à 673.9 Mo)

Chargement dans QGIS

Je charge simplement toutes ces couches dans un projet vide. J'ai activé le mode débogage pour avoir les temps de chargement.

Lors d'un premier chargement, voici les résultats

ms de chargement

Avec Geojson, cela prend trop de temps (je ne vais pas la charger dans la suite)

geolson

Essayons avec un zoom 1000, puis retour à toute l'étendue. (video ici)

Et encore un peu déplacement, de zoom, de sélection, et puis retour à l'étendue, le cache fait sans doute son oeuvre.

Visuellement, voilà ce que cela donne

J'ai testé aussi des traitements type buffer sur toutes les communes, et je n'ai pas noté d'amélioration par rapport au shapefile (102 contre 103 sec. donc négligeable)

Conclusion

Je ne tire pas de conclusion définitive. Mes pauvres essais montrent qu'il n'y pas une différence phénoménale en utilisation courante, ou limitée comme je l'ai fait (env 100ms). J'ai aussi testé en condition réelle, sur des pc plus puissants, avec du cadastre (parcelle et bâtiment) plus lourd, dans des projets pleins de couches, et j'ai noté une vraie différence d'affichage. Mais est-ce ma ferveur de la découverte ou un réel gain ? Toutefois, je note une légère amélioration et un format qui ne fait qu'un seul fichier, et déjà rien que ça, c'est plutôt pas mal. Et par rapport à du GeoJSON, ou le geopackage, il n'y a pas photo.

Si je suis passé à coté de quelquechose, ou si pensez que l'avenir est dans ce format ou l'inverse, déployez vos arguments en commentaire. Merci


2 commentaires

#1  - Anonyme a dit :

Salut,
Il y a je crois une faute sur le paragraphe situé juste avant le sous-titre LA TAILLE DES FICHIERS.

Répondre
#2  - Alain a dit :

merci, c'est corrigé (enfin je crois)

Répondre

Écrire un commentaire

Quelle est le dernier caractère du mot v2elc ?