GeoParquet vs. GeoJSON: Vilket GIS-format är bättre för stora datamängder?

Om du någonsin har försökt öppna en 2 GB GeoJSON‑fil i QGIS eller ladda en polygon‑gränsfil med flera miljoner rader i en interaktiv karta, vet du redan den nedslående känslan av en frusen skärm och ett minnesutrymmesfel.

I över ett decennium har GeoJSON fungerat som det universella lingua francan för webbkartografi. Det är transparent, mänskligt läsbart och stöds direkt av nästan alla webbkartbibliotek och REST‑API:er på internet.

Men moderna GIS‑arbetsflöden ser radikalt annorlunda ut än de gjorde 2008. Dagens geospatiala yrkesutövare importerar rutinmässigt gigabyte (eller terabyte) av IoT‑mobilitetstelemetri, nationella byggnadsavtryck, satellitbaserade segmenteringsmasker och högfrekventa klimatnät.

När det tillämpas på dataset i denna skala, saktar GeoJSON inte bara ner – det blir en fullständig flaskhals i dataarkitekturer.

Här kommer GeoParquet, ett öppet, standardiserat geospatialt tillägg till Apache Parquet som inkuberas inom Open Geospatial Consortium (OGC).

I den här omfattande guiden jämför vi GeoParquet och GeoJSON utifrån arkitektur, lagringseffektivitet, läs/skriv-genomströmning, molnberedskap och utvecklarergonomi för att besvara en kritisk fråga: Vilket format bör du välja för stora datamängder?

1. Strukturell arkitektur: Text vs. binär kolumnbaserad

För att förstå varför dessa format presterar så olika i stor skala måste du titta under huven på hur var och en representerar koordinatvärden och tabellmetadata.

+--------------------------------------------------------------+
| Utvärderingsmått |
| **Dataformat** |
| **Geometrirepresentation** |
| **Komprimeringsförhållande** |
| **Kolumnprojektion** |
+--------------------------------------------------------------+
                               VS
+--------------------------------------------------------------+
| **Spatialt predikat‑nedtryckning** |
| **Molnobjektlagring (S3/GCS)** |
| **Mänsklig läsbarhet** |
| **Webbläsarstöd** |
| **Standardiseringsorgan** |
+--------------------------------------------------------------+

GeoJSON: Radorienterad, textkodad JSON

GeoJSON representerar data som en array av JSON-objekt. Varje enskild funktion upprepar explicit attributnycklar tillsammans med en array av strängkodade flyttal:

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

Eftersom GeoJSON är textbaserat:

• Upprepade scheman: Fältnamn som "properties", "type" och "coordinates" upprepas miljoner gånger, vilket ökar den råa filstorleken.
• Kostsam sträng‑till‑flyttalskonvertering: Din CPU måste tolka texttecken ("-", "9", "7", ".", "7"...) till 64‑bitars IEEE dubbelprecision flyttal innan någon rumslig operation kan utföras.
• Monolitiska läskrav: Standard‑JSON‑parsers måste läsa in hela filen i minnet för att konstruera Document Object Model (DOM). Att läsa ett attribut kräver att varje enskild funktion parsas.

GeoParquet: Kolumnorienterad, binärkodad data

GeoParquet bygger direkt på Apache Parquet, och lagrar rumsliga tabeller kolumn för kolumn snarare än rad för rad.

Attribut som county lagras i sammanhängande block, vilket möjliggör avancerade komprimeringstekniker såsom run-length encoding (RLE), bit-packing och dictionary compression. Geometri-data standardiseras som Well-Known Binary (WKB), tillsammans med inbäddad JSON-metadata som beskriver rumsliga referenssystem (CRS), begränsningsboxar och geometrityper.

Eftersom GeoParquet är binär och kolumnbaserad:

• Ingen kostnad för koordinatparsing: Geometrier lagras direkt i binär form, vilket kringgår dyra string‑to‑float‑konverteringar.
• Projection Pushdown: Om ditt efterföljande arbetsflöde bara behöver kolumnerna county och pop_density, hämtar läsaren endast dessa byte‑offset från disk eller S3, och hoppar helt över geometrikolumnen.
• Row-Group Partitioning: Parquet‑filer delar upp poster i självständiga “Row Groups” (ofta 100 000 till 1 000 000 rader vardera) med fullständiga min/max‑statistik för varje kolumn.

2. Jämförelse sida vid sida: De viktigaste mätvärdena

3. Lagringseffektivitet och filstorleksbenchmarkar

När man skalar från tusentals till miljoner poster, ökar lagringsskillnaderna dramatiskt.

I standardprestandatester med verkliga öppna rumsliga data (såsom OpenStreetMap-byggnadsytor, US Census TIGER-gränser och globala fartygs‑AIS‑loggar) uppnår GeoParquet rutinmässigt 70% till 85% lagringsreduktioner jämfört med rå GeoJSON, och slår .geojson.gz med ytterligare 20% till 40%.

Varför är GeoParquet så mycket mindre?

1. Dictionary Encoding: Upprepade strängattribut (t.ex. delstatskoder, markanvändningsklassificeringar) indexeras till små heltalspekare istället för att lagras upprepade gånger som långa strängar.
2. Compact Binary Coordinates: En 2D‑punkt i GeoJSON tar cirka 30 till 45 byte ASCII‑text ([-122.4194155, 37.7749295]). I WKB kräver samma koordinatpar exakt 16 byte.
3. Modern Compression Algorithms: Zstandard (Zstd) och Snappy komprimerar kolumnära byte‑arrayer mycket effektivare än standard‑Gzip kan komprimera intrasslad radbaserad text.

4. Frågeprestanda och molnbaserade arbetsflöden

Den största skillnaden för stora dataset är inte bara lagring – det är frågelatens och minnesanvändning.

1. Selektiva läsningar via kolumnprojektion

Föreställ dig en nationell fastighetsdatamängd på 15 GB som innehåller 60 attribut (ägarens namn, skatte‑ID, handlingens historik, zonkoder och komplexa multipolygon‑gränser).

• I GeoJSON: Om du vill beräkna det genomsnittliga taxerade fastighetsvärdet per postnummer måste din analytiska motor ladda ner och pars​a hela de 15 GB, inklusive miljontals komplexa gräns‑vertexar.
• I GeoParquet: Analytiska motorer som DuckDB, Apache Sedona, Polars eller AWS Athena läser endast kolumnerna zip_code och assessed_value. Istället för att överföra 15 GB laddar din motor ner och skannar mindre än 80 MB.

2. HTTP‑intervallförfrågningar på molnlagring

GeoParquet fungerar sömlöst som ett moln‑native geospatialt format.

Eftersom Parquet‑filer lagrar interna offset‑värden och metadata i filens fot, kan klientbibliotek skicka HTTP GET Range: bytes=...‑förfrågningar till moln‑objektlagringar som Amazon S3, Google Cloud Storage eller Azure Blob Storage. Istället för att ladda ner en hel fler‑gigabyte‑fil läser klienten foten, identifierar de exakta byte‑offseten där relevanta poster finns, och laddar ner endast de nödvändiga delarna.

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. Mjukvaruekosystem och verktygsstöd

Historiskt sett var GeoJSON:s främsta fördel universellt verktygsstöd. Även om det fortfarande gäller för webbläsarmiljöer har GeoParquets ekosystem mognat snabbt:

• Desktop GIS: Inbyggt läs/skriv-stöd i QGIS 3.28+, ArcGIS Pro och GDAL/OGR 3.5+.
• Analytical Engines & Languages: Snabb vektoriserad läs/skriv-funktionalitet i Python (GeoPandas, pyarrow), R (sf), DuckDB (via det spatiala tillägget), Apache Sedona och Snowflake.
• Big Data Pipelines: Inbyggd integration med Apache Spark, Trino, Presto och Databricks.
• Client-Side Web Maps: Lätta WebAssembly-bibliotek (såsom parquet-wasm och duckdb-wasm) gör nu det möjligt för webbläsare att fråga GeoParquet-filer direkt på klientenheter utan en dedikerad GIS-mellanståndsserver.

6. Praktisk beslutsmatris: När ska man använda vilket?

                                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älj GeoJSON om:

• Ditt dataset är under 50 MB till 100 MB.
• Du returnerar lätta payload-svar från ett REST‑API till frontend‑klienter.
• Du bygger lätta webbkartor med Leaflet, MapLibre eller Mapbox GL JS utan mellansteg för översättning.
• Du behöver snabb manuell redigering eller granskning i en standardkod- eller textredigerare.

Välj GeoParquet om:

• Din datamängd överstiger 100 MB, eller innehåller hundratusentals komplexa rumsliga funktioner.
• Du lagrar vektorresurser i molnbaserad objektlagring (S3, GCS, MinIO, Azure Blob).
• Du kör rumslig SQL‑analys, feature‑engineering eller maskininlärnings‑pipelines med Python, DuckDB, Spark eller Databricks.
• Du vill minska lagringskostnader, undvika nätverksavgifter för utgående trafik och eliminera minneskrascher.

7. Migrationsexempel: Konvertera GeoJSON till GeoParquet

Att konvertera befintliga rumsliga resurser till GeoParquet kräver bara några få kodrader.

Använd 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")

Använd GDAL / OGR (CLI)

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

Använda 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. Sammanfattning: Domen om stora datamängder

För små datamängder och direkta webb‑endpoints förblir GeoJSON ett pålitligt, problemfritt verktygsformat.

Men för stora datamängder är GeoParquet objektivt överlägset i varje operativ kategori. Det levererar mindre filavtryck, avsevärt lägre lagringskostnad, nästintill omedelbara rumsliga läsningar och inbyggd integration med moderna molnbaserade datalager.

Om dina geospatiala pipelines gnisslar under vikten av överdimensionerade GeoJSON-filer, är byte till GeoParquet en av de mest effektiva infrastrukturuppgraderingarna du kan göra.

Vanliga frågor (FAQ)

Q1. Är GeoParquet en officiellt erkänd GIS-standard? Ja, GeoParquet är en officiell öppen standard som underhålls under ledning av Open Geospatial Consortium (OGC).

Q2. Kan jag rendera en GeoParquet-fil direkt i webbkartbibliotek som Leaflet eller Mapbox GL JS? Även om den inte parsas nativt som GeoJSON, kan du rendera GeoParquet i webbläsare med WebAssembly-paket som parquet-wasm eller genom att konvertera filer till Vector Tiles (PMTiles/MVT) vid import.

Q3. Stöder GeoParquet flera koordinatreferenssystem (CRS)? Ja, till skillnad från GeoJSON (som strikt är begränsad till WGS 84 / EPSG:4326 enligt RFC 7946), tillåter GeoParquet anpassade CRS-definitioner direkt i dess inbäddade filmetadata.

Q4. Hur jämför sig GeoParquet med FlatGeobuf för stora rumsliga dataset? FlatGeobuf är optimerat för att strömma rumsliga funktioner direkt till interaktiva webbkartor med R-Tree-indexering, medan GeoParquet är designat för högpresterande kolumnanalys, komprimering och massiv datalake‑lagring.

Q5. Kan jag öppna GeoParquet-filer i skrivbords‑GIS‑program som QGIS? Ja, moderna versioner av QGIS (version 3.28 och senare) stödjer att dra och släppa, visa och stilisera GeoParquet-filer utan att behöva tredjeparts‑plugins.

Se även

GIS-filformat på FileFormat.com

Topp 5 GIS-filformat för Google Maps

Nyheter om filformat

Forum för filformat