Poslední aktualizace: 2026-11-04

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

GeoParquet vs. GeoJSON: Který formát GIS je lepší pro velké datové sady?

Pokud jste někdy zkoušeli otevřít 2 GB soubor GeoJSON v QGIS nebo načíst soubor s polygonovými hranicemi o několika milionech řádků do interaktivní mapy, už víte, jaký to je pocit – zamrzlá obrazovka a pád kvůli nedostatku paměti.

Po více než deset let slouží GeoJSON jako univerzální lingua franca webové kartografie. Je transparentní, čitelný pro člověka a je podporován přímo z krabice téměř každou knihovnou pro webové mapování a REST API na internetu.

Nicméně moderní pracovní postupy GIS se radikálně liší od těch z roku 2008. Dnešní geoprostoroví odborníci pravidelně zpracovávají gigabajty (nebo terabajty) telemetrie IoT mobility, celostátní data o obrysech budov, segmentační masky získané ze satelitů a vysokofrekvenční klimatické mřížky.

Při aplikaci na datové sady v takovém měřítku GeoJSON ne jen zpomaluje – zcela úzké hrdlo představuje pro datové architektury.

Představujeme GeoParquet, otevřenou, standardizovanou geoprostorovou rozšíření pro Apache Parquet, která se vyvíjí v rámci Open Geospatial Consortium (OGC).

V tomto komplexním průvodci porovnáváme GeoParquet a GeoJSON z hlediska architektury, úspornosti úložiště, propustnosti čtení/zápisu, připravenosti na cloud a ergonomie pro vývojáře, abychom odpověděli na klíčovou otázku: Který formát byste měli zvolit pro velké datové sady?

1. Strukturní architektura: Text vs. binární sloupcová

Abyste pochopili, proč se tyto formáty na velkém měřítku chovají tak odlišně, musíte nahlédnout pod kapotu a podívat se, jak každý z nich reprezentuje souřadnicové hodnoty a tabulková metadata.

+--------------------------------------------------------------+
| Metrika hodnocení |
| **Formát dat** |
| **Reprezentace geometrie** |
| **Komprimační poměr** |
| **Projektování sloupců** |
+--------------------------------------------------------------+
                               VS
+--------------------------------------------------------------+
| **Propagace prostorových predikátů** |
| **Cloudové úložiště objektů (S3/GCS)** |
| **Čitelnost pro člověka** |
| **Podpora webových prohlížečů** |
| **Standardizační orgán** |
+--------------------------------------------------------------+

GeoJSON: Řádkově orientovaný, textově kódovaný JSON

GeoJSON představuje data jako pole JSON objektů. Každý jednotlivý prvek explicitně opakuje klíče atributů vedle pole řetězcově kódovaných desetinných čísel:

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

Protože GeoJSON je textově založený:

  • Opakující se schémata: Název polí jako "properties", "type" a "coordinates" se opakují milionykrát, což nafukuje velikost surového souboru.
  • Nákladná konverze řetězec‑na‑float: Váš procesor musí parsovat textové znaky ("-", "9", "7", ".", "7"...) na 64‑bitová IEEE double‑precision floating‑point čísla, než provede jakoukoli prostorovou operaci.
  • Monolitické požadavky na čtení: Standardní JSON parsery musí načíst celý soubor do paměti, aby vytvořily Document Object Model (DOM). Čtení jednoho atributu vyžaduje parsování každého jednotlivého prvku.

GeoParquet: Sloupcově orientovaný, binárně kódovaná data

GeoParquet staví přímo na Apache Parquet, ukládá prostorové tabulky sloupec po sloupci místo řádek po řádku.

Atributy jako county jsou uloženy v souvislých blocích, což umožňuje pokročilé kompresní techniky jako kódování běhu (RLE), bitové balení a slovníkovou kompresi. Geometrická data jsou standardizována jako Well-Known Binary (WKB), doprovázena vloženými JSON metadaty popisujícími systémy prostorových referencí (CRS), ohraničující rámečky a typy geometrie.

Protože GeoParquet je binární a sloupcový:

  • Nulová cena parsování souřadnic: Geometrie jsou uloženy přímo v binární formě, obcházejí nákladné konverze řetězců na čísla s plovoucí desetinnou čárkou.
  • Pushdown projekce: Pokud váš následný pracovní tok potřebuje pouze sloupce county a pop_density, čtečka načte pouze tyto bajtové offsety z disku nebo S3, zcela přeskočící sloupec geometrie.
  • Rozdělení do Row-Group: Soubory Parquet rozdělují záznamy do samostatných “Row Groups” (často 100 000 až 1 000 000 řádků každá) s kompletními min/max statistikami pro každý sloupec.

2. Přímé srovnání: Klíčové metriky

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. Účinnost úložiště a benchmarky velikosti souborů

Při škálování od tisíců až po miliony záznamů se rozdíly ve skladování dramaticky zvětšují.

Ve standardních benchmarkech využívajících reálné otevřené prostorové záznamy (jako jsou obrysy budov z OpenStreetMap, hranice US Census TIGER a globální lodní AIS záznamy) GeoParquet rutinně dosahuje 70 % až 85 % úspory úložiště ve srovnání s čistým GeoJSON a překonává .geojson.gz o dalších 20 % až 40 %.

Proč je GeoParquet tak mnohem menší?

  1. Dictionary Encoding: Opakující se řetězcové atributy (např. kódy států, klasifikace využití půdy) jsou indexovány do malých celočíselných ukazatelů místo opakovaného ukládání jako dlouhé řetězce.
  2. Compact Binary Coordinates: 2D bod v GeoJSON zabírá přibližně 30 až 45 bajtů ASCII textu ([-122.4194155, 37.7749295]). Ve formátu WKB vyžaduje stejný pár souřadnic přesně 16 bajtů.
  3. Modern Compression Algorithms: Zstandard (Zstd) a Snappy komprimují sloupcové bajtové pole mnohem efektivněji než standardní Gzip dokáže komprimovat prokládaný text založený na řádcích.

4. Výkon dotazů a cloudově nativní pracovní postupy

Největším rozdílem pro velké datové sady není jen úložiště – jde o latenci dotazů a využití paměti.

1. Selektivní čtení pomocí sloupcové projekce

Představte si národní dataset parcel o velikosti 15 GB obsahující 60 atributů (jména vlastníků, daňová ID, historie listin, územní kódy a složité multipolygonové hranice).

  • V GeoJSON: Pokud chcete vypočítat průměrnou oceněnou hodnotu nemovitosti podle poštovního směrovacího čísla, váš analytický engine musí stáhnout a parsovat celých 15 GB, včetně milionů složitých vrcholů hranic.
  • V GeoParquet: Analytické enginy jako DuckDB, Apache Sedona, Polars nebo AWS Athena čtou pouze sloupce zip_code a assessed_value. Místo přenosu 15 GB váš engine stáhne a prohledá méně než 80 MB.

2. HTTP požadavky na rozsahy v cloudovém úložišti

GeoParquet funguje bezproblémově jako cloud-native geoprostorový formát.

Protože soubory Parquet ukládají interní offsety a metadata do patičky souboru, knihovny klienta mohou odesílat HTTP GET Range: bytes=... požadavky na cloudové úložiště objektů jako Amazon S3, Google Cloud Storage nebo Azure Blob Storage. Místo stažení celého multi‑gigabajtového souboru klient načte patičku, identifikuje přesné offsety bajtů, kde se nacházejí relevantní záznamy, a stáhne pouze požadované podmnožiny.

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. Softwarový ekosystém a podpora nástrojů

Historicky byl hlavní výhodou GeoJSON univerzální podpora nástrojů. I když to platí i pro prohlížečová prostředí, ekosystém GeoParquet se rychle vyvíjí:

  • Desktop GIS: Nativní podpora čtení/zápisu v QGIS 3.28+, ArcGIS Pro a GDAL/OGR 3.5+.
  • Analytical Engines & Languages: Rychlé vektorové čtení/zápisové schopnosti napříč Pythonem (GeoPandas, pyarrow), R (sf), DuckDB (prostřednictvím prostorového rozšíření), Apache Sedona a Snowflake.
  • Big Data Pipelines: Nativní integrace napříč Apache Spark, Trino, Presto a Databricks.
  • Client-Side Web Maps: Lightweight WebAssembly libraries (such as parquet-wasm and duckdb-wasm) now allow web browsers to query GeoParquet files directly on client devices without a dedicated GIS middleware server.

6. Praktická rozhodovací matice: Kdy použít který?

                                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

Zvolte GeoJSON, pokud:

  • Váš dataset je menší než 50 MB až 100 MB.
  • Vracíte lehké odpovědi payloadu z REST API front-endovým klientům.
  • Vytváříte lehké webové mapy pomocí Leaflet, MapLibre nebo Mapbox GL JS bez mezilehlých překladových vrstev.
  • Potřebujete rychlé ruční úpravy nebo kontrolu ve standardním editoru kódu nebo textu.

Zvolte GeoParquet, pokud:

  • Váš dataset přesahuje 100 MB nebo obsahuje stovky tisíc složitých prostorových prvků.
  • Ukládáte vektorová aktiva do cloudového objektového úložiště (S3, GCS, MinIO, Azure Blob).
  • Provádíte prostorovou SQL analytiku, feature engineering nebo pipeline strojového učení pomocí Pythonu, DuckDB, Spark nebo Databricks.
  • Chcete snížit náklady na úložiště, vyhnout se poplatkům za odchozí síťový provoz a eliminovat pády paměti.

7. Příklad migrace: Převod GeoJSON na GeoParquet

Převod existujících prostorových aktiv na GeoParquet vyžaduje jen několik řádků kódu.

Použití Pythonu (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")

Použití GDAL / OGR (CLI)

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

Používání 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. Shrnutí: Verdikt o velkých datových sadách

Pro malé datasety a přímé webové koncové body zůstává GeoJSON spolehlivým, bezproblémovým utilitním formátem.

Nicméně, pro velké datasety je GeoParquet objektivně nadřazený ve všech provozních kategoriích. Poskytuje menší velikost souborů, výrazně nižší úložnou režii, téměř okamžité prostorové čtení a nativní integraci s moderními cloudovými datovými sklady.

Pokud vaše geoprostorové pipeliney trpí pod tíhou nadměrných souborů GeoJSON, přechod na GeoParquet je jedním z nejúčinnějších vylepšení infrastruktury, které můžete provést.

Často kladené otázky (FAQ)

Q1. Je GeoParquet oficiálně uznávaný GIS standard? Ano, GeoParquet je oficiální otevřený standard spravovaný pod vedením Open Geospatial Consortium (OGC).

Q2. Můžu přímo vykreslit soubor GeoParquet v knihovnách pro webové mapování jako Leaflet nebo Mapbox GL JS? I když není nativně parsován jako GeoJSON, můžete GeoParquet v prohlížečích vykreslovat pomocí WebAssembly balíčků jako parquet-wasm nebo převodem souborů na vektorové dlaždice (PMTiles/MVT) při ingestování.

Q3. Podporuje GeoParquet více souřadnicových referenčních systémů (CRS)? Ano, na rozdíl od GeoJSON (který je přísně omezen na WGS 84 / EPSG:4326 podle RFC 7946), GeoParquet umožňuje vlastní definice CRS přímo v metadatech vložených do souboru.

Q4. Jak GeoParquet porovnává s FlatGeobuf pro velké prostorové datové sady? FlatGeobuf je optimalizován pro streamování prostorových prvků přímo do interaktivních webových map pomocí R-Tree prostorového indexování, zatímco GeoParquet je navržen pro vysoce výkonnou sloupcovou analytiku, kompresi a masivní skladování v datových jezerech.

Q5. Mohu otevřít soubory GeoParquet v desktopovém GIS softwaru jako QGIS? Ano, moderní verze QGIS (verze 3.28 a vyšší) podporují přetahování, upouštění, prohlížení a stylování souborů GeoParquet bez nutnosti třetích stran pluginů.

Viz také

Formáty GIS souborů na FileFormat.com

Top 5 GIS formátů souborů pro Google Maps

Novinky o formátech souborů

Fóra o formátech souborů