Zuletzt aktualisiert: 2026-11-04

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

GeoParquet vs. GeoJSON: Welches GIS-Format ist besser für große Datensätze?

Wenn Sie jemals versucht haben, eine 2 GB‑GeoJSON‑Datei in QGIS zu öffnen oder eine Polygon‑Grenzdaten‑Datei mit mehreren Millionen Zeilen in eine interaktive Karte zu laden, kennen Sie bereits das beklemmende Gefühl eines eingefrorenen Bildschirms und eines Absturzes wegen Speicherüberlaufs.

Seit mehr als einem Jahrzehnt dient GeoJSON als universelle Lingua Franca der Webkartografie. Es ist transparent, menschenlesbar und wird von praktisch jeder Web‑Mapping‑Bibliothek und REST‑API im Internet sofort unterstützt.

Moderne GIS‑Workflows sehen jedoch radikal anders aus als 2008. Heute verarbeiten Geodaten‑Fachleute routinemäßig Gigabytes (oder Terabytes) an IoT‑Mobilitäts‑Telemetriedaten, landesweite Gebäudekonturen, satellitengenerierte Segmentierungs‑Masken und hochfrequente Klimagitter.

Bei Datensätzen in diesem Umfang verlangsamt GeoJSON nicht nur – es wird zum vollständigen Engpass in Datenarchitekturen.

Hier kommt GeoParquet ins Spiel, eine offene, standardisierte geospatiale Erweiterung von Apache Parquet, die im Open Geospatial Consortium (OGC) inkubiert wird.

In diesem umfassenden Leitfaden vergleichen wir GeoParquet und GeoJSON hinsichtlich Architektur, Speichereffizienz, Lese-/Schreibdurchsatz, Cloud‑Bereitschaft und Entwickler‑Ergonomie, um eine entscheidende Frage zu beantworten: Welches Format sollten Sie für große Datensätze wählen?

1. Strukturelle Architektur: Text vs. Binär spaltenbasiert

Um zu verstehen, warum diese Formate in großem Maßstab so unterschiedlich performen, muss man einen Blick unter die Haube werfen, wie jedes von ihnen Koordinatenwerte und tabellarische Metadaten darstellt.

+--------------------------------------------------------------+
| Evaluationsmetrik |
| **Datenformat** |
| **Geometrie-Darstellung** |
| **Kompressionsrate** |
| **Spaltenprojektion** |
+--------------------------------------------------------------+
                               VS
+--------------------------------------------------------------+
| **Räumliche Prädikat-Pushdown** |
| **Cloud-Objektspeicher (S3/GCS)** |
| **Menschliche Lesbarkeit** |
| **Webbrowser-Unterstützung** |
| **Standardisierungsorganisation** |
+--------------------------------------------------------------+

GeoJSON: Zeilenorientiert, textkodiertes JSON

GeoJSON stellt Daten als ein Array von JSON‑Objekten dar. Jede einzelne Feature wiederholt explizit Attributschlüssel zusammen mit einem Array von als Zeichenkette kodierten Fließkommazahlen:

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

Da GeoJSON textbasiert ist:

  • Wiederholende Schemata: Feldnamen wie "properties", "type" und "coordinates" werden Millionen‑fach wiederholt, was die rohe Dateigröße aufbläht.
  • Kostenintensive String‑zu‑Float‑Umwandlung: Ihre CPU muss Textzeichen ("-", "9", "7", ".", "7"...) in 64‑Bit IEEE‑Doppel‑Präzisions‑Fließkommazahlen konvertieren, bevor irgendeine räumliche Operation durchgeführt werden kann.
  • Monolithische Leseanforderungen: Standard‑JSON‑Parser müssen die gesamte Datei in den Speicher laden, um das Document Object Model (DOM) zu erstellen. Das Lesen eines Attributs erfordert das Parsen jeder einzelnen Feature.

GeoParquet: Spaltenorientiert, binärkodierte Daten

GeoParquet baut direkt auf Apache Parquet auf und speichert räumliche Tabellen spaltenweise statt zeilenweise.

Attribute wie county werden in zusammenhängenden Blöcken gespeichert, was fortschrittliche Kompressionstechniken wie Run-Length-Encoding (RLE), Bit-Packing und Wörterbuchkompression ermöglicht. Geometriedaten werden als Well-Known Binary (WKB) standardisiert und von eingebetteten JSON-Metadaten begleitet, die räumliche Bezugssysteme (CRS), Begrenzungsrahmen und Geometrietypen beschreiben.

Da GeoParquet binär und spaltenbasiert ist:

  • Keine Kosten für Koordinatenparsen: Geometrien werden direkt im Binärformat gespeichert, wodurch teure String-zu-Float-Konvertierungen umgangen werden.
  • Projektions-Pushdown: Wenn Ihr nachgelagerter Workflow nur die Spalten county und pop_density benötigt, holt der Leser nur diese Byte-Offsets von Festplatte oder S3 und überspringt die Geometriespalte vollständig.
  • Row-Group-Partitionierung: Parquet-Dateien teilen Datensätze in eigenständige “Row Groups” (oft 100.000 bis 1.000.000 Zeilen pro Gruppe) und enthalten Min/Max-Statistiken für jede Spalte.

2. Direktvergleich: Die Kernmetriken

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. Speichereffizienz und Dateigrößen-Benchmarks

Beim Skalieren von Tausenden auf Millionen von Datensätzen weiten sich die Speicherunterschiede dramatisch aus.

In Standard-Benchmarks mit realen offenen räumlichen Datensätzen (wie OpenStreetMap-Gebäudekonturen, US Census TIGER-Grenzen und globalen Schiffs‑AIS‑Logs) erzielt GeoParquet routinemäßig 70 % bis 85 % Speicherreduktionen im Vergleich zu rohem GeoJSON und schlägt .geojson.gz um weitere 20 % bis 40 %.

Warum ist GeoParquet so viel kleiner?

  1. Dictionary Encoding: Wiederholte Zeichenkettenattribute (z. B. Staatencodes, Landnutzungs‑Klassifikationen) werden in kleine Ganzzahl‑Zeiger indiziert, anstatt wiederholt als lange Zeichenketten gespeichert zu werden.
  2. Compact Binary Coordinates: Ein 2D‑Punkt in GeoJSON benötigt etwa 30 bis 45 Byte ASCII‑Text ([-122.4194155, 37.7749295]). In WKB erfordert dasselbe Koordinatenpaar exakt 16 Byte.
  3. Modern Compression Algorithms: Zstandard (Zstd) und Snappy komprimieren spaltenbasierte Byte‑Arrays deutlich effektiver als das Standard‑Gzip zeilenbasierten, interleavten Text komprimieren kann.

4. Abfrageleistung und cloud-native Arbeitsabläufe

Der wichtigste Unterschied bei großen Datensätzen liegt nicht nur im Speicher – er besteht in Abfrage‑Latenz und Speicherauslastung.

1. Selektive Lesevorgänge mittels Spaltenprojektion

Stellen Sie sich einen 15 GB großen nationalen Flurstück-Datensatz vor, der 60 Attribute enthält (Eigentümernamen, Steuer‑IDs, Grundbuchhistorie, Zonierungscodes und komplexe Multipolygon‑Grenzen).

  • In GeoJSON: Wenn Sie den durchschnittlichen bewerteten Immobilienwert pro Postleitzahl berechnen möchten, muss Ihre Analyse‑Engine alle 15 GB herunterladen und parsen, einschließlich Millionen komplexer Grenzscheitelpunkte.
  • In GeoParquet: Analyse‑Engines wie DuckDB, Apache Sedona, Polars oder AWS Athena lesen nur die Spalten zip_code und assessed_value. Anstatt 15 GB zu übertragen, lädt Ihre Engine weniger als 80 MB herunter und scannt sie.

2. HTTP-Range-Anfragen im Cloud-Speicher

GeoParquet funktioniert nahtlos als cloud-natives Geodatenformat.

Da Parquet‑Dateien interne Offsets und Metadaten in ihrem Dateifooter speichern, können Client‑Bibliotheken HTTP GET Range: bytes=...‑Anfragen an Cloud‑Objektspeicher wie Amazon S3, Google Cloud Storage oder Azure Blob Storage stellen. Anstatt eine gesamte mehr‑gigabyte‑große Datei herunterzuladen, liest der Client den Footer, ermittelt die genauen Byte‑Offsets, an denen relevante Datensätze liegen, und lädt nur die benötigten Teilmengen herunter.

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-Ökosystem & Werkzeugunterstützung

Historisch war der Hauptvorteil von GeoJSON die universelle Tool‑Unterstützung. Während dies für Browser‑Umgebungen weiterhin zutrifft, hat sich das Ökosystem von GeoParquet schnell weiterentwickelt:

  • Desktop GIS: Native Lese-/Schreibunterstützung in QGIS 3.28+, ArcGIS Pro und GDAL/OGR 3.5+.
  • Analytische Engines & Sprachen: Schnelle vektorisierte Lese-/Schreibfunktionen in Python (GeoPandas, pyarrow), R (sf), DuckDB (über die räumliche Erweiterung), Apache Sedona und Snowflake.
  • Big‑Data‑Pipelines: Native Integration mit Apache Spark, Trino, Presto und Databricks.
  • Client‑seitige Webkarten: Leichte WebAssembly‑Bibliotheken (wie parquet-wasm und duckdb-wasm) ermöglichen es Webbrowsern jetzt, GeoParquet‑Dateien direkt auf Client‑Geräten abzufragen, ohne einen dedizierten GIS‑Middleware‑Server.

6. Praktische Entscheidungsmatrix: Wann welches verwenden?

                                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

Wählen Sie GeoJSON, wenn:

  • Ihr Datensatz liegt zwischen 50 MB und 100 MB.
  • Sie geben leichte Payload‑Antworten einer REST‑API an Frontend‑Clients zurück.
  • Sie erstellen leichte Webkarten mit Leaflet, MapLibre oder Mapbox GL JS ohne Zwischentranslationsschichten.
  • Sie benötigen schnelle manuelle Bearbeitung oder Inspektion in einem Standard‑Code‑ oder Texteditor.

Wählen Sie GeoParquet, wenn:

  • Ihr Datensatz überschreitet 100 MB oder enthält Hunderttausende komplexer räumlicher Features.
  • Sie speichern Vektor‑Assets in Cloud‑Objektspeicher (S3, GCS, MinIO, Azure Blob).
  • Sie führen räumliche SQL‑Analysen, Feature‑Engineering oder Machine‑Learning‑Pipelines mit Python, DuckDB, Spark oder Databricks aus.
  • Sie möchten Speicherkosten senken, Netzwerk‑Egress‑Gebühren vermeiden und Speicherabstürze eliminieren.

7. Migrationsbeispiel: Konvertierung von GeoJSON zu GeoParquet

Das Konvertieren bestehender räumlicher Assets zu GeoParquet erfordert nur ein paar Code‑Zeilen.

Verwendung von 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")

Verwendung von GDAL / OGR (CLI)

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

DuckDB verwenden

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. Zusammenfassung: Das Urteil über große Datensätze

Für kleine Datensätze und direkte Web‑Endpoints bleibt GeoJSON ein zuverlässiges, unkompliziertes Nutzformat.

Allerdings ist für große Datensätze GeoParquet objektiv in jeder betrieblichen Kategorie überlegen. Es liefert kleinere Dateigrößen, deutlich geringeren Speicheraufwand, nahezu sofortige räumliche Lesevorgänge und native Integration mit modernen Cloud‑Data‑Warehouses.

Wenn Ihre geospatialen Pipelines unter dem Gewicht von übergroßen GeoJSON-Dateien ächzen, ist der Umstieg auf GeoParquet eine der effektivsten Infrastrukturverbesserungen, die Sie vornehmen können.

Häufig gestellte Fragen (FAQ)

Q1. Ist GeoParquet ein offiziell anerkannter GIS-Standard? Ja, GeoParquet ist ein offizieller offener Standard, der unter der Leitung des Open Geospatial Consortium (OGC) gepflegt wird.

Q2. Kann ich eine GeoParquet-Datei direkt in Web-Mapping-Bibliotheken wie Leaflet oder Mapbox GL JS rendern? Obwohl sie nicht nativ wie GeoJSON geparst wird, können Sie GeoParquet in Browsern mit WebAssembly-Paketen wie parquet-wasm rendern oder die Dateien bei der Aufnahme in Vector Tiles (PMTiles/MVT) konvertieren.

Q3. Unterstützt GeoParquet mehrere Koordinatenreferenzsysteme (CRS)? Ja, im Gegensatz zu GeoJSON (das strikt auf WGS 84 / EPSG:4326 nach RFC 7946 beschränkt ist), erlaubt GeoParquet benutzerdefinierte CRS-Definitionen direkt in den eingebetteten Dateimetadaten.

Q4. Wie vergleicht sich GeoParquet mit FlatGeobuf für große räumliche Datensätze? FlatGeobuf ist für das Streaming räumlicher Features direkt zu interaktiven Webkarten mit R-Tree-Raumindizierung optimiert, während GeoParquet für leistungsstarke spaltenbasierte Analysen, Kompression und massive Data-Lake-Warehousing konzipiert ist.

Q5. Kann ich GeoParquet-Dateien in Desktop-GIS-Software wie QGIS öffnen? Ja, moderne Versionen von QGIS (Version 3.28 und höher) unterstützen das Ziehen, Ablegen, Anzeigen und Stylen von GeoParquet-Dateien, ohne dass Drittanbieter-Plugins erforderlich sind.

Siehe auch

GIS-Dateiformate bei FileFormat.com

Top 5 GIS-Dateiformate für Google Maps

Dateiformat-News

Dateiformat-Foren