GeoParquet 与 GeoJSON：哪种 GIS 格式更适合大型数据集？

如果你曾尝试在 QGIS 中打开一个 2 GB 的 GeoJSON 文件，或将一个包含数百万行多边形边界的文件加载到交互式地图中，你已经体会到屏幕冻结和内存不足崩溃的那种沉重感。

十多年来，GeoJSON 一直是网络制图的通用语言。它透明、易于阅读，并且几乎所有网络制图库和 REST API 都开箱即用地支持它。

然而，现代 GIS 工作流与 2008 年时截然不同。如今的地理空间从业者常规性地摄取数 GB（甚至 TB）级的物联网移动遥测数据、全国建筑轮廓、卫星衍生的分割掩膜以及高频率的气候网格。

在如此规模的数据集上使用时，GeoJSON 不仅仅是变慢——它会彻底成为数据架构的瓶颈。

引入 GeoParquet，它是一个开放、标准化的地理空间扩展，基于 Apache Parquet，并在开放地理空间联盟（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\" 这样的字段名会被重复数百万次，导致原始文件大小膨胀。
• 昂贵的字符串转浮点转换： 在执行任何空间操作之前，CPU 必须将文本字符（\"-\", \"9\", \"7\", \".\", \"7\"...）解析为 64 位 IEEE 双精度浮点数。
• 单体读取需求： 标准 JSON 解析器必须将整个文件加载到内存中以构建文档对象模型（DOM）。读取单个属性需要解析每一个特征。

GeoParquet：面向列的二进制编码数据

GeoParquet 直接基于 Apache Parquet 构建，以列式而非行式方式存储空间表。

类似 county 的属性存储在连续块中，支持高级压缩技术，如行程长度编码（RLE）、位打包和字典压缩。几何数据采用 Well-Known Binary (WKB) 标准，并附带嵌入的 JSON 元数据，详细说明空间参考系统（CRS）、边界框和几何类型。

因为 GeoParquet 是二进制且列式的：

• 零坐标解析成本: 几何体直接以二进制形式存储，绕过昂贵的字符串转浮点转换。
• 投影下推: 如果下游工作流仅需要 county 和 pop_density 列，读取器只会从磁盘或 S3 中获取 仅 那些字节偏移，完全跳过几何列。
• 行组分区: Parquet 文件将记录拆分为自包含的 “Row Groups”（通常每组 100,000 到 1,000,000 行），并为每列提供最小/最大统计信息。

2. 正面对比：核心指标

3. 存储效率与文件大小基准

当规模从数千条记录扩展到数百万条记录时，存储差异会显著扩大。

在使用真实的开放空间记录（如 OpenStreetMap 建筑轮廓、美国人口普查 TIGER 边界和全球船舶 AIS 日志）的标准基准测试中，GeoParquet 相较于原始 GeoJSON 通常实现 70% 到 85% 的存储减少，并且比 .geojson.gz 额外提升 20% 到 40%。

为什么 GeoParquet 会小这么多？

1. 字典编码: 重复的字符串属性（例如，州代码、土地使用分类）被索引为小整数指针，而不是反复存储为长字符串。
2. 紧凑二进制坐标: GeoJSON 中的二维点大约占用 30 到 45 字节的 ASCII 文本（[-122.4194155, 37.7749295]）。在 WKB 中，同一坐标对恰好需要 16 字节。
3. 现代压缩算法: Zstandard（Zstd）和 Snappy 对列式字节数组的压缩效果远优于标准 Gzip 对交错行文本的压缩。

4. 查询性能与云原生工作流

对于大型数据集来说，最大的区别不仅在于存储——而在于 查询延迟和内存利用率。

1. 通过列投影进行选择性读取

想象一个包含 60 个属性（业主姓名、税号、契约历史、分区代码以及复杂的多多边形边界）的 15 GB 全国地块数据集。

• In GeoJSON: 如果您想计算每个邮政编码的平均评估物业价值，您的分析引擎必须下载并解析全部 15 GB，包括数百万个复杂的边界顶点。
• In GeoParquet: 像 DuckDB、Apache Sedona、Polars 或 AWS Athena 这样的分析引擎仅读取 zip_code 和 assessed_value 列。无需传输 15 GB，您的引擎只下载并扫描不到 80 MB 的数据。

2. 云存储上的 HTTP 范围请求

GeoParquet 作为一种 云原生地理空间格式，可无缝运行。

由于 Parquet 文件在文件尾部存储内部偏移量和元数据，客户端库可以向 Amazon S3、Google Cloud Storage 或 Azure Blob Storage 等云对象存储发出 HTTP GET Range: bytes=... 请求。客户端无需下载整个多千兆字节的文件，而是读取文件尾部，确定相关记录所在的精确字节偏移，然后仅下载所需的子集。

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）。
• 您使用 Python、DuckDB、Spark 或 Databricks 运行空间 SQL 分析、特征工程或机器学习流水线。
• 您希望降低存储成本，避免网络出站费用，并消除内存崩溃。

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. 总结：大数据集的结论

对于小型数据集和直接的 Web 端点，GeoJSON 仍然是可靠、免烦恼的实用格式。

然而，对于大型数据集，GeoParquet 在每个运营类别中客观上都更优。它提供更小的文件体积、显著降低的存储开销、近乎即时的空间读取，以及与现代云数据仓库的原生集成。

如果您的地理空间管道因超大 GeoJSON 文件的负担而喘不过气来，切换到 GeoParquet 是您可以进行的最有效的基础设施升级之一。

常见问题解答（FAQ）

Q1. GeoParquet 是官方认可的 GIS 标准吗？ 是的，GeoParquet 是在开放地理空间联盟（OGC）指导下维护的官方开放标准。

Q2. 我可以在 Leaflet 或 Mapbox GL JS 等网络制图库中直接渲染 GeoParquet 文件吗？ 虽然不像 GeoJSON 那样原生解析，但您可以使用 WebAssembly 包（如 parquet-wasm）在浏览器中渲染 GeoParquet，或在导入时将文件转换为矢量瓦片（PMTiles/MVT）。

Q3. GeoParquet 支持多坐标参考系统（CRS）吗？ 是的，与严格限制为 WGS 84 / EPSG:4326（RFC 7946）的 GeoJSON 不同，GeoParquet 允许在其嵌入的文件元数据中直接定义自定义 CRS。

Q4. GeoParquet 与 FlatGeobuf 在大型空间数据集方面如何比较？ FlatGeobuf 针对使用 R-Tree 空间索引直接流式传输空间要素到交互式网络地图进行了优化，而 GeoParquet 则旨在实现高性能列式分析、压缩以及大规模数据湖仓储。

Q5. 我可以在桌面 GIS 软件如 QGIS 中打开 GeoParquet 文件吗？ 是的，现代版本的 QGIS（3.28 及以上）支持拖拽、查看和样式化 GeoParquet 文件，无需第三方插件。

另见

FileFormat.com 上的 GIS 文件格式

Google Maps 的前 5 大 GIS 文件格式

文件格式新闻

文件格式论坛