Utoljára frissítve: 2026-11-04

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

GeoParquet vs. GeoJSON: Melyik GIS formátum jobb nagy adathalmazokhoz?

Ha valaha is megpróbáltál megnyitni egy 2 GB-os GeoJSON fájlt a QGIS-ben, vagy betölteni egy több millió soros polygon határfájlt egy interaktív térképre, már ismered a befagyott képernyő és a memóriahiányos összeomlás nyomasztó érzését.

Több mint egy évtizede a GeoJSON a webes kartográfia univerzális lingua francája. Átlátható, ember által olvasható, és szinte minden webes térképkönyvtár és REST API által alapból támogatott az interneten.

Azonban a modern GIS munkafolyamatok radikálisan eltérnek a 2008-as állapottól. A mai térinformatikai szakemberek rendszeresen dolgoznak fel gigabájt (vagy terabájt) méretű IoT mobilitási telemetriát, országos épületlábnyomokat, műholdas származású szegmentációs maszkokat és nagy frekvenciájú klímarácsokat.

Amikor ilyen méretű adathalmazokra alkalmazzák, a GeoJSON nem csak lelassul—teljesen szűk keresztmetszetet képez az adatarchitektúrákban.

Bemutatkozik a GeoParquet, egy nyílt, szabványosított térinformatikai kiterjesztés az Apache Parquethez, amely az Open Geospatial Consortium (OGC) keretében inkubálódik.

Ebben az átfogó útmutatóban összehasonlítjuk a GeoParquet-et és a GeoJSON-t az architektúra, tárolási hatékonyság, olvasási/írási áteresztőképesség, felhőre való felkészültség és a fejlesztői ergonómia szempontjából, hogy megválaszoljunk egy kritikus kérdést: Melyik formátumot válassza nagy adathalmazokhoz?

1. Strukturális architektúra: szöveg vs. bináris oszlopos

Ahhoz, hogy megértsük, miért teljesítenek ezek a formátumok ilyen eltérően nagy léptékben, be kell nézni a motor mögé, hogyan ábrázolják az egyes koordinátaértékeket és a táblázatos metaadatokat.

+--------------------------------------------------------------+
| Értékelési metrika |
| **Adatformátum** |
| **Geometriai ábrázolás** |
| **Tömörítési arány** |
| **Oszlopvetítés** |
+--------------------------------------------------------------+
                               VS
+--------------------------------------------------------------+
| **Térbeli predikátum lecsökkentés** |
| **Felhő objektumtároló (S3/GCS)** |
| **Emberi olvashatóság** |
| **Webböngésző támogatás** |
| **Szabványosító testület** |
+--------------------------------------------------------------+

GeoJSON: sor-orientált, szövegkódolt JSON

A GeoJSON adatokat JSON objektumok tömbjeként ábrázolja. Minden egyes elem kifejezetten megismétli az attribútum kulcsait egy karakterlánc‑kódolt lebegőpontos számok tömbjével együtt:

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

Mivel a GeoJSON szövegalapú:

  • Ismétlődő sémák: Olyan mezőnevek, mint a "properties", "type" és "coordinates" milliószor ismétlődnek, növelve a nyers fájlméretet.
  • Költséges karakterlánc‑lebegőpontos átalakítás: A CPU-nak szöveges karaktereket ("-", "9", "7", ".", "7"...) kell 64 bites IEEE dupla pontosságú lebegőpontos számokká konvertálnia, mielőtt bármilyen térbeli műveletet végrehajtana.
  • Monolitikus olvasási követelmények: A szabványos JSON-parszereknek a teljes fájlt be kell olvasniuk a memóriába a Dokumentum Objektum Modell (DOM) felépítéséhez. Egy attribútum olvasása az összes egyes elem feldolgozását igényli.

GeoParquet: oszlop-orientált, bináriskódolt adatok

A GeoParquet közvetlenül az Apache Parquet-re épül, és a térbeli táblákat oszloponként, nem soronként tárolja.

Az olyan attribútumok, mint a county, folytonos blokkokban tárolódnak, lehetővé téve fejlett tömörítési technikákat, például futamhossz‑kódolást (RLE), bitcsomagolást és szótár tömörítést. A geometriai adatokat Well-Known Binary (WKB)‑ként szabványosítják, beágyazott JSON metaadatok kísérik, amelyek részletezik a térbeli referenciarendszereket (CRS), a határoló dobozokat és a geometria típusait.

Mivel a GeoParquet bináris és oszlopos:

  • Null Koordináta Elemzési Költség: A geometriákat közvetlenül bináris formában tárolják, elkerülve a költséges karakterlánc‑lebegőpontos átalakításokat.
  • Projektálás Leeresztése: Ha az alárendelt munkafolyamat csak a county és pop_density oszlopokra van szüksége, az olvasó csak ezeket a bájteltolásokat tölti le lemezről vagy S3‑ról, teljesen kihagyva a geometria oszlopot.
  • Sor‑csoport Partícionálás: A Parquet fájlok rekordokat önálló “Row Groups”‑ra osztják (gyakran 100 000‑tól 1 000 000‑ig soronként), minden oszlophoz min/max statisztikákkal.

2. Közvetlen összehasonlítás: a fő metrikák

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. Tárolási hatékonyság és fájlméret mérőszámok

Amikor a feljegyzések számát ezrekről milliókra növeljük, a tárolási különbségek drámaian nőnek.

A valós világ nyílt térbeli rekordjait (például az OpenStreetMap épületkontúrokat, az US Census TIGER határolásokat és a globális hajó AIS naplókat) felhasználó szabványos benchmarkokban a GeoParquet rendszeresen 70%‑tól 85%‑ig tároláscsökkenés ér el a nyers GeoJSON-hoz képest, és további 20%‑tól 40%‑ig felülmúlja a .geojson.gz-t.

Miért olyan sokkal kisebb a GeoParquet?

  1. Szótárkódolás: Az ismétlődő karakterlánc attribútumok (például államkódok, földhasználati osztályozások) kis egész szám mutatókba vannak indexelve, ahelyett, hogy hosszú karakterláncként tárolnák őket többször.
  2. Kompakt bináris koordináták: Egy 2D pont a GeoJSON-ban körülbelül 30‑tól 45‑byte ASCII szöveget foglal ([-122.4194155, 37.7749295]). WKB‑ben ugyanaz a koordinátapár pontosan 16 byte.
  3. Modern tömörítési algoritmusok: A Zstandard (Zstd) és a Snappy sokkal hatékonyabban tömöríti a oszlopos bájt tömböket, mint a szabványos Gzip az összefűzött sor‑alapú szöveget.

4. Lekérdezési teljesítmény és felhőnatív munkafolyamatok

A legnagyobb különbség a nagy adathalmazoknál nem csak a tárolás—hanem a lekérdezési késleltetés és memóriahasználat.

1. Szelektív olvasás oszlopprojekcióval

Képzelj el egy 15 GB méretű nemzeti parcellák adatkészletet, amely 60 attribútumot tartalmaz (tulajdonosnevek, adóazonosítók, tulajdonjog történet, övezeti kódok és összetett multipolygon határok).

  • GeoJSON-ban: Ha szeretnéd kiszámítani az átlagos felmért ingatlanértéket irányítószám szerint, az elemző motorodnak le kell töltenie és elemeznie kell az összes 15 GB-ot, beleértve a milliók számát a komplex határcsúcsokból.
  • GeoParquet-ban: Olyan elemző motorok, mint a DuckDB, az Apache Sedona, a Polars vagy az AWS Athena csak a zip_code és assessed_value oszlopokat olvassák. A 15 GB átvitele helyett a motorod kevesebb, mint 80 MB-ot tölt le és vizsgál.

2. HTTP tartománykérések felhőtárolón

A GeoParquet zökkenőmentesen működik felhőnatív térinformatikai formátumként.

Mivel a Parquet fájlok a belső eltolásokat és metaadatokat a fájl láblécében tárolják, az ügyfélkönyvtárak HTTP GET Range: bytes=... kéréseket küldhetnek felhő tárhelyekhez, mint az Amazon S3, a Google Cloud Storage vagy az Azure Blob Storage. Ahelyett, hogy egy egész több gigabájtos fájlt töltenének le, a kliens beolvassa a láblécet, azonosítja a pontos bájteltolásokat, ahol a releváns rekordok találhatók, és csak a szükséges részhalmazokat tölti le.

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. Szoftverökoszisztéma és eszköztámogatás

Történelmileg a GeoJSON fő előnye az volt, hogy univerzális eszköztámogatással rendelkezett. Bár ez a böngészői környezetekben továbbra is igaz, a GeoParquet ökoszisztéma gyorsan fejlődött:

  • Desktop GIS: Natív olvasási/írási támogatás a QGIS 3.28+, ArcGIS Pro és GDAL/OGR 3.5+ verziókban.
  • Analytical Engines & Languages: Gyors vektorizált olvasási/írási képességek Pythonban (GeoPandas, pyarrow), R-ben (sf), DuckDB-ben (a térbeli kiterjesztésen keresztül), Apache Sedona-ban és Snowflake-ban.
  • Big Data Pipelines: Natív integráció az Apache Spark, Trino, Presto és Databricks rendszerek között.
  • Client-Side Web Maps: Könnyű WebAssembly könyvtárak (például parquet-wasm és duckdb-wasm) most már lehetővé teszik, hogy a web böngészők közvetlenül a kliens eszközökön kérdezzék le a GeoParquet fájlokat, dedikált GIS köztes szerver nélkül.

6. Gyakorlati döntési mátrix: Mikor melyiket használjuk?

                                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álassza a GeoJSON-t, ha:

  • Az adathalmazod 50 MB és 100 MB között van.
  • Könnyű payload válaszokat adsz vissza egy REST API-ból a frontend klienseknek.
  • Könnyű webtérképeket építesz a Leaflet, MapLibre vagy Mapbox GL JS használatával köztes fordítási rétegek nélkül.
  • Gyors kézi szerkesztésre vagy ellenőrzésre van szüksége egy szabványos kódszerkesztőben vagy szövegszerkesztőben.

Válassza a GeoParquet-et, ha:

  • Az adathalmaz meghaladja a 100 MB-ot, vagy több százezres mennyiségű összetett térbeli elemet tartalmaz.
  • Vektoros eszközöket tárol felhő alapú objektumtárolóban (S3, GCS, MinIO, Azure Blob).
  • Térbeli SQL-elemzéseket, jellemzőképzést vagy gépi tanulási folyamatokat futtat Python, DuckDB, Spark vagy Databricks használatával.
  • Csökkenteni szeretné a tárolási költségeket, elkerülni a hálózati kimeneti díjakat, és megszüntetni a memóriaösszeomlásokat.

7. Migrációs példa: GeoJSON átalakítása GeoParquet-re

A meglévő térbeli eszközök GeoParquet formátumba konvertálása csak néhány kódsort igényel.

Python használata (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")

GDAL / OGR használata (CLI)

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

DuckDB használata

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. Összefoglaló: A döntés a nagy adathalmazokról

Kis adathalmazok és közvetlen webes végpontok esetén a GeoJSON továbbra is megbízható, gondtalan segédformátum.

Azonban nagy adathalmazok esetén a GeoParquet objektívan felülmúlja a többi megoldást minden működési kategóriában. Kisebb fájlméretet biztosít, jelentősen alacsonyabb tárolási terhelést, szinte azonnali térbeli olvasásokat, és natív integrációt a modern felhő adatraktárakkal.

Ha a geospaciális adatcsatornáid a túlméretezett GeoJSON fájlok súlya alatt nyögnek, a GeoParquet-re való áttérés az egyik leghatékonyabb infrastruktúra fejlesztés, amit végrehajthatsz.

Gyakran Ismételt Kérdések (GYIK)

Q1. A GeoParquet hivatalosan elismert GIS szabvány? Igen, a GeoParquet egy hivatalos nyílt szabvány, amelyet az Open Geospatial Consortium (OGC) irányítása alatt tartanak karban.

Q2. Megjeleníthetek egy GeoParquet fájlt közvetlenül a webes térképkönyvtárakban, mint a Leaflet vagy a Mapbox GL JS? Bár nem natívan értelmezhető, mint a GeoJSON, a GeoParquet-et megjelenítheted a böngészőkben WebAssembly csomagok, például a parquet-wasm használatával, vagy a fájlok vektor csempékké (PMTiles/MVT) konvertálásával a betöltéskor.

Q3. Támogatja a GeoParquet a több koordináta-referencia rendszert (CRS)? Igen, a GeoJSON-tól eltérően (amely szigorúan a WGS 84 / EPSG:4326-ra korlátozódik az RFC 7946 szerint), a GeoParquet lehetővé teszi egyedi CRS definíciók közvetlen beágyazását a fájl metaadataiban.

Q4. Hogyan hasonlítható a GeoParquet a FlatGeobuf-hoz nagy térbeli adatkészletek esetén? A FlatGeobuf optimalizált a térbeli jellemzők streamingjére közvetlenül interaktív webtérképekhez R-Tree térbeli indexeléssel, míg a GeoParquet magas teljesítményű oszlopos analitikára, tömörítésre és hatalmas adat-tó raktározásra lett tervezve.

Q5. Megnyithatom a GeoParquet fájlokat asztali GIS szoftverben, például a QGIS-ben? Igen, a QGIS modern verziói (3.28 és újabb) támogatják a GeoParquet fájlok húzás‑és‑ejtés, megtekintés és stílusozás funkcióit anélkül, hogy harmadik féltől származó bővítményre lenne szükség.

Lásd még

GIS fájlformátumok a FileFormat.com-on

Az 5 legjobb GIS fájlformátum a Google Maps-hez

Fájlformátum hírek

Fájlformátum fórumok