Paskutinį kartą atnaujinta: 2026-11-04

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

GeoParquet vs. GeoJSON: Koks GIS formatas geriau tinka dideliems duomenų rinkiniams?

Jei kada nors bandėte atidaryti 2 GB GeoJSON failą QGIS programoje arba įkelti daugiamilijonų eilučių poligono ribų failą į interaktyvią žemėlapį, jau žinote, kaip jaučiasi užšalusio ekrano ir atminties trūkumo gedimas.

Daugiau nei dešimtmetį GeoJSON tarnavo kaip universali web kartografijos lingua franca. Jis yra skaidrus, žmonėms suprantamas ir iš karto palaikomas beveik kiekvienos internetinės žemėlapių bibliotekos ir REST API.

Tačiau šiuolaikiniai GIS darbo procesai atrodo visiškai kitaip nei 2008 m. Šiandien geografinės informacijos specialistai reguliariai įkelia gigabaitus (arba terabaitus) IoT mobilumo telemetrijos duomenų, visos šalies pastatų kontūrų, palydovų sukurtų segmentavimo kaukių ir didelio dažnio klimato tinklų.

Taikant tokio masto duomenų rinkinius, GeoJSON ne tik sulėtina – jis visiškai riboja duomenų architektūras.

Pristatome GeoParquet, atvirą, standartizuotą geografinės informacijos plėtinį Apache Parquet, kuriam skiriama priežiūra Open Geospatial Consortium (OGC) organizacijoje.

Šiame išsamiajame vadove mes lyginame GeoParquet ir GeoJSON pagal architektūrą, saugojimo efektyvumą, skaitymo/rašymo pralaidumą, pasirengimą debesų aplinkai ir kūrėjų ergonomiką, siekdami atsakyti į svarbų klausimą: Kurią formatą turėtumėte pasirinkti dideliems duomenų rinkiniams?

1. Struktūrinė architektūra: tekstinė vs. binarinė stulpelinė

Norint suprasti, kodėl šie formatai veikia taip skirtingai mastu, reikia pažvelgti į vidų, kaip kiekvienas atvaizduoja koordinačių reikšmes ir lentelės metaduomenis.

+--------------------------------------------------------------+
| Vertinimo metrika |
| **Duomenų formatas** |
| **Geometrijos atvaizdavimas** |
| **Suspaudimo santykis** |
| **Stulpelio projekcija** |
+--------------------------------------------------------------+
                               VS
+--------------------------------------------------------------+
| **Erdvinio predikato išstumimas** |
| **Debesų objektų saugykla (S3/GCS)** |
| **Žmogaus skaitomumas** |
| **Naršyklės palaikymas** |
| **Standartizacijos organas** |
+--------------------------------------------------------------+

GeoJSON: eilutėmis orientuotas, tekstu koduotas JSON

GeoJSON atvaizduoja duomenis kaip JSON objektų masyvą. Kiekviena atskira funkcija (feature) aiškiai kartoja atributo raktus kartu su eilutėmis, kuriose užkoduoti slankaus kablelio skaičiai:

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

Kadangi GeoJSON yra tekstinis:

  • Kartojančios schemos: Laukų pavadinimai, tokie kaip "properties", "type" ir "coordinates", kartojami milijonus kartų, padidindami neapdoroto failo dydį.
  • Brangus eilutės‑į‑skaičių konvertavimas: Jūsų procesorius turi išanalizuoti teksto simbolius ("-", "9", "7", ".", "7"...) į 64‑bitų IEEE dvigubo tikslumo slankaus kablelio skaičius prieš atliekant bet kokią erdvinę operaciją.
  • Monolitiniai skaitymo reikalavimai: Standartiniai JSON analizatoriai turi įkelti visą failą į atmintį, kad sukurtų Dokumento Objektų Modelį (DOM). Perskaityti vieną atributą reikia analizuoti kiekvieną atskirą funkciją.

GeoParquet: stulpeliais orientuotas, binariniai koduoti duomenys

GeoParquet tiesiogiai remiasi Apache Parquet, saugodamas erdvines lenteles stulpelis po stulpelio, o ne eilutė po eilutės.

Tokie atributai kaip county saugomi nuosekliuose blokų, leidžiantys pažangias suspaudimo technikas, tokias kaip run-length encoding (RLE), bit-packing ir dictionary compression. Geometrijos duomenys yra standartizuoti kaip Well-Known Binary (WKB), kartu su įterptais JSON metaduomenimis, nurodančiais erdvinės nuorodos sistemas (CRS), ribinius laukus ir geometrijos tipus.

Kadangi GeoParquet yra binarinis ir stulpelinės struktūros:

  • Nulinė koordinatės analizės kaina: Geometrijos saugomos tiesiogiai binarinėje formoje, apeinant brangius eilutės‑į‑skaičių konvertavimus.
  • Projekcijos stumdymas: Jei jūsų vėlesnis darbinis srautas reikalauja tik county ir pop_density stulpelių, skaitytojas ištraukia tik tuos baitų poslinkius iš disko arba S3, visiškai praleisdamas geometrijos stulpelį.
  • Eilučių grupės skaidymas: Parquet failai suskaido įrašus į savarankiškas “Row Groups” (dažnai po 100 000–1 000 000 eilučių) su pilna min/max statistika kiekvienam stulpeliui.

2. Tiesioginis palyginimas: pagrindiniai rodikliai

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. Saugojimo efektyvumas ir failų dydžio etalonai

Kai mastelis didėja nuo tūkstančių iki milijonų įrašų, saugojimo skirtumai išauga dramatiškai.

Įprastiniuose našumo testuose, naudojant realaus pasaulio atvirus erdvinius įrašus (pvz., OpenStreetMap pastatų kontūrus, JAV gyventojų surašymo TIGER ribas ir pasaulinius laivų AIS žurnalus), GeoParquet nuosekliai pasiekia 70% to 85% storage reductions lyginant su neapdorotu GeoJSON ir pranoksta .geojson.gz dar 20% to 40%.

Kodėl GeoParquet yra tiek mažesnis?

  1. Dictionary Encoding: Kartojamos eilutės atributai (pvz., valstijos kodai, žemės naudojimo klasifikacijos) indeksuojami į mažus sveikųjų skaičių rodyklius, o ne saugomi kartotinai kaip ilgos eilutės.
  2. Compact Binary Coordinates: 2D taškas GeoJSON užima apie 30–45 baitus ASCII teksto ([-122.4194155, 37.7749295]). WKB formatu tas pats koordinatų pora reikalauja lygiai 16 baitų.
  3. Modern Compression Algorithms: Zstandard (Zstd) ir Snappy suspaudžia stulpelinės baitų masyvus daug efektyviau nei standartinis Gzip gali suspausti persidengiantį eilutės pagrindu tekstą.

4. Užklausų našumas ir debesų natūralūs darbo srautai

Didžiausias skirtumas dideliems duomenų rinkiniams nėra tik saugojimas – tai query latency and memory utilization.

1. Selektiškas skaitymas per stulpelių projekciją

Įsivaizduokite 15 GB nacionalinį sklypų duomenų rinkinį, kuriame yra 60 atributų (savininkų vardai, mokesčių ID, dokumentų istorija, zonavimo kodai ir sudėtingos daugiakampės ribos).

  • GeoJSON formate: Jei norite apskaičiuoti vidutinę įvertintą turto vertę pagal pašto kodą, jūsų analitinė variklis turi atsisiųsti ir apdoroti visus 15 GB, įskaitant milijonus sudėtingų ribų viršūnių.
  • GeoParquet formate: Analitiniai varikliai, tokie kaip DuckDB, Apache Sedona, Polars arba AWS Athena, skaito tik zip_code ir assessed_value stulpelius. Vietoj 15 GB perdavimo, jūsų variklis atsisiunčia ir skenuoja mažiau nei 80 MB.

2. HTTP diapazono užklausos debesų saugykloje

GeoParquet veikia sklandžiai kaip debesis gimto geografinis formatas.

Kadangi Parquet failai saugo vidinius poslinkius ir metaduomenis failo poraštėje, kliento bibliotekos gali siųsti HTTP GET Range: bytes=... užklausas į debesų objektų saugyklas, tokias kaip Amazon S3, Google Cloud Storage arba Azure Blob Storage. Vietoj viso kelių gigabaitų failo atsisiuntimo, klientas perskaito poraštę, nustato tikslius baitų poslinkius, kur yra atitinkami įrašai, ir atsisiunčia tik reikiamus duomenų fragmentus.

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. Programinės įrangos ekosistema ir įrankių palaikymas

Istoriškai pagrindinis GeoJSON pranašumas buvo universali įrankių palaikymas. Nors tai vis dar galioja naršyklių aplinkoje, GeoParquet ekosistema sparčiai subrendo:

  • Darbalaukio GIS: Natūrali skaitymo/rašymo palaikymas QGIS 3.28+, ArcGIS Pro ir GDAL/OGR 3.5+.
  • Analitiniai varikliai ir kalbos: Greitos vektorizuotos skaitymo/rašymo galimybės per Python (GeoPandas, pyarrow), R (sf), DuckDB (per erdvinį plėtinį), Apache Sedona ir Snowflake.
  • Didelių duomenų srautai: Natūrali integracija su Apache Spark, Trino, Presto ir Databricks.
  • Kliento pusės žemėlapiai internete: Lengvos WebAssembly bibliotekos (pvz., parquet-wasm ir duckdb-wasm) dabar leidžia žiniatinklio naršyklėms tiesiogiai užklausti GeoParquet failų kliento įrenginiuose be specialaus GIS tarpinio serverio.

6. Praktinė sprendimų matrica: Kada naudoti kurį?

                                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

Pasirinkite GeoJSON, jei:

  • Jūsų duomenų rinkinys yra nuo 50 MB iki 100 MB.
  • Grąžinate lengvus apkrovos atsakymus iš REST API priekinės pusės klientams.
  • Kuriate lengvus žemėlapius internete naudodami Leaflet, MapLibre arba Mapbox GL JS be tarpinio vertimo sluoksnių.
  • Jums reikia greito rankinio redagavimo arba peržiūros standartiniame kodo ar teksto redaktoriuje.

Pasirinkite GeoParquet, jei:

  • Jūsų duomenų rinkinys viršija 100 MB arba jame yra šimtai tūkstančių sudėtingų erdvinių elementų.
  • Jūs saugote vektorinius išteklius debesų objektų saugykloje (S3, GCS, MinIO, Azure Blob).
  • Jūs vykdote erdvinę SQL analizę, požymių inžineriją arba mašininio mokymosi procesus naudodami Python, DuckDB, Spark arba Databricks.
  • Jūs norite sumažinti saugojimo išlaidas, išvengti tinklo išsiuntimo mokesčių ir pašalinti atminties gedimus.

7. Migracijos pavyzdys: GeoJSON konvertavimas į GeoParquet

Esamų erdvinių išteklių konvertavimas į GeoParquet reikalauja tik kelių kodo eilučių.

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

Naudojant GDAL / OGR (CLI)

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

Naudojant 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. Santrauka: Išvada apie didelius duomenų rinkinius

Mažiems duomenų rinkiniams ir tiesioginiams interneto galutiniams taškams GeoJSON išlieka patikimu, be rūpesčių naudingumo formatu.

Tačiau dideliems duomenų rinkiniams GeoParquet yra objektyviai pranašesnis visose operacinėse kategorijose. Jis suteikia mažesnį failų dydį, žymiai mažesnį saugojimo išteklių poreikį, beveik momentinius erdvinius skaitymus ir natūralų integravimą su šiuolaikinėmis debesų duomenų sandėlių sistemomis.

Jei jūsų geoduomenų kanalai skausmingai nešioja per didelių GeoJSON failų svorį, perėjimas prie GeoParquet yra vienas efektyviausių infrastruktūros patobulinimų, kuriuos galite atlikti.

Dažnai užduodami klausimai (DUK)

Q1. Ar GeoParquet yra oficialiai pripažintas GIS standartas? Taip, GeoParquet yra oficialus atviras standartas, prižiūrimas pagal Atvirojo Geoprostoro Konsorciumo (OGC) gairės.

Q2. Ar galiu tiesiogiai atvaizduoti GeoParquet failą žiniatinklio žemėlapių bibliotekose, tokių kaip Leaflet ar Mapbox GL JS? Nors jis nėra natūraliai apdorojamas kaip GeoJSON, galite atvaizduoti GeoParquet naršyklėse naudojant WebAssembly paketus, pvz., parquet-wasm, arba konvertuojant failus į vektorines plyteles (PMTiles/MVT) įkėlimo metu.

Q3. Ar GeoParquet palaiko kelias koordinačių nuorodų sistemas (CRS)? Taip, skirtingai nuo GeoJSON (kuris griežtai apribotas WGS 84 / EPSG:4326 pagal RFC 7946), GeoParquet leidžia naudoti pasirinktines CRS apibrėžtis tiesiai įterptas į failo metaduomenis.

Q4. Kaip GeoParquet lyginamas su FlatGeobuf dideliems erdviniams duomenų rinkiniams? FlatGeobuf yra optimizuotas srautinėms erdvinių elementų transliacijoms tiesiai į interaktyvias žemėlapių svetaines naudojant R-Tree erdvinių indeksavimą, o GeoParquet sukurtas aukštos našumo stulpelinėms analizėms, suspaudimui ir milžiniškam duomenų ežero sandėliavimui.

Q5. Ar galiu atidaryti GeoParquet failus darbalaukio GIS programinėje įrangoje, pvz., QGIS? Taip, modernios QGIS versijos (3.28 ir naujesnės) palaiko GeoParquet failų vilkimą, numetimą, peržiūrą ir stilių taikymą be papildomų trečiųjų šalių įskiepių.

Taip pat žiūrėkite

GIS failų formatai FileFormat.com

Top 5 GIS failų formatai Google Maps

Failų formatų naujienos

Failų formatų forumai