GeoParquet vs. GeoJSON: Який формат GIS кращий для великих наборів даних?

Якщо ви коли‑небудь намагалися відкрити 2 ГБ файл GeoJSON у QGIS або завантажити багатомільйонний файл полігональних меж у інтерактивну карту, ви вже знаєте відчуття, коли екран зависає, а програма падає через нестачу пам’яті.

Більше десяти років GeoJSON служить універсальною лінгва‑франка веб‑картографії. Він прозорий, зрозумілий людям і підтримується «з коробки» майже всіма бібліотеками веб‑карт та REST‑API в інтернеті.

Проте сучасні робочі процеси GIS виглядають радикально інакше, ніж у 2008 році. Сьогодні геопросторові фахівці регулярно обробляють гігабайти (або терабайти) телеметрії мобільності IoT, національні контури будівель, сегментаційні маски, отримані зі супутників, та високочастотні кліматичні сітки.

При застосуванні до наборів даних такого масштабу GeoJSON не лише сповільнюється — він повністю створює вузьке місце в архітектурі даних.

Зустрічайте GeoParquet, відкрите, стандартизоване геопросторове розширення Apache Parquet, яке інкубується в межах Open Geospatial Consortium (OGC).

У цьому всебічному посібнику ми порівнюємо GeoParquet і GeoJSON за архітектурою, ефективністю зберігання, пропускною здатністю читання/запису, готовністю до хмари та ергономікою для розробників, щоб відповісти на важливе питання: Який формат слід обрати для великих наборів даних?

1. Структурна архітектура: Текст проти бінарного колонкового

Щоб зрозуміти, чому ці формати працюють так по-різному у масштабі, потрібно заглянути під капот і подивитися, як кожен з них представляє координатні значення та табличні метадані.

+--------------------------------------------------------------+
| Метрика оцінки |
| **Формат даних** |
| **Геометричне представлення** |
| **Коефіцієнт стискання** |
| **Проекція стовпців** |
+--------------------------------------------------------------+
                               VS
+--------------------------------------------------------------+
| **Протиспрямування просторових предикатів** |
| **Хмарне сховище об’єктів (S3/GCS)** |
| **Людська читабельність** |
| **Підтримка веб‑браузерів** |
| **Орган стандартизації** |
+--------------------------------------------------------------+

GeoJSON: Орієнтований на рядки, текстово-кодований JSON

GeoJSON представляє дані як масив JSON‑об’єктів. Кожна окрема ознака явно повторює ключі атрибутів поряд з масивом рядково‑закодованих чисел з плаваючою комою:

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

Оскільки GeoJSON є текстовим:

• Повторювані схеми: Назви полів, такі як "properties", "type" та "coordinates", повторюються мільйони разів, збільшуючи розмір вихідного файлу.
• Витратне перетворення рядка у число з плаваючою комою: Ваш процесор повинен розбирати текстові символи ("-", "9", "7", ".", "7"...) у 64‑бітові числа з подвійною точністю IEEE перед виконанням будь‑якої просторової операції.
• Монолітні вимоги до читання: Стандартні JSON‑парсери повинні завантажити весь файл у пам’ять для побудови Document Object Model (DOM). Читання одного атрибуту вимагає розбору кожної окремої ознаки.

GeoParquet: Орієнтований на стовпці, бінарно-кодовані дані

GeoParquet безпосередньо базується на Apache Parquet, зберігаючи просторові таблиці стовпчик за стовпчиком, а не рядок за рядком.

Атрибути, такі як county, зберігаються у безперервних блоках, що дозволяє застосовувати передові методи стиснення, такі як кодування довжини послідовностей (RLE), бітове пакування та словникове стиснення. Геометричні дані стандартизовані як Well-Known Binary (WKB), супроводжуються вбудованими JSON‑метаданими, що описують системи просторових посилань (CRS), обмежувальні коробки та типи геометрій.

Оскільки GeoParquet є бінарним та колонковим:

• Нульова вартість розбору координат: Геометрії зберігаються безпосередньо у бінарній формі, обходячи дорогі перетворення рядок‑у‑число (string-to-float).
• Проекційне спускання: Якщо ваш подальший робочий процес потребує лише стовпці county та pop_density, читач отримує лише ці байтові зсуви з диска або S3, повністю пропускаючи стовпець геометрії.
• Розбиття на групи рядків: Файли Parquet розбивають записи на автономні “Row Groups” (зазвичай по 100 000–1 000 000 рядків у кожній) з повними статистиками мін/макс для кожного стовпця.

2. Порівняння один до одного: Основні метрики

3. Ефективність зберігання та бенчмарки розмірів файлів

При масштабуванні від тисяч до мільйонів записів розбіжності у використанні сховища різко збільшуються.

У стандартних бенчмарках, що використовують реальні відкриті просторові дані (наприклад, контури будівель OpenStreetMap, межі TIGER перепису США та глобальні журнали AIS кораблів), GeoParquet регулярно досягає зниження обсягу сховища від 70% до 85% порівняно з сирим GeoJSON і перевершує .geojson.gz ще на від 20% до 40%.

Чому GeoParquet настільки менший?

1. Dictionary Encoding: Повторювані рядкові атрибути (наприклад, коди штатів, класифікації землекористування) індексуються у малі цілочисельні покажчики замість того, щоб зберігатися повторно у вигляді довгих рядків.
2. Compact Binary Coordinates: 2D‑точка у GeoJSON займає приблизно 30‑45 байт ASCII‑тексту ([-122.4194155, 37.7749295]). У WKB та сама пара координат вимагає точно 16 байт.
3. Modern Compression Algorithms: Zstandard (Zstd) та Snappy стискають колонкові масиви байтів значно ефективніше, ніж стандартний Gzip може стискати чергуваний рядковий текст.

4. Продуктивність запитів та хмарно‑нативні робочі процеси

Головний фактор, що відрізняє великі набори даних, — це не лише сховище, а затримка запитів та використання пам’яті.

1. Вибіркове читання за допомогою проекції стовпців

Уявіть собі національний набір даних про ділянки обсягом 15 ГБ, що містить 60 атрибутів (імена власників, податкові ідентифікатори, історія прав власності, коди зонування та складні багатокутні межі).

• У GeoJSON: Якщо ви хочете обчислити середню оцінену вартість майна за поштовим індексом, ваш аналітичний движок має завантажити та розпарсити всі 15 ГБ, включаючи мільйони складних вершин меж.
• У GeoParquet: Аналітичні движки, такі як DuckDB, Apache Sedona, Polars або AWS Athena, читають лише стовпці zip_code та assessed_value. Замість передачі 15 ГБ, ваш движок завантажує та сканує менше 80 МБ.

2. HTTP‑запити діапазону в хмарному сховищі

GeoParquet працює безперешкодно як хмарний геопросторовий формат.

Оскільки файли Parquet зберігають внутрішні зміщення та метадані у футері файлу, клієнтські бібліотеки можуть надсилати HTTP GET Range: bytes=... запити до хмарних сховищ об’єктів, таких як Amazon S3, Google Cloud Storage або Azure Blob Storage. Замість завантаження цілого багатогігабайтного файлу, клієнт читає футер, визначає точні зміщення байтів, де розташовані потрібні записи, і завантажує лише необхідні підмножини.

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. Екосистема програмного забезпечення та підтримка інструментів

Історично головна перевага GeoJSON полягала у всезагальній підтримці інструментів. Хоча це й досі вірно для браузерних середовищ, екосистема GeoParquet швидко зріла:

• Desktop GIS: Рідна підтримка читання/запису в QGIS 3.28+, ArcGIS Pro та GDAL/OGR 3.5+.
• Analytical Engines & Languages: Швидкі векторизовані можливості читання/запису в Python (GeoPandas, pyarrow), R (sf), DuckDB (через просторове розширення), Apache Sedona та Snowflake.
• Big Data Pipelines: Рідна інтеграція з Apache Spark, Trino, Presto та Databricks.
• Client-Side Web Maps: Легкі бібліотеки WebAssembly (наприклад parquet-wasm та duckdb-wasm) тепер дозволяють веб-браузерам запитувати файли GeoParquet безпосередньо на клієнтських пристроях без спеціального GIS‑проміжного сервера.

6. Практична матриця рішень: коли який варіант використовувати?

                                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

Виберіть GeoJSON, якщо:

• Ваш набір даних має розмір від 50 МБ до 100 МБ.
• Ви повертаєте легкі відповіді навантаження від REST API до клієнтів фронтенду.
• Ви створюєте легкі веб‑карти за допомогою Leaflet, MapLibre або Mapbox GL JS без проміжних шарів трансляції.
• Вам потрібне швидке ручне редагування або перевірка у стандартному редакторі коду чи тексту.

Виберіть GeoParquet, якщо:

• Ваш набір даних перевищує 100 МБ або містить сотні тисяч складних просторових об’єктів.
• Ви зберігаєте векторні активи у хмарному сховищі об’єктів (S3, GCS, MinIO, Azure Blob).
• Ви виконуєте просторову SQL‑аналітику, інженерію ознак або конвеєри машинного навчання, використовуючи Python, DuckDB, Spark або Databricks.
• Ви хочете знизити витрати на зберігання, уникнути платежів за вихідний трафік і усунути збої пам’яті.

7. Приклад міграції: перетворення GeoJSON у GeoParquet

Перетворення існуючих просторових активів у GeoParquet займає лише кілька рядків коду.

Використання 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")

Використання GDAL / OGR (CLI)

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

Використання 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. Підсумок: Висновок щодо великих наборів даних

Для невеликих наборів даних і прямих веб‑кінцевих точок GeoJSON залишається надійним, безпроблемним форматом утиліти.

Проте, для великих наборів даних GeoParquet об’єктивно переважає у всіх операційних категоріях. Він забезпечує менший розмір файлів, значно нижчі витрати на зберігання, майже миттєве читання просторових даних і вбудовану інтеграцію з сучасними хмарними сховищами даних.

Якщо ваші геопросторові конвеєри стогнуть під вагою надмірно великих файлів GeoJSON, перехід на GeoParquet — одне з найефективніших оновлень інфраструктури, які ви можете здійснити.

Поширені запитання (FAQ)

Q1. Чи є GeoParquet офіційно визнаним GIS-стандартом? Так, GeoParquet — офіційний відкритий стандарт, який підтримується під керівництвом Open Geospatial Consortium (OGC).

Q2. Чи можу я безпосередньо відобразити файл GeoParquet у веб‑картографічних бібліотеках, таких як Leaflet або Mapbox GL JS? Хоча він не парситься нативно, як GeoJSON, ви можете відображати GeoParquet у браузерах за допомогою пакетів WebAssembly, таких як parquet-wasm, або конвертуючи файли у векторні тайли (PMTiles/MVT) під час завантаження.

Q3. Чи підтримує GeoParquet кілька систем координат (CRS)? Так, на відміну від GeoJSON (який суворо обмежений WGS 84 / EPSG:4326 згідно RFC 7946), GeoParquet дозволяє визначати власні CRS безпосередньо у вбудованих метаданих файлу.

Q4. Як GeoParquet порівнюється з FlatGeobuf для великих просторових наборів даних? FlatGeobuf оптимізовано для потокової передачі просторових об’єктів безпосередньо до інтерактивних веб‑карт за допомогою просторового індексування R-Tree, тоді як GeoParquet розроблений для високопродуктивної колонкової аналітики, стиснення та масштабного сховища даних у озерах.

Q5. Чи можу я відкривати файли GeoParquet у настільному ПЗ GIS, такому як QGIS? Так, сучасні версії QGIS (версія 3.28 і вище) підтримують перетягування, перегляд та стилізацію файлів GeoParquet без потреби у сторонніх плагінах.

Дивіться також

Формати GIS файлів на FileFormat.com

Топ‑5 форматів GIS файлів для Google Maps

Новини про формати файлів

Форуми про формати файлів