Laatst bijgewerkt: 2026-11-04

GeoParquet vs. GeoJSON: Which GIS Format Is Best for Large Datasets?

GeoParquet vs. GeoJSON: Welk GIS-formaat is beter voor grote datasets?

Als je ooit hebt geprobeerd een 2 GB GeoJSON‑bestand in QGIS te openen of een polygon‑grensbestand met miljoenen rijen in een interactieve kaart te laden, weet je al dat het gevoel van een bevroren scherm en een out‑of‑memory‑crash.

Al meer dan een decennium dient GeoJSON als de universele lingua franca van webcartografie. Het is transparant, menselijk leesbaar en wordt out‑of‑the‑box ondersteund door bijna elke web‑mappingbibliotheek en REST‑API op internet.

Echter, moderne GIS‑workflows zien er radicaal anders uit dan in 2008. De hedendaagse geospatiale professionals nemen routinematig gigabytes (of terabytes) aan IoT‑mobiliteitstelemetrie, landelijke gebouwcontouren, door satellieten afgeleide segmentatiemaskers en hoogfrequente klimaatrasters op.

Wanneer het wordt toegepast op datasets van deze omvang, vertraagt GeoJSON niet alleen—het vormt een volledige knelpunt in data‑architecturen.

Maak kennis met GeoParquet, een open, gestandaardiseerde geospatiale extensie voor Apache Parquet die zich in incubatie bevindt binnen de Open Geospatial Consortium (OGC).

In deze uitgebreide gids vergelijken we GeoParquet en GeoJSON op het gebied van architectuur, opslag efficiëntie, lees-/schrijfsnelheid, cloud gereedheid en ontwikkelaar ergonomie om een cruciale vraag te beantwoorden: Welk formaat moet je kiezen voor grote datasets?

1. Structurele architectuur: tekst versus binaire kolomindeling

Om te begrijpen waarom deze formaten zo verschillend presteren op schaal, moet je onder de motorkap kijken naar hoe elk coördinaatwaarden en tabelmetadata weergeeft.

+--------------------------------------------------------------+
| Evaluatiemetric |
| **Gegevensformaat** |
| **Geometrische representatie** |
| **Compressieverhouding** |
| **Kolomprojectie** |
+--------------------------------------------------------------+
                               VS
+--------------------------------------------------------------+
| **Ruimtelijke predicaat pushdown** |
| **Cloud Object Storage (S3/GCS)** |
| **Menselijke leesbaarheid** |
| **Webbrowserondersteuning** |
| **Standaardiseringsorgaan** |
+--------------------------------------------------------------+

GeoJSON: rijgeoriënteerd, tekstgecodeerde JSON

GeoJSON stelt gegevens voor als een array van JSON-objecten. Elke afzonderlijke feature herhaalt expliciet attribuutsleutels naast een array van als tekst gecodeerde zwevende-kommagetallen:

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

Omdat GeoJSON tekstgebaseerd is:

  • Repetitieve schema’s: Veldnamen zoals "properties", "type" en "coordinates" worden miljoenen keren herhaald, waardoor de ruwe bestandsgrootte toeneemt.
  • Kostenintense teken-naar-float conversie: Je CPU moet teksttekens ("-", "9", "7", ".", "7"...) omzetten naar 64-bit IEEE double-precision floats voordat een ruimtelijke bewerking kan worden uitgevoerd.
  • Monolithische leesvereisten: Standaard JSON-parsers moeten het volledige bestand in het geheugen laden om het Document Object Model (DOM) op te bouwen. Het lezen van één attribuut vereist het parseren van elke afzonderlijke feature.

GeoParquet: kolomgeoriënteerd, binair gecodeerde gegevens

GeoParquet bouwt direct voort op Apache Parquet, waarbij ruimtelijke tabellen kolom-voor-kolom worden opgeslagen in plaats van rij-voor-rij.

Attributen zoals county worden opgeslagen in aaneengesloten blokken, waardoor geavanceerde compressietechnieken mogelijk zijn, zoals run-length encoding (RLE), bit-packing en dictionary-compressie. Geometriegegevens zijn gestandaardiseerd als Well-Known Binary (WKB), vergezeld van ingebedde JSON-metadata die ruimtelijke referentiesystemen (CRS), begrenzingskaders en geometrietypen beschrijft.

Omdat GeoParquet binair en kolomgebaseerd is:

  • Geen Kosten voor Coördinaatontleding: Geometrieën worden direct in binaire vorm opgeslagen, waardoor dure string-naar-float conversies worden omzeild.
  • Projection Pushdown: Als je downstream workflow alleen de kolommen county en pop_density nodig heeft, haalt de lezer alleen die byte-offsets op van schijf of S3, en slaat de geometrie‑kolom volledig over.
  • Row-Group Partitionering: Parquet‑bestanden splitsen records in zelfstandige “Row Groups” (vaak 100.000 tot 1.000.000 rijen per groep) met volledige min/max‑statistieken voor elke kolom.

2. Directe vergelijking: de kernmetriek

Evaluation MetricGeoJSONGeoParquet
Data FormatPlain-text JSON (UTF-8)Binary columnar (Apache Parquet)
Geometry RepresentationNested arrays of coordinate stringsStandardized Well-Known Binary (WKB)
Compression RatioPoor (requires gzip/bzip2 to reduce)Exceptional (native Zstd, Snappy, Gzip)
Column Projection❌ No (entire record must be parsed)✅ Yes (fetch only the columns you need)
Spatial Predicate Pushdown❌ No (requires full scan)✅ Yes (using bounding box metadata)
Cloud Object Storage (S3/GCS)❌ Poor (must download full file)✅ Cloud-native (supports HTTP range requests)
Human Readability✅ Direct viewing in text editors❌ Requires CLI, GIS app, or code
Web Browser SupportNative JavaScript (JSON.parse)Requires WebAssembly (e.g., duckdb-wasm, parquet-wasm)
Standardization BodyIETF (RFC 7946)OGC (Open Geospatial Consortium standard)

3. Opslagefficiëntie en benchmarks voor bestandsgrootte

Wanneer je opschaalt van duizenden naar miljoenen records, worden de opslagverschillen dramatisch groter.

In standaard benchmarks met echte open ruimtelijke records (zoals OpenStreetMap gebouwcontouren, US Census TIGER grenzen, en wereldwijde scheeps AIS-logs), behaalt GeoParquet consequent 70% tot 85% opslagreducties vergeleken met ruwe GeoJSON, en verslaat .geojson.gz met nog eens 20% tot 40%.

Waarom is GeoParquet zoveel kleiner?

  1. Dictionary Encoding: Herhaalde tekenreeksattributen (bijv. staatscodes, landgebruikclassificaties) worden geïndexeerd naar kleine integer‑pointers in plaats van herhaaldelijk als lange tekenreeksen op te slaan.
  2. Compact Binary Coordinates: Een 2D‑punt in GeoJSON neemt ongeveer 30 tot 45 bytes ASCII‑tekst in beslag ([-122.4194155, 37.7749295]). In WKB vereist datzelfde coördinaatpaar exact 16 bytes.
  3. Modern Compression Algorithms: Zstandard (Zstd) en Snappy comprimeren kolom‑byte‑arrays veel effectiever dan standaard Gzip interleaved rij‑gebaseerde tekst kan comprimeren.

4. Queryprestaties en cloud‑native workflows

De grootste onderscheidende factor voor grote datasets is niet alleen opslag—het is querylatentie en geheugengebruik.

1. Selectieve lecties via kolomprojectie

Stel je een nationale perceeldataset van 15 GB voor met 60 attributen (eigenaarsnamen, belasting‑ID’s, eigendomsgeschiedenis, bestemmingscodes en complexe multipolygon‑grenzen).

  • In GeoJSON: Als je de gemiddelde getaxeerde vastgoedwaarde per postcode wilt berekenen, moet je analytische engine alle 15 GB downloaden en parseren, inclusief miljoenen complexe grens‑vertices.
  • In GeoParquet: Analytische engines zoals DuckDB, Apache Sedona, Polars of AWS Athena lezen alleen de zip_code en assessed_value kolommen. In plaats van 15 GB over te dragen, downloadt en scant je engine minder dan 80 MB.

2. HTTP-bereikverzoeken op cloudopslag

GeoParquet werkt naadloos als een cloud-native geospatiaal formaat.

Omdat Parquet‑bestanden interne offsets en metadata in hun bestandsfooter opslaan, kunnen client‑bibliotheken HTTP GET Range: bytes=...‑verzoeken sturen naar cloud‑objectstores zoals Amazon S3, Google Cloud Storage of Azure Blob Storage. In plaats van een heel multi‑gigabyte bestand te downloaden, leest de client de footer, identificeert de exacte byte‑offsets waar relevante records zich bevinden, en downloadt alleen de benodigde subsets.

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. Software-ecosysteem & toolondersteuning

Historisch gezien was het belangrijkste voordeel van GeoJSON de universele toolondersteuning. Terwijl dat nog steeds geldt voor browseromgevingen, is het ecosysteem van GeoParquet snel volwassen geworden:

  • Desktop GIS: Native ondersteuning voor lezen/schrijven in QGIS 3.28+, ArcGIS Pro en GDAL/OGR 3.5+.
  • Analytische engines & talen: Snelle gevectoriseerde lees-/schrijfmogelijkheden in Python (GeoPandas, pyarrow), R (sf), DuckDB (via de spatial extensie), Apache Sedona en Snowflake.
  • Big Data-pijplijnen: Native integratie met Apache Spark, Trino, Presto en Databricks.
  • Client-side webkaarten: Lichtgewicht WebAssembly-bibliotheken (zoals parquet-wasm en duckdb-wasm) stellen webbrowsers nu in staat om GeoParquet-bestanden direct op clientapparaten te raadplegen zonder een dedicated GIS-middleware server.

6. Praktische beslissingsmatrix: wanneer welke te gebruiken?

                                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

Kies GeoJSON als:

  • Uw dataset is kleiner dan 50 MB tot 100 MB.
  • U retourneert lichte payload-responses van een REST API naar frontend-clients.
  • U bouwt lichte webkaarten met Leaflet, MapLibre of Mapbox GL JS zonder tussenliggende vertaallagen.
  • U heeft snelle handmatige bewerking of inspectie nodig in een standaard code- of teksteditor.

Kies GeoParquet als:

  • Uw dataset overschrijdt 100 MB, of bevat honderden duizenden complexe ruimtelijke kenmerken.
  • U slaat vectorassets op in cloudobjectopslag (S3, GCS, MinIO, Azure Blob).
  • U voert ruimtelijke SQL‑analyse, feature‑engineering of machine‑learning‑pijplijnen uit met Python, DuckDB, Spark of Databricks.
  • U wilt opslagkosten verlagen, netwerkkosten voor uitgaand verkeer vermijden en geheugencrashes elimineren.

7. Migratievoorbeeld: GeoJSON naar GeoParquet converteren

Het converteren van bestaande ruimtelijke assets naar GeoParquet vereist slechts een paar regels code.

Gebruik 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")

Gebruik GDAL / OGR (CLI)

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

DuckDB gebruiken

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. Samenvatting: Het oordeel over grote datasets

Voor kleine datasets en directe web‑endpoints blijft GeoJSON een betrouwbaar, probleemloos utiliteitsformaat.

Echter, voor grote datasets is GeoParquet objectief superieur in elke operationele categorie. Het levert kleinere bestandsafdrukken, aanzienlijk lagere opslagoverhead, bijna‑directe ruimtelijke leesbewerkingen, en native integratie met moderne cloud‑datawarehouses.

Als uw geospatiale pipelines kreunen onder het gewicht van te grote GeoJSON-bestanden, is overschakelen naar GeoParquet een van de meest effectieve infrastructuurupgrades die u kunt uitvoeren.

Veelgestelde vragen (FAQ)

Q1. Is GeoParquet een officieel erkende GIS-standaard? Ja, GeoParquet is een officiële open standaard die wordt onderhouden onder de leiding van de Open Geospatial Consortium (OGC).

Q2. Kan ik een GeoParquet-bestand direct weergeven in web‑mappingbibliotheken zoals Leaflet of Mapbox GL JS? Hoewel het niet native wordt geparseerd zoals GeoJSON, kunt u GeoParquet in browsers weergeven met WebAssembly‑pakketten zoals parquet-wasm of door bestanden bij het inladen te converteren naar Vector Tiles (PMTiles/MVT).

Q3. Ondersteunt GeoParquet meerdere coördinatenreferentiesystemen (CRS)? Ja, in tegenstelling tot GeoJSON (dat strikt beperkt is tot WGS 84 / EPSG:4326 volgens RFC 7946), staat GeoParquet aangepaste CRS-definities toe direct binnen de ingebedde bestandsmetadata.

Q4. Hoe verhoudt GeoParquet zich tot FlatGeobuf voor grote ruimtelijke datasets? FlatGeobuf is geoptimaliseerd voor het streamen van ruimtelijke features direct naar interactieve webkaarten met behulp van R-Tree ruimtelijke indexering, terwijl GeoParquet is ontworpen voor high-performance kolomanalyses, compressie en massale data lake opslag.

Q5. Kan ik GeoParquet-bestanden openen in desktop GIS-software zoals QGIS? Ja, moderne versies van QGIS (versie 3.28 en hoger) ondersteunen het slepen, neerzetten, bekijken en stylen van GeoParquet-bestanden zonder dat derden plugins nodig zijn.

Zie ook

GIS-bestandsformaten op FileFormat.com

Top 5 GIS-bestandsformaten voor Google Maps

Nieuws over bestandsformaten

Forums over bestandsformaten