Pēdējoreiz atjaunināts: 2026-11-04

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

GeoParquet vs. GeoJSON: Kurš GIS formāts ir labāks lieliem datu kopumiem?

Ja jebkad esat mēģinājis atvērt 2 GB GeoJSON failu QGIS vai ielādēt vairāk nekā miljonu rindu daudzstūru robežas failu interaktīvā kartē, jau zināt, kāda ir noslīdes sajūta – iesaldēts ekrāns un atmiņas pārsnieguma avārija.

Vairāk nekā desmit gadu GeoJSON ir kalpojusi kā universāla pasaules valoda tīmekļa kartogrāfijā. Tā ir caurspīdīga, cilvēkiem lasāma, un ir atbalstīta jau no sākuma gandrīz katras tīmekļa kartēšanas bibliotēkas un REST API internetā.

Tomēr mūsdienu GIS darba plūsmas izskatās radikāli atšķirīgi nekā 2008. gadā. Šodienas ģeotelpiskie praktiķi regulāri apstrādā gigabaitus (vai terabaitus) IoT mobilitātes telemetrijas, valsts mēroga ēku kontūru, satelītu izceltas segmentācijas maskas un augstas frekvences klimata režģus.

Kad tas tiek piemērots datu kopām šādā mērogā, GeoJSON ne tikai palēninās — tas pilnīgi ierobežo datu arhitektūras.

Ienāk GeoParquet, atvērta, standartizēta ģeotelpiskā paplašinājuma uz Apache Parquet, kas tiek izstrādāta Open Geospatial Consortium (OGC) ietvaros.

Šajā visaptverošajā ceļvedī mēs salīdzinām GeoParquet un GeoJSON arhitektūras, glabāšanas efektivitātes, lasīšanas/rakstīšanas caurlaidības, mākoņa gatavības un izstrādātāju ergonomikas ziņā, lai atbildētu uz svarīgu jautājumu: Kuru formātu izvēlēties lieliem datu kopumiem?

1. Struktūrālā arhitektūra: Teksts pret bināro kolonnu

Lai izprastu, kāpēc šie formāti darbojas tik atšķirīgi lielā mērogā, ir jāskata zem virsmas, kā katrs no tiem attēlo koordinātu vērtības un tabulāro metadatu.

+--------------------------------------------------------------+
| Novērtējuma metriks |
| **Datu formāts** |
| **Ģeometrijas attēlojums** |
| **Saspiešanas attiecība** |
| **Kolonnas projekcija** |
+--------------------------------------------------------------+
                               VS
+--------------------------------------------------------------+
| **Telpiskā predikāta pārsūtīšana** |
| **Mākoņa objektu glabātuve (S3/GCS)** |
| **Cilvēka lasāmība** |
| **Tīmekļa pārlūkprogrammu atbalsts** |
| **Standartizācijas institūcija** |
+--------------------------------------------------------------+

GeoJSON: Rindu-orientēts, teksta kodēts JSON

GeoJSON attēlo datus kā JSON objektu masīvu. Katrs vienīgais elements skaidri atkārto atribūtu atslēgas kopā ar virkņu kodētām peldošā komata skaitļu masīvām:

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

Tā kā GeoJSON ir teksta balstīts:

  • Atkārtoti shēmas: Lauku nosaukumi, piemēram, "properties", "type" un "coordinates", tiek atkārtoti miljoniem reižu, palielinot neapstrādāta faila izmēru.
  • Dārga virknes‑uz‑peldošā komata konversija: Jūsu CPU ir jāparsē teksta rakstzīmes ("-", "9", "7", ".", "7"...) uz 64‑bitu IEEE dubultas precizitātes peldošajiem skaitļiem, pirms veic jebkuru telpisko operāciju.
  • Monolītiskas lasīšanas prasības: Standarta JSON parsētājiem jāielādē viss fails atmiņā, lai izveidotu Dokumenta Objektu Modeli (DOM). Vienas atribūta lasīšana prasa parsēt katru vienu elementu.

GeoParquet: Kolonu-orientēti, bināri kodēti dati

GeoParquet balstās tieši uz Apache Parquet, glabājot telpiskās tabulas kolonnu pa kolonnai, nevis rindas pa rindai.

Tādi atribūti kā county tiek glabāti nepārtrauktos blokos, ļaujot izmantot uzlabotas saspiešanas tehnoloģijas, piemēram, garuma kodēšanu (RLE), bitu paketi un vārdnīcas saspiešanu. Ģeometrijas dati tiek standartizēti kā Well-Known Binary (WKB), kam seko iekļauti JSON metadati, kas detalizē telpisko atsauču sistēmu (CRS), robežkastes un ģeometrijas tipus.

Tā kā GeoParquet ir binārs un kolonnu veidots:

  • Nulles koordinātu parsēšanas izmaksas: Ģeometrijas tiek glabātas tieši binārā formā, apietot dārgas virknes‑uz‑peldošā‑komata konvertācijas.
  • Projekcijas pushdown: Ja jūsu turpmākais darba plūsmas posms vajag tikai county un pop_density kolonnas, lasītājs ielādē tikai šos baitu nobīdes no diska vai S3, pilnīgi izlaidot ģeometrijas kolonnu.
  • Rindu grupas sadalīšana: Parquet faili sadala ierakstus pašpietiekamās "Row Groups" (bieži 100 000 līdz 1 000 000 rindu katrā) ar pilnīgiem min/max statistikas datiem katrai kolonnai.

2. Tieša salīdzinājuma pārskats: Galvenie rādītāji

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. Uzglabāšanas efektivitāte un failu izmēru salīdzinājumi

Kad mērogo no tūkstošiem uz miljoniem ierakstu, glabāšanas atšķirības kļūst dramatiski lielākas.

Standarta veiktspējas testos, izmantojot reālus atvērtus telpiskos ierakstus (piemēram, OpenStreetMap ēku kontūras, ASV Skaitīšanas TIGER robežas un globālos kuģu AIS žurnālus), GeoParquet regulāri sasniedz 70 % līdz 85 % glabāšanas samazinājumu salīdzinājumā ar neapstrādāto GeoJSON, un pārspēj .geojson.gz papildu 20 % līdz 40 %.

Kāpēc GeoParquet ir tik daudz mazāks?

  1. Dictionary Encoding: Atkārtoti teksta atribūti (piemēram, štatu kodi, zemes izmantošanas klasifikācijas) tiek indeksēti kā mazi veseli skaitļu rādītāji, nevis glabāti atkārtoti kā garas virknes.
  2. Compact Binary Coordinates: 2D punkts GeoJSON aizņem apmēram 30 līdz 45 baitus ASCII teksta ([-122.4194155, 37.7749295]). WKB formātā tas pats koordinātu pāris prasa tieši 16 baitus.
  3. Modern Compression Algorithms: Zstandard (Zstd) un Snappy saspiež kolonnu baitu masīvus daudz efektīvāk nekā standarta Gzip spēj saspiest pārklāto rindu balstīto tekstu.

4. Vaicājumu veiktspēja un mākoņdatora dzimtie darba plūsmas

Lielāko atšķirību lieliem datu kopumiem nav tikai glabāšana — tas ir vaicājumu latentums un atmiņas izmantošana.

1. Selektīva lasīšana, izmantojot kolonnu projekciju

Iedomājieties 15 GB valsts zemes gabalu datu kopu, kas satur 60 atribūtus (īpašnieku vārdi, nodokļu ID, īpašuma vēsture, zonēšanas kodi un sarežģītas daudzstūru robežas).

  • GeoJSON formātā: Ja vēlaties aprēķināt vidējo novērtēto īpašuma vērtību katram pasta indeksam, jūsu analītiskajam dzinējam jālejupielādē un jāparsē visi 15 GB, ieskaitot miljoniem sarežģītu robežvirsotņu.
  • GeoParquet formātā: Analītiskie dzinēji, piemēram, DuckDB, Apache Sedona, Polars vai AWS Athena, lasa tikai zip_code un assessed_value kolonnas. Tā vietā, lai pārsūtītu 15 GB, jūsu dzinējs lejupielādē un skenē mazāk nekā 80 MB.

2. HTTP diapazona pieprasījumi mākoņglabā

GeoParquet darbojas nevainojami kā mākoņdatora dzimtā ģeotelpiskā formāts.

Tā kā Parquet faili saglabā iekšējos nobīdes un metadatus savā faila kājenē, klientu bibliotēkas var izsūtīt HTTP GET Range: bytes=... pieprasījumus uz mākoņpakalpojumu krātuvēm, piemēram, Amazon S3, Google Cloud Storage vai Azure Blob Storage. Tā vietā, lai lejupielādētu visu vairāk nekā gigabaitu lielo failu, klients lasa kāju, identificē precīzās baitu nobīdes, kur atrodas attiecīgie ieraksti, un lejupielādē tikai nepieciešamos apakškopumus.

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. Programmatūras ekosistēma un rīku atbalsts

Vēsturiski GeoJSON galvenais priekšrocība bija universāla rīku atbalsts. Lai gan tas joprojām ir patiesi pārlūkprogrammu vidēs, GeoParquet ekosistēma ir strauji attīstījusies:

  • Desktop GIS: Dabisks lasīšanas/rakstīšanas atbalsts QGIS 3.28+, ArcGIS Pro un GDAL/OGR 3.5+.
  • Analytical Engines & Languages: Ātras vektorizētas lasīšanas/rakstīšanas iespējas Python (GeoPandas, pyarrow), R (sf), DuckDB (caur telpisko paplašinājumu), Apache Sedona un Snowflake.
  • Big Data Pipelines: Dabiska integrācija ar Apache Spark, Trino, Presto un Databricks.
  • Client-Side Web Maps: Vieglas WebAssembly bibliotēkas (piemēram, parquet-wasm un duckdb-wasm) tagad ļauj tīmekļa pārlūkprogrammām vaicāt GeoParquet failus tieši klienta ierīcēs bez īpaša GIS starpniekservera.

6. Praktiska lēmumu matrica: kad izmantot kādu?

                                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

Izvēlies GeoJSON, ja:

  • Jūsu datu kopas lielums ir no 50 MB līdz 100 MB.
  • Jūs atgriežat vieglas slodzes atbildes no REST API uz priekšējām klientēm.
  • Jūs veidojat vieglas tīmekļa kartes, izmantojot Leaflet, MapLibre vai Mapbox GL JS, bez starpposma tulkošanas slāņiem.
  • Jums ir nepieciešama ātra manuāla rediģēšana vai pārbaude standarta koda vai teksta redaktorā.

Izvēlies GeoParquet, ja:

  • Jūsu datu kopas apjoms pārsniedz 100 MB vai tā satur simtiem tūkstošu sarežģītu telpisko elementu.
  • Jūs glabājat vektoru aktīvus mākoņa objektu glabātuvē (S3, GCS, MinIO, Azure Blob).
  • Jūs veicat telpisko SQL analīzi, funkciju izstrādi vai mašīnmācības cauruļvadu, izmantojot Python, DuckDB, Spark vai Databricks.
  • Jūs vēlaties samazināt glabāšanas izmaksas, izvairīties no tīkla izvadīšanas maksām un novērst atmiņas avārijas.

7. Migrācijas piemērs: GeoJSON konvertēšana uz GeoParquet

Esošo telpisko aktīvu konvertēšana uz GeoParquet prasa tikai dažas koda rindas.

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

Izmantojot GDAL / OGR (CLI)

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

Lietojot 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. Kopsavilkums: Spriedums par lieliem datu kopumiem

Mazām datu kopām un tiešiem tīmekļa galapunktiem GeoJSON joprojām ir uzticams, bezrūpīgs utilītformāts.

Tomēr, lielām datu kopām GeoParquet ir objektīvi pārāks katrā operacionālajā kategorijā. Tas nodrošina mazākus failu apjomus, ievērojami zemākas glabāšanas pārklas, gandrīz tūlītējus telpiskos nolasījumus un iebūvētu integrāciju ar mūsdienīgiem mākoņa datu noliktavām.

Ja jūsu ģeotelpiskie cauruļvadi raud zem pārāk lielu GeoJSON failu svara, pāreja uz GeoParquet ir viens no visefektīvākajiem infrastruktūras uzlabojumiem, ko varat veikt.

Biežāk uzdotie jautājumi (BUJ)

Q1. Vai GeoParquet ir oficiāli atzīts GIS standarts? Jā, GeoParquet ir oficiāls atvērtais standarts, ko uztur Open Geospatial Consortium (OGC) vadībā.

Q2. Vai es varu tieši attēlot GeoParquet failu tīmekļa kartēšanas bibliotēkās, piemēram, Leaflet vai Mapbox GL JS? Lai gan tas netiek nativi parsēts kā GeoJSON, jūs varat attēlot GeoParquet pārlūkprogrammās, izmantojot WebAssembly pakotnes, piemēram, parquet-wasm, vai pārvēršot failus uz Vektoru flīzēm (PMTiles/MVT) pie uzņemšanas.

Q3. Vai GeoParquet atbalsta vairākas koordinātu atsauces sistēmas (CRS)? Jā, atšķirībā no GeoJSON (kas ir stingri ierobežots uz WGS 84 / EPSG:4326 saskaņā ar RFC 7946), GeoParquet ļauj pielāgotas CRS definīcijas tieši savā iekļautajā faila metadatu.

Q4. Kā GeoParquet salīdzina ar FlatGeobuf lieliem telpiskajiem datu kopumiem? FlatGeobuf ir optimizēts, lai straumētu telpiskās funkcijas tieši uz interaktīvām tīmekļa kartēm, izmantojot R-Tree telpisko indeksēšanu, savukārt GeoParquet ir paredzēts augstas veiktspējas kolonnveida analīzei, kompresijai un milzīgu datu ezeru glabāšanai.

Q5. Vai varu atvērt GeoParquet failus darbvirsmas GIS programmatūrā, piemēram, QGIS? Jā, modernas QGIS versijas (versija 3.28 un jaunākas) atbalsta vilkšanu, nomaišanu, skatīšanu un stilu piemērošanu GeoParquet failiem, neprasot trešo pušu spraudņus.

Skatīt arī

GIS failu formāti vietnē FileFormat.com

Top 5 GIS failu formāti Google Maps

Failu formātu ziņas

Failu formātu forumi