GeoParquet vs. GeoJSON - Performance, taille de fichier et SIG cloud‑native comparés

Dernière mise à jour : 2026-11-04

GeoParquet vs. GeoJSON : quel format SIG est meilleur pour les grands ensembles de données ?

Si vous avez déjà essayé d’ouvrir un fichier GeoJSON de 2 Go dans QGIS ou de charger un fichier de limites polygonales contenant plusieurs millions de lignes dans une carte interactive, vous connaissez déjà la sensation désagréable d’un écran figé et d’un plantage dû à un manque de mémoire.

Depuis plus d’une décennie, GeoJSON sert de lingua franca universelle de la cartographie web. Il est transparent, lisible par l’homme et pris en charge immédiatement par presque toutes les bibliothèques de cartographie web et les API REST sur Internet.

Cependant, les flux de travail GIS modernes sont radicalement différents de ceux de 2008. Les praticiens géospatiaux d’aujourd’hui ingèrent régulièrement des gigaoctets (ou téraoctets) de télémétrie de mobilité IoT, des empreintes de bâtiments à l’échelle nationale, des masques de segmentation dérivés de satellites et des grilles climatiques à haute fréquence.

Lorsqu’il est appliqué à des ensembles de données à cette échelle, le GeoJSON ne se contente pas de ralentir — il crée un goulot d’étranglement complet des architectures de données.

Voici GeoParquet, une extension géospatiale ouverte et standardisée d’Apache Parquet en incubation au sein de l’Open Geospatial Consortium (OGC).

Dans ce guide complet, nous comparons GeoParquet et GeoJSON en termes d’architecture, d’efficacité de stockage, de débit de lecture/écriture, de préparation au cloud et d’ergonomie pour les développeurs afin de répondre à une question cruciale : Quel format devez‑vous choisir pour les grands ensembles de données ?

1. Architecture structurelle : texte vs. colonne binaire

Pour comprendre pourquoi ces formats se comportent si différemment à grande échelle, il faut examiner en profondeur la façon dont chacun représente les valeurs de coordonnées et les métadonnées tabulaires.

+--------------------------------------------------------------+
| Métrique d'évaluation |
| **Format de données** |
| **Représentation géométrique** |
| **Taux de compression** |
| **Projection de colonne** |
+--------------------------------------------------------------+
                               VS
+--------------------------------------------------------------+
| **Propagation de prédicat spatial** |
| **Stockage d'objets cloud (S3/GCS)** |
| **Lisibilité humaine** |
| **Prise en charge des navigateurs Web** |
| **Organisme de normalisation** |
+--------------------------------------------------------------+

GeoJSON : orienté lignes, JSON encodé en texte

GeoJSON représente les données sous forme d’un tableau d’objets JSON. Chaque caractéristique répète explicitement les clés d’attributs aux côtés d’un tableau de nombres à virgule flottante encodés en chaîne :

{
  "type": "FeatureCollection",
  "features": [
    {
      "type": "Feature",
      "properties": { "county": "Travis", "state": "TX", "pop_density": 1845.2 },
      "geometry": {
        "type": "Point",
        "coordinates": [-97.74306, 30.26715]
      }
    }
  ]
}

Parce que GeoJSON est basé sur du texte :

• Schémas répétitifs : Les noms de champs comme "properties", "type" et "coordinates" sont répétés des millions de fois, gonflant la taille brute du fichier.
• Conversion coûteuse de chaîne en flottant : Votre CPU doit analyser les caractères texte ("-", "9", "7", ".", "7"...) en nombres à virgule flottante double précision IEEE 64 bits avant d’effectuer toute opération spatiale.
• Exigences de lecture monolithiques : Les analyseurs JSON standard doivent charger le fichier entier en mémoire pour construire le Document Object Model (DOM). Lire un seul attribut nécessite d’analyser chaque caractéristique.

GeoParquet : orienté colonnes, données encodées en binaire

GeoParquet s’appuie directement sur Apache Parquet, stockant les tables spatiales colonne par colonne plutôt que ligne par ligne.

Des attributs comme county sont stockés dans des blocs contigus, permettant des techniques de compression avancées telles que l’encodage run-length (RLE), le bit-packing et la compression par dictionnaire. Les données géométriques sont standardisées en Well-Known Binary (WKB), accompagnées de métadonnées JSON intégrées détaillant les systèmes de référence spatiale (CRS), les boîtes englobantes et les types de géométrie.

Parce que GeoParquet est binaire et columnaire :

• Coût zéro d’analyse des coordonnées : Les géométries sont stockées directement en forme binaire, contournant les coûteuses conversions chaîne‑vers‑flottant.
• Projection Pushdown : Si votre flux de travail en aval n’a besoin que des colonnes county et pop_density, le lecteur récupère uniquement ces décalages d’octets depuis le disque ou S3, en sautant complètement la colonne de géométrie.
• Partitionnement par groupe de lignes : Les fichiers Parquet divisent les enregistrements en “Row Groups” autonomes (souvent de 100 000 à 1 000 000 de lignes chacun) complets avec des statistiques min/max pour chaque colonne.

2. Comparaison côte à côte : les métriques principales

3. Efficacité de stockage et références de taille de fichier

Lors du passage de milliers à des millions d’enregistrements, les disparités de stockage s’élargissent considérablement.

Dans les benchmarks standard utilisant des enregistrements spatiaux ouverts du monde réel (tels que les empreintes de bâtiments OpenStreetMap, les limites TIGER du recensement américain et les journaux AIS mondiaux des navires), GeoParquet réalise régulièrement des réductions de stockage de 70 % à 85 % par rapport au GeoJSON brut, et surpasse .geojson.gz de 20 % à 40 % supplémentaires.

Pourquoi GeoParquet est-il tellement plus petit ?

1. Encodage par dictionnaire : Les attributs de chaîne répétés (par ex., les codes d’état, les classifications d’utilisation des sols) sont indexés en de petits pointeurs entiers plutôt que stockés à plusieurs reprises comme de longues chaînes.
2. Coordonnées binaires compactes : Un point 2D dans GeoJSON occupe environ 30 à 45 octets de texte ASCII ([-122.4194155, 37.7749295]). En WKB, cette même paire de coordonnées nécessite exactement 16 octets.
3. Algorithmes de compression modernes : Zstandard (Zstd) et Snappy compressent les tableaux d’octets columnaires beaucoup plus efficacement que le Gzip standard ne peut compresser le texte en lignes entrelacées.

4. Performance des requêtes et flux de travail cloud‑native

Le principal différenciateur pour les grands ensembles de données n’est pas seulement le stockage — c’est la latence des requêtes et l’utilisation de la mémoire.

1. Lectures sélectives via projection de colonnes

Imaginez un jeu de données national de parcelles de 15 Go contenant 60 attributs (noms de propriétaires, identifiants fiscaux, historique des titres, codes de zonage et limites multipolygones complexes).

• En GeoJSON : Si vous souhaitez calculer la valeur moyenne évaluée des propriétés par code postal, votre moteur analytique doit télécharger et analyser les 15 Go complets, y compris des millions de sommets de limites complexes.
• En GeoParquet : Les moteurs analytiques tels que DuckDB, Apache Sedona, Polars ou AWS Athena lisent uniquement les colonnes zip_code et assessed_value. Au lieu de transférer 15 Go, votre moteur télécharge et analyse moins de 80 Mo.

2. Requêtes HTTP Range sur le stockage cloud

GeoParquet fonctionne de manière transparente comme un format géospatial cloud‑native.

Comme les fichiers Parquet stockent les décalages internes et les métadonnées dans le pied de page du fichier, les bibliothèques clientes peuvent émettre des requêtes HTTP GET Range: bytes=... vers des stockages d’objets cloud tels qu’Amazon S3, Google Cloud Storage ou Azure Blob Storage. Au lieu de télécharger un fichier de plusieurs gigaoctets complet, le client lit le pied de page, identifie les décalages exacts où se trouvent les enregistrements pertinents, et ne télécharge que les sous‑ensembles nécessaires.

Client (DuckDB / Python / QGIS)
       │
       ├── 1. Read footer metadata (HTTP Range Request) ───► Cloud Storage (S3 / GCS)
       │                                                              │
       ◄── 2. Returns column offsets & row-group stats ───────────────┘
       │
       ├── 3. Read ONLY requested column chunks & ranges ─────────────►
       │                                                              │
       ◄── 4. Fast binary stream (minimal I/O & egress) ──────────────┘

5. Écosystème logiciel et prise en charge des outils

Historiquement, l’avantage principal de GeoJSON était le support universel des outils. Bien que cela reste vrai pour les environnements de navigateur, l’écosystème de GeoParquet a mûri rapidement :

• GIS de bureau : prise en charge native en lecture/écriture dans QGIS 3.28+, ArcGIS Pro et GDAL/OGR 3.5+.
• Moteurs analytiques & langages : capacités rapides de lecture/écriture vectorisées sur Python (GeoPandas, pyarrow), R (sf), DuckDB (via l’extension spatiale), Apache Sedona et Snowflake.
• Pipelines Big Data : intégration native avec Apache Spark, Trino, Presto et Databricks.
• Cartes Web côté client : des bibliothèques WebAssembly légères (telles que parquet-wasm et duckdb-wasm) permettent désormais aux navigateurs web d’interroger directement les fichiers GeoParquet sur les appareils clients, sans serveur middleware GIS dédié.

6. Matrice de décision pratique : quand utiliser quoi ?

                                Dataset Size & Use Case
                                           │
             ┌─────────────────────────────┴─────────────────────────────┐
             ▼                                                           ▼
     Under 50–100 MB                                              Over 100 MB
(API payloads, simple maps)                                (Data warehousing, big data)
             │                                                           │
             ▼                                                           ▼
      Use **GeoJSON**                                            Use **GeoParquet**
• Direct Mapbox/Leaflet integration                        • High compression ratios
• Human-readable inspection                                • Sub-second analytical queries
• Standard REST API responses                              • Direct S3/GCS HTTP range reads

Choisissez GeoJSON si :

• Votre jeu de données est compris entre 50 Mo et 100 Mo.
• Vous renvoyez des réponses de charge utile légères depuis une API REST vers les clients frontaux.
• Vous créez des cartes web légères avec Leaflet, MapLibre ou Mapbox GL JS sans couches de traduction intermédiaires.
• Vous avez besoin d’une édition ou d’une inspection manuelle rapide dans un éditeur de code ou de texte standard.

Choisissez GeoParquet si :

• Votre jeu de données dépasse 100 Mo, ou contient des centaines de milliers d’entités spatiales complexes.
• Vous stockez des actifs vectoriels dans un stockage d’objets cloud (S3, GCS, MinIO, Azure Blob).
• Vous exécutez des analyses SQL spatiales, de l’ingénierie des caractéristiques ou des pipelines d’apprentissage automatique en utilisant Python, DuckDB, Spark ou Databricks.
• Vous souhaitez réduire les coûts de stockage, éviter les frais de sortie réseau et éliminer les plantages de mémoire.

7. Exemple de migration : conversion de GeoJSON en GeoParquet

Convertir les actifs spatiaux existants en GeoParquet ne nécessite que quelques lignes de code.

Utilisation de Python (GeoPandas)

import geopandas as gpd

# 1. Read the legacy GeoJSON file
gdf = gpd.read_file("large_boundaries.geojson")

# 2. Write directly to GeoParquet using modern Zstandard compression
gdf.to_parquet("large_boundaries.parquet", compression="zstd")

Utilisation de GDAL / OGR (CLI)

ogr2ogr -f Parquet \
  -oo LCO:COMPRESSION=ZSTD \
  large_boundaries.parquet \
  large_boundaries.geojson

Utilisation de DuckDB

INSTALL spatial;
LOAD spatial;

-- Direct convert via SQL
COPY (
  SELECT * FROM ST_Read('large_boundaries.geojson')
) TO 'large_boundaries.parquet' 
WITH (FORMAT PARQUET, COMPRESSION 'ZSTD');

8. Résumé : Le verdict sur les grands ensembles de données

Pour les petits jeux de données et les points de terminaison web directs, GeoJSON reste un format utilitaire fiable et sans tracas.

Cependant, pour les grands jeux de données, GeoParquet est objectivement supérieur dans chaque catégorie opérationnelle. Il offre des empreintes de fichiers plus petites, un encombrement de stockage nettement réduit, des lectures spatiales quasi instantanées, et une intégration native avec les entrepôts de données cloud modernes.

Si vos pipelines géospatiaux ploient sous le poids de fichiers GeoJSON surdimensionnés, passer à GeoParquet est l’une des améliorations d’infrastructure les plus efficaces que vous puissiez réaliser.

Foire aux questions (FAQ)

Q1. GeoParquet est-il une norme SIG officiellement reconnue ? Oui, GeoParquet est une norme ouverte officielle maintenue sous la direction du Open Geospatial Consortium (OGC).

Q2. Puis-je rendre un fichier GeoParquet directement dans des bibliothèques de cartographie web comme Leaflet ou Mapbox GL JS ? Bien qu’il ne soit pas analysé nativement comme GeoJSON, vous pouvez rendre GeoParquet dans les navigateurs en utilisant des paquets WebAssembly comme parquet-wasm ou en convertissant les fichiers en tuiles vectorielles (PMTiles/MVT) lors de l’ingestion.

Q3. GeoParquet prend-il en charge plusieurs systèmes de référence de coordonnées (CRS) ? Oui, contrairement à GeoJSON (qui est strictement limité à WGS 84 / EPSG:4326 selon la RFC 7946), GeoParquet permet des définitions de CRS personnalisées directement dans les métadonnées intégrées du fichier.

Q4. Comment GeoParquet se compare-t-il à FlatGeobuf pour les grands ensembles de données spatiales ? FlatGeobuf est optimisé pour le streaming de fonctionnalités spatiales directement vers des cartes web interactives en utilisant l’indexation spatiale R-Tree, tandis que GeoParquet est conçu pour l’analyse columnaire haute performance, la compression et le stockage massif dans des lacs de données.

Q5. Puis-je ouvrir des fichiers GeoParquet dans un logiciel SIG de bureau comme QGIS ? Oui, les versions modernes de QGIS (version 3.28 et supérieures) prennent en charge le glisser‑déposer, la visualisation et le style des fichiers GeoParquet sans nécessiter de plugins tiers.

Voir aussi

Formats de fichiers SIG sur FileFormat.com

Top 5 des formats de fichiers SIG pour Google Maps

Actualités des formats de fichiers

Forums des formats de fichiers