GeoParquet vs. GeoJSON: Кой GIS формат е по-добър за големи набори от данни?

Ако някога сте опитвали да отворите 2 GB 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 е бинарен и колоночно структуриран:

• Нулев разход за парсиране на координати: Геометрите се съхраняват директно в бинарна форма, заобикаляйки скъпите преобразувания от низ към число с плаваща запетая.
• Натискане на проекцията: Ако вашият последващ работен процес се нуждае само от колоните county и pop_density, четачът извлича само тези байтови отмествания от диск или S3, напълно пропускайки колоната с геометрия.
• Разделяне по Row-Group: 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 GB, съдържащ 60 атрибута (имена на собственици, данъчни идентификационни номера, история на имотните документи, зониращи кодове и сложни многополигонални граници).

• В GeoJSON: Ако искате да изчислите средната оценена стойност на имотите по пощенски код, вашият аналитичен двигател трябва да изтегли и анализира целите 15 GB, включително милиони сложни върхове на граници.
• В GeoParquet: Аналитичните двигатели като DuckDB, Apache Sedona, Polars или AWS Athena четат само колоните zip_code и assessed_value. Вместо да прехвърлят 15 GB, вашият двигател изтегля и сканира по-малко от 80 MB.

2. HTTP Range заявки в облачно съхранение

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 се разви бързо:

• Настолен GIS: Вградено поддържане за четене/писане в 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 MB до 100 MB.
• Връщате леки отговори с полезен товар от REST API към клиентите на фронтенда.
• Създавате леки уеб карти, използвайки Leaflet, MapLibre или Mapbox GL JS, без междинни слоеве за превод.
• Необходима ви е бърза ръчна редакция или проверка в стандартен кодов или текстов редактор.

Изберете GeoParquet, ако:

• Вашият набор от данни надвишава 100 MB или съдържа стотици хиляди сложни пространствени обекти.
• Съхранявате векторни активи в облачно обектно съхранение (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 или като конвертирате файловете във Vector Tiles (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

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

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