Последнее обновление: 2026-11-04

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

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. бинарный колонный

Чтобы понять, почему эти форматы работают так по‑разному в масштабах, необходимо заглянуть под капот и посмотреть, как каждый из них представляет координатные значения и табличные метаданные.

+--------------------------------------------------------------+
| Метрика оценки |
| **Формат данных** |
| **Представление геометрии** |
| **Коэффициент сжатия** |
| **Проекция столбцов** |
+--------------------------------------------------------------+
                               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 должны загрузить весь файл в память для построения модели объекта документа (DOM). Чтение одного атрибута требует парсинга каждого отдельного объекта.

GeoParquet: ориентированный по колонкам, бинарно-кодированные данные

GeoParquet строится непосредственно на Apache Parquet, храня пространственные таблицы столбец за столбцом, а не строка за строкой.

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

Поскольку GeoParquet является бинарным и колонковым:

  • Zero Coordinate Parsing Cost: Геометрии хранятся непосредственно в бинарной форме, обходя дорогие преобразования строк в числа с плавающей точкой.
  • Projection Pushdown: Если ваш последующий рабочий процесс нуждается только в столбцах county и pop_density, читатель получает только эти байтовые смещения с диска или S3, полностью пропуская столбец геометрии.
  • Row-Group Partitioning: Файлы Parquet разбивают записи на автономные “Row Groups” (обычно по 100 000–1 000 000 строк каждая) с полными статистиками min/max для каждого столбца.

2. Сравнение «лицом к лицу»: основные метрики

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. Эффективность хранения и показатели размеров файлов

При масштабировании от тысяч до миллионов записей различия в объёме хранилища резко увеличиваются.

В стандартных тестах с использованием реальных открытых пространственных данных (например, контуров зданий OpenStreetMap, границ TIGER переписи США и глобальных логов AIS судов), GeoParquet регулярно достигает сокращения объёма хранения от 70 % до 85 % по сравнению с необработанным GeoJSON и опережает .geojson.gz ещё на от 20 % до 40 %.

Почему GeoParquet так сильно меньше?

  1. Dictionary Encoding: Повторяющиеся строковые атрибуты (например, коды штатов, классификации землепользования) индексируются в небольшие целочисленные указатели вместо того, чтобы храниться многократно в виде длинных строк.
  2. Compact Binary Coordinates: 2‑мерная точка в 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 быстро развилась:

  • Настольные ГИС: Нативная поддержка чтения/записи в QGIS 3.28+, ArcGIS Pro и GDAL/OGR 3.5+.
  • Аналитические движки и языки: Быстрые векторные возможности чтения/записи в Python (GeoPandas, pyarrow), R (sf), DuckDB (через пространственное расширение), Apache Sedona и Snowflake.
  • Конвейеры больших данных: Нативная интеграция с Apache Spark, Trino, Presto и Databricks.
  • Веб‑карты на стороне клиента: Лёгкие библиотеки 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

Новости форматов файлов

Форумы форматов файлов