GeoParquet vs. GeoJSON – Wydajność, rozmiar pliku i GIS w chmurze w porównaniu

Ostatnia aktualizacja: 2026-11-04

GeoParquet vs. GeoJSON: Który format GIS jest lepszy dla dużych zbiorów danych?

Jeśli kiedykolwiek próbowałeś otworzyć plik GeoJSON o wielkości 2 GB w QGIS lub wczytać plik granic wielokątów liczący miliony wierszy do interaktywnej mapy, już znasz przytłaczające uczucie zamarzniętego ekranu i awarii z powodu braku pamięci.

Od ponad dekady GeoJSON pełni rolę uniwersalnego lingua franca kartografii internetowej. Jest przejrzysty, czytelny dla człowieka i obsługiwany od razu przez prawie każdą bibliotekę mapowania internetowego oraz API REST w sieci.

Jednak współczesne przepływy pracy GIS wyglądają radykalnie inaczej niż w 2008 roku. Dzisiejsi specjaliści ds. geoprzestrzennych regularnie przetwarzają gigabajty (lub terabajty) danych telemetrycznych IoT, ogólnokrajowe kontury budynków, maski segmentacji pochodzące z satelitów oraz wysokoczęstotliwościowe siatki klimatyczne.

Gdy stosuje się go do zestawów danych o takiej skali, GeoJSON nie tylko spowalnia — całkowicie wąskie gardło w architekturach danych.

Przedstawiamy GeoParquet, otwarte, ustandaryzowane rozszerzenie geoprzestrzenne dla Apache Parquet, rozwijane w ramach Open Geospatial Consortium (OGC).

W tym obszernym przewodniku porównujemy GeoParquet i GeoJSON pod względem architektury, efektywności przechowywania, przepustowości odczytu/zapisu, gotowości do chmury oraz ergonomii dla programistów, aby odpowiedzieć na kluczowe pytanie: Jaki format wybrać dla dużych zbiorów danych?

1. Architektura strukturalna: Tekst vs. Kolumnowy binarny

Aby zrozumieć, dlaczego te formaty zachowują się tak różnie w skali, trzeba zajrzeć pod maskę i zobaczyć, jak każdy z nich reprezentuje wartości współrzędnych oraz metadane tabelaryczne.

+--------------------------------------------------------------+
| Metryka oceny |
| **Format danych** |
| **Reprezentacja geometrii** |
| **Współczynnik kompresji** |
| **Projekcja kolumn** |
+--------------------------------------------------------------+
                               VS
+--------------------------------------------------------------+
| **Przesuwanie predykatu przestrzennego** |
| **Przechowywanie obiektów w chmurze (S3/GCS)** |
| **Czytelność dla człowieka** |
| **Obsługa przeglądarek internetowych** |
| **Organizacja Standaryzacyjna** |
+--------------------------------------------------------------+

GeoJSON: Ukierunkowany na wiersze, tekstowo zakodowany JSON

GeoJSON reprezentuje dane jako tablicę obiektów JSON. Każda pojedyncza cecha explicite powtarza klucze atrybutów wraz z tablicą liczb zmiennoprzecinkowych zakodowanych jako ciągi znaków:

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

Ponieważ GeoJSON jest oparty na tekście:

• Powtarzalne schematy: Nazwy pól takie jak \"properties\", \"type\" i \"coordinates\" są powtarzane miliony razy, zwiększając rozmiar surowego pliku.
• Kosztowna konwersja ciąg-liczba zmiennoprzecinkowa: Twój procesor musi parsować znaki tekstowe (\"-\", \"9\", \"7\", \".\", \"7\"...) na 64‑bitowe liczby zmiennoprzecinkowe podwójnej precyzji IEEE, zanim wykona jakąkolwiek operację przestrzenną.
• Monolityczne wymagania odczytu: Standardowe parsery JSON muszą wczytać cały plik do pamięci, aby zbudować Model Obiektu Dokumentu (DOM). Odczyt jednego atrybutu wymaga parsowania każdej pojedynczej cechy.

GeoParquet: Ukierunkowany na kolumny, binarnie zakodowane dane

GeoParquet opiera się bezpośrednio na Apache Parquet, przechowując tabele przestrzenne kolumna po kolumnie zamiast wiersz po wierszu.

Atrybuty takie jak county są przechowywane w ciągłych blokach, co umożliwia zaawansowane techniki kompresji, takie jak kodowanie długości serii (RLE), pakowanie bitów i kompresja słownikowa. Dane geometryczne są standaryzowane jako Well-Known Binary (WKB), wraz z osadzonymi metadanymi JSON opisującymi układy odniesień przestrzennych (CRS), prostokąty ograniczające i typy geometrii.

Ponieważ GeoParquet jest binarny i kolumnowy:

• Zero kosztu parsowania współrzędnych: Geometrie są przechowywane bezpośrednio w formie binarnej, omijając kosztowne konwersje z łańcucha znaków na liczby zmiennoprzecinkowe.
• Projection Pushdown: Jeśli Twój dalszy przepływ pracy potrzebuje tylko kolumn county i pop_density, czytnik pobiera tylko te offsety bajtowe z dysku lub S3, całkowicie pomijając kolumnę geometrii.
• Podział na grupy wierszy (Row-Group Partitioning): Pliki Parquet dzielą rekordy na samodzielne “Row Groups” (często od 100 000 do 1 000 000 wierszy każda) zawierające pełne statystyki min/max dla każdej kolumny.

2. Porównanie bezpośrednie: Kluczowe metryki

3. Wydajność przechowywania i benchmarki rozmiaru plików

Podczas skalowania od tysięcy do milionów rekordów, różnice w zużyciu pamięci rosną dramatycznie.

W standardowych benchmarkach wykorzystujących rzeczywiste otwarte rekordy przestrzenne (takie jak kontury budynków OpenStreetMap, granice US Census TIGER oraz globalne logi AIS statków), GeoParquet regularnie osiąga 70% do 85% redukcji rozmiaru w porównaniu z surowym GeoJSON i przewyższa .geojson.gz o dodatkowe 20% do 40%.

Dlaczego GeoParquet jest tak dużo mniejszy?

1. Kodowanie słownikowe: Powtarzające się atrybuty tekstowe (np. kody stanów, klasyfikacje użytkowania ziemi) są indeksowane do małych wskaźników całkowitych zamiast być przechowywane wielokrotnie jako długie ciągi znaków.
2. Kompaktowe współrzędne binarne: Punkt 2D w GeoJSON zajmuje około 30 do 45 bajtów tekstu ASCII ([-122.4194155, 37.7749295]). W WKB ta sama para współrzędnych wymaga dokładnie 16 bajtów.
3. Nowoczesne algorytmy kompresji: Zstandard (Zstd) i Snappy kompresują kolumnowe tablice bajtów znacznie skuteczniej niż standardowy Gzip może kompresować przeplatany tekst wierszowy.

4. Wydajność zapytań i natywne przepływy pracy w chmurze

Największym wyróżnikiem dużych zbiorów danych nie jest tylko przechowywanie — to opóźnienie zapytań i wykorzystanie pamięci.

1. Selektywne odczyty poprzez projekcję kolumn

Wyobraź sobie ogólnokrajowy zbiór danych parceli o wielkości 15 GB, zawierający 60 atrybutów (nazwy właścicieli, numery identyfikacyjne podatników, historię akt własności, kody zagospodarowania przestrzennego oraz złożone granice multipoligonów).

• W GeoJSON: Jeśli chcesz obliczyć średnią wycenioną wartość nieruchomości na kod pocztowy, Twój silnik analityczny musi pobrać i przetworzyć całe 15 GB, w tym miliony złożonych wierzchołków granic.
• W GeoParquet: Silniki analityczne takie jak DuckDB, Apache Sedona, Polars lub AWS Athena odczytują tylko kolumny zip_code i assessed_value. Zamiast przesyłać 15 GB, Twój silnik pobiera i skanuje mniej niż 80 MB.

2. Żądania zakresu HTTP w przechowywaniu w chmurze

GeoParquet działa płynnie jako chmurowy natywny format geoprzestrzenny.

Ponieważ pliki Parquet przechowują wewnętrzne offsety i metadane w stopce pliku, biblioteki klienckie mogą wysyłać żądania HTTP GET Range: bytes=... do chmurowych magazynów obiektów, takich jak Amazon S3, Google Cloud Storage czy Azure Blob Storage. Zamiast pobierać cały wielogigabajtowy plik, klient odczytuje stopkę, identyfikuje dokładne offsety bajtów, w których znajdują się odpowiednie rekordy, i pobiera tylko niezbędne podzbiory.

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. Ekosystem oprogramowania i wsparcie narzędziowe

Historycznie główną zaletą GeoJSON była powszechna obsługa narzędzi. Choć wciąż jest to prawdą w środowiskach przeglądarkowych, ekosystem GeoParquet szybko się rozwinął:

• Desktop GIS: Natywna obsługa odczytu/zapisu w QGIS 3.28+, ArcGIS Pro i GDAL/OGR 3.5+.
• Analytical Engines & Languages: Szybkie wektorowe możliwości odczytu/zapisu w Pythonie (GeoPandas, pyarrow), R (sf), DuckDB (poprzez rozszerzenie przestrzenne), Apache Sedona i Snowflake.
• Big Data Pipelines: Natywna integracja z Apache Spark, Trino, Presto i Databricks.
• Client-Side Web Maps: Lekkie biblioteki WebAssembly (takie jak parquet-wasm i duckdb-wasm) umożliwiają teraz przeglądarkom internetowym zapytania do plików GeoParquet bezpośrednio na urządzeniach klienta, bez dedykowanego serwera pośredniczącego GIS.

6. Praktyczna macierz decyzyjna: Kiedy używać którego?

                                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

Wybierz GeoJSON, jeśli:

• Twój zestaw danych ma od 50 MB do 100 MB.
• Zwracasz lekkie odpowiedzi ładunkowe z REST API do klientów front‑end.
• Tworzysz lekkie mapy internetowe przy użyciu Leaflet, MapLibre lub Mapbox GL JS bez pośrednich warstw translacji.
• Potrzebujesz szybkiej ręcznej edycji lub inspekcji w standardowym edytorze kodu lub tekstu.

Wybierz GeoParquet, jeśli:

• Twój zestaw danych przekracza 100 MB lub zawiera setki tysięcy złożonych cech przestrzennych.
• Przechowujesz zasoby wektorowe w chmurowym magazynie obiektów (S3, GCS, MinIO, Azure Blob).
• Uruchamiasz analizy przestrzenne SQL, inżynierię cech lub pipeline’y uczenia maszynowego przy użyciu Pythona, DuckDB, Spark lub Databricks.
• Chcesz obniżyć koszty przechowywania, uniknąć opłat za transfer danych oraz wyeliminować awarie pamięci.

7. Przykład migracji: konwersja GeoJSON do GeoParquet

Konwersja istniejących zasobów przestrzennych do GeoParquet wymaga zaledwie kilku linii kodu.

Używanie Pythona (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")

Używanie GDAL / OGR (CLI)

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

Korzystanie z 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. Podsumowanie: Ocena dużych zestawów danych

Dla małych zestawów danych i bezpośrednich punktów końcowych w sieci, GeoJSON pozostaje niezawodnym, bezproblemowym formatem użytkowym.

Jednak dla dużych zestawów danych GeoParquet jest obiektywnie lepszy we wszystkich kategoriach operacyjnych. Zapewnia mniejsze rozmiary plików, znacznie niższe koszty przechowywania, prawie natychmiastowe odczyty przestrzenne oraz natywną integrację z nowoczesnymi chmurowymi hurtowniami danych.

Jeśli Twoje potoki geoprzestrzenne jęczą pod ciężarem zbyt dużych plików GeoJSON, przejście na GeoParquet jest jednym z najskuteczniejszych ulepszeń infrastruktury, jakie możesz wprowadzić.

Najczęściej zadawane pytania (FAQ)

Q1. Czy GeoParquet jest oficjalnie uznanym standardem GIS? Tak, GeoParquet jest oficjalnym otwartym standardem utrzymywanym pod kierunkiem Open Geospatial Consortium (OGC).

Q2. Czy mogę renderować plik GeoParquet bezpośrednio w bibliotekach mapowania internetowego, takich jak Leaflet lub Mapbox GL JS? Chociaż nie jest on parsowany natywnie jak GeoJSON, możesz renderować GeoParquet w przeglądarkach przy użyciu pakietów WebAssembly, takich jak parquet-wasm, lub konwertując pliki na wektorowe kafelki (PMTiles/MVT) podczas wprowadzania.

Q3. Czy GeoParquet obsługuje wiele układów odniesienia współrzędnych (CRS)? Tak, w przeciwieństwie do GeoJSON (który jest ściśle ograniczony do WGS 84 / EPSG:4326 zgodnie z RFC 7946), GeoParquet pozwala na definiowanie własnych CRS bezpośrednio w osadzonych metadanych pliku.

Pytanie 4. Jak GeoParquet porównuje się do FlatGeobuf w przypadku dużych zbiorów danych przestrzennych? FlatGeobuf jest zoptymalizowany do strumieniowego przesyłania cech przestrzennych bezpośrednio do interaktywnych map internetowych przy użyciu indeksowania przestrzennego R-Tree, podczas gdy GeoParquet jest przeznaczony do wysokowydajnej analityki kolumnowej, kompresji i masowego przechowywania w jeziorach danych.

Pytanie 5. Czy mogę otworzyć pliki GeoParquet w oprogramowaniu GIS na komputerze, takim jak QGIS? Tak, nowoczesne wersje QGIS (wersja 3.28 i wyższe) obsługują przeciąganie, upuszczanie, przeglądanie i stylizowanie plików GeoParquet bez konieczności używania wtyczek firm trzecich.

Zobacz także

Formaty plików GIS na FileFormat.com

Top 5 formatów plików GIS dla Google Maps

Aktualności o formatach plików

Fora o formatach plików