GeoParquet vs. GeoJSON: Hvilket GIS-format er bedre for store datasæt?

Hvis du nogensinde har forsøgt at åbne en 2 GB GeoJSON‑fil i QGIS eller indlæse en polygongrænsefil med flere millioner rækker i et interaktivt kort, ved du allerede den ubehagelige fornemmelse af en frossen skærm og et hukommelsesnedbrud.

I mere end et årti har GeoJSON tjent som det universelle lingua franca inden for webkartografi. Det er gennemsigtigt, menneskelæsbart og understøttes direkte af næsten alle webkortbiblioteker og REST‑API’er på internettet.

Moderne GIS‑arbejdsgange ser imidlertid radikalt anderledes ud end de gjorde i 2008. Dagens geospatiale fagfolk indlæser rutinemæssigt gigabytes (eller terabytes) af IoT‑mobilitetstelemetri, landsdækkende bygningstegninger, satellit‑afledte segmenteringsmasker og højfrekvente klimagitre.

Når det anvendes på datasæt i denne skala, bremser GeoJSON ikke kun – det udgør en fuldstændig flaskehals i dataarkitekturer.

Mød GeoParquet, en åben, standardiseret geospatiale udvidelse til Apache Parquet, som er under inkubation i Open Geospatial Consortium (OGC).

I denne omfattende guide sammenligner vi GeoParquet og GeoJSON på tværs af arkitektur, lagringseffektivitet, læse-/skrivegennemløb, cloud-beredskab og udviklerergonomi for at besvare et kritisk spørgsmål: Hvilket format skal du vælge til store datasæt?

1. Strukturel Arkitektur: Tekst vs. Binær Kolonnær

For at forstå, hvorfor disse formater præsterer så forskelligt i stor skala, skal du kigge under motorhjelmen på, hvordan hver af dem repræsenterer koordinatværdier og tabelmetadata.

+--------------------------------------------------------------+
| Evalueringsmetrik |
| **Dataformat** |
| **Geometrirepræsentation** |
| **Komprimeringsforhold** |
| **Kolonneprojektion** |
+--------------------------------------------------------------+
                               VS
+--------------------------------------------------------------+
| **Rumlig Prædikat Pushdown** |
| **Cloud-objektlagring (S3/GCS)** |
| **Menneskelig læsbarhed** |
| **Webbrowser-understøttelse** |
| **Standardiseringsorgan** |
+--------------------------------------------------------------+

GeoJSON: Rækkeorienteret, Tekstkodet JSON

GeoJSON repræsenterer data som et array af JSON-objekter. Hvert enkelt feature gentager eksplicit attributnøgler sammen med et array af strengkodede flydende tal:

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

Fordi GeoJSON er tekstbaseret:

• Gentagne skemaer: Feltnavne som "properties", "type" og "coordinates" gentages millioner af gange, hvilket opblæser den rå filstørrelse.
• Om­kostningsfuld streng‑til‑flydende konvertering: Din CPU skal parse teksttegn ("-", "9", "7", ".", "7"...) til 64-bit IEEE double‑precision flydende tal, før du udfører nogen rumlig operation.
• Monolitiske læsekrav: Standard JSON‑parsers skal indlæse hele filen i hukommelsen for at konstruere Document Object Model (DOM). At læse én attribut kræver, at alle enkelte features parses.

GeoParquet: Kolonneorienteret, Binærkodet Data

GeoParquet bygger direkte på Apache Parquet, og gemmer rumlige tabeller kolonne for kolonne i stedet for række for række.

Attributter som county gemmes i sammenhængende blokke, hvilket muliggør avancerede komprimeringsteknikker såsom run-length encoding (RLE), bit-packing og ordbogs-komprimering. Geometri-data standardiseres som Well-Known Binary (WKB), ledsaget af indlejret JSON-metadata, der beskriver rumlige referencessystemer (CRS), begrænsningsbokse og geometrityper.

Fordi GeoParquet er binær og kolonnebaseret:

• Nul Koordinat Parsningsomkostning: Geometrier gemmes direkte i binær form, hvilket omgår dyre streng‑til‑flydende‑tal‑konverteringer.
• Projection Pushdown: Hvis din efterfølgende arbejdsgang kun har brug for county- og pop_density-kolonnerne, henter læseren kun de byte‑offsets fra disk eller S3 og springer geometrikolonnen helt over.
• Row-Group Partitioning: Parquet‑filer opdeler poster i selvstændige "Row Groups" (ofte 100.000 til 1.000.000 rækker hver) med fuldstændige min/max‑statistikker for hver kolonne.

2. Direkte Sammenligning: De Centrale Målepunkter

3. Lagringseffektivitet og Filstørrelsesbenchmark

Når man skalerer fra tusinder til millioner af poster, udvides lagerforskelene dramatisk.

I standardbenchmark-tests, der bruger virkelige åbne rumlige poster (såsom OpenStreetMap bygningstegninger, US Census TIGER-grænser og globale skibs‑AIS‑logfiler), opnår GeoParquet rutinemæssigt 70 % til 85 % lagringsreduktioner sammenlignet med rå GeoJSON, og slår .geojson.gz med yderligere 20 % til 40 %.

Hvorfor er GeoParquet så meget mindre?

1. Dictionary Encoding: Gentagne strengattributter (f.eks. delstatskoder, arealanvendelsesklassifikationer) indekseres til små heltalspegepinde i stedet for at blive gemt gentagne gange som lange strenge.
2. Compact Binary Coordinates: Et 2D‑punkt i GeoJSON optager omkring 30 til 45 bytes ASCII‑tekst ([-122.4194155, 37.7749295]). I WKB kræver det samme koordinatpar præcis 16 bytes.
3. Modern Compression Algorithms: Zstandard (Zstd) og Snappy komprimerer kolonnære byte‑arrays meget mere effektivt end standard‑Gzip kan komprimere indlejret række‑baseret tekst.

4. Forespørgselsydelse og Cloud-native Arbejdsprocesser

Den største differentierende faktor for store datasæt er ikke kun lager—det er forespørgselslatens og hukommelsesudnyttelse.

1. Selektive Læsninger via Kolonneprojektion

Forestil dig et 15 GB nationalt parcel-datasæt, der indeholder 60 attributter (ejernavne, skatte‑ID’er, skøderhistorik, zonekoder og komplekse multipolygon‑grænser).

• I GeoJSON: Hvis du vil beregne den gennemsnitlige vurderede ejendomsværdi pr. postnummer, skal din analytiske motor downloade og parse alle 15 GB, inklusive millioner af komplekse grænse‑vertexer.
• I GeoParquet: Analytiske motorer som DuckDB, Apache Sedona, Polars eller AWS Athena læser kun kolonnerne zip_code og assessed_value. I stedet for at overføre 15 GB, downloader og scanner din motor mindre end 80 MB.

2. HTTP Range-anmodninger på cloud-lagring

GeoParquet fungerer problemfrit som et cloud-native geospatielt format.

Fordi Parquet‑filer gemmer interne offset og metadata i deres filfod, kan klientbiblioteker udsende HTTP GET Range: bytes=...‑anmodninger til cloud‑objektlagre som Amazon S3, Google Cloud Storage eller Azure Blob Storage. I stedet for at downloade en hel multi‑gigabyte fil, læser klienten fodet, identificerer de præcise byte‑offset, hvor relevante poster findes, og downloader kun de nødvendige delmængder.

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 & værktøjsunderstøttelse

Historisk set var GeoJSON’s primære fordel universel værktøjsunderstøttelse. Mens det stadig er sandt for browsermiljøer, har GeoParquet-økosystemet modnet hurtigt:

• Desktop GIS: Indfødt læse/skriv-understøttelse i QGIS 3.28+, ArcGIS Pro, og GDAL/OGR 3.5+.
• Analytical Engines & Languages: Hurtige vektoriserede læse/skriv-funktioner på tværs af Python (GeoPandas, pyarrow), R (sf), DuckDB (via den rumlige udvidelse), Apache Sedona og Snowflake.
• Big Data Pipelines: Indfødt integration på tværs af Apache Spark, Trino, Presto og Databricks.
• Client-Side Web Maps: Letvægts WebAssembly-biblioteker (såsom parquet-wasm og duckdb-wasm) gør det nu muligt for webbrowsere at forespørge GeoParquet-filer direkte på klientenheder uden en dedikeret GIS-middleware-server.

6. Praktisk beslutningsmatrix: Hvornår skal du bruge hvilken?

                                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

Vælg GeoJSON hvis:

• Dit datasæt er mellem 50 MB og 100 MB.
• Du returnerer letvægts-payload-responser fra en REST API til frontend-klienter.
• Du bygger letvægts webkort ved hjælp af Leaflet, MapLibre eller Mapbox GL JS uden mellemliggende oversættelseslag.
• Du har brug for hurtig manuel redigering eller inspektion i en standard kode- eller teksteditor.

Vælg GeoParquet hvis:

• Dit datasæt overstiger 100 MB, eller indeholder hundredtusinder af komplekse rumlige funktioner.
• Du gemmer vektor‑aktiver i cloud‑objektlagring (S3, GCS, MinIO, Azure Blob).
• Du kører rumlig SQL‑analyse, feature‑engineering eller maskin‑lærings‑pipelines ved hjælp af Python, DuckDB, Spark eller Databricks.
• Du vil reducere lagringsomkostninger, undgå netværksudgående gebyrer og eliminere hukommelsesnedbrud.

7. Migrationseksempel: Konvertering af GeoJSON til GeoParquet

Konvertering af eksisterende rumlige aktiver til GeoParquet kræver kun et par linjer kode.

Brug af 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")

Brug af GDAL / OGR (CLI)

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

Brug af 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. Opsummering: Dommen om store datasæt

For små datasæt og direkte web‑endpoints forbliver GeoJSON et pålideligt, problemfrit hjælpeformat.

Men for store datasæt er GeoParquet objektivt overlegen i alle operationelle kategorier. Det leverer mindre filfodaftryk, betydeligt lavere lagringsomkostninger, næsten øjeblikkelige rumlige læsninger og indbygget integration med moderne cloud‑datavarehuse.

Hvis dine geospatiale pipelines knager under vægten af overdimensionerede GeoJSON-filer, er skiftet til GeoParquet en af de mest effektive infrastrukturopgraderinger, du kan foretage.

Ofte stillede spørgsmål (FAQ)

Q1. Er GeoParquet en officielt anerkendt GIS-standard? Ja, GeoParquet er en officiel åben standard, der vedligeholdes under vejledning af Open Geospatial Consortium (OGC).

Q2. Kan jeg gengive en GeoParquet-fil direkte i webkortbiblioteker som Leaflet eller Mapbox GL JS? Selvom den ikke parses native som GeoJSON, kan du gengive GeoParquet i browsere ved hjælp af WebAssembly-pakker som parquet-wasm eller ved at konvertere filer til Vector Tiles (PMTiles/MVT) ved indtagning.

Q3. Understøtter GeoParquet flere koordinatreferencesystemer (CRS)? Ja, i modsætning til GeoJSON (som er strengt begrænset til WGS 84 / EPSG:4326 i henhold til RFC 7946), tillader GeoParquet brugerdefinerede CRS-definitioner direkte i dens indlejrede filmetadata.

Q4. Hvordan sammenlignes GeoParquet med FlatGeobuf for store rumlige datasæt? FlatGeobuf er optimeret til streaming af rumlige funktioner direkte til interaktive webkort ved brug af R-Tree rumlig indeksering, mens GeoParquet er designet til højtydende kolonnær analyse, kompression og massiv datalake-lagring.

Q5. Kan jeg åbne GeoParquet-filer i desktop GIS-software som QGIS? Ja, moderne versioner af QGIS (version 3.28 og derover) understøtter træk‑og‑slip, visning og styling af GeoParquet-filer uden at kræve tredjeparts‑plugins.

Se også

GIS-filformater på FileFormat.com

Top 5 GIS-filformater til Google Maps

Nyheder om filformater

Filformatfora