第02章 技术栈地图与数据层
本章导读
分析链路的第一段是数据怎么落地，它也决定后面存储与服务怎么选。本章对应原报告 3.1 节与 3.2 节（含 3.2.1—3.2.4）：先给出一张七层技术栈地图，逐层说明选型关键，再落到数据层——为什么 GeoParquet 成为分析默认、COG 与 Zarr 怎么分工、3D Tiles 处在什么状态、点云与矢量瓦片各自能用在哪。这一章最容易写错的地方不是技术，而是版本状态：把“社区共识”当成“已批准标准”，会在合同条款与跨工具链验证上直接踩坑。读完你应当能判断手上的数据该用什么格式落地，以及哪些说法只是传闻。
学习目标
读完本章，你应当能够：
- 用 3.1 节七层图说出一条分析链路各层的选型关键，并指出哪一层选错会锁死上下游；
- 复述 GeoParquet 1.1.0 与 2.0.0-rc.1 的发布时间与状态，解释为什么 2.0 不能写成“已发布的正式标准”；
- 对照 3.2.2 节，为单片大影像与时序立方体两类数据各选一种格式，并说明理由；
- 说出 3D Tiles 1.1（文档号 22-025r4）与 2.0 的关系，解释“1.1 与 2.0 兼容，主要差异在 asset.version”对存量数据意味着什么；
- 用 3.2.4 节判断矢量瓦片在哪些用途上会给出错误结果，并说明分析为什么必须回到原始矢量；
- 写出一段替代“必须支持 3D Tiles 2.0”的采购表述，做到既不押注未批准标准，也不放弃升级空间。
3.1 一张技术栈地图
把 GIS 数据分析拆成七层，每层的选型逻辑不同：
| 层 | 解决什么问题 | 主流选项（2026 年） | 选型关键 |
|---|---|---|---|
| 数据格式 | 数据怎么落地、怎么交换 | GeoParquet、GeoPackage、Shapefile、COG、Zarr、MVT、3D Tiles、LAS/LAZ/COPC | 分析用列式，交付用容器，影像用云优化 |
| 存储 | 数据放哪、怎么索引 | PostGIS、DuckDB、Snowflake/BigQuery/Redshift、Iceberg/Delta 湖仓、对象存储 | 事务 vs 分析 vs 冷归档 |
| 计算引擎 | 算得多快、能算多大 | 单机（DuckDB/GeoPandas/SedonaDB）、分布式（Spark/Flink/Sedona）、数仓内计算 | 数据量与实时性决定 |
| 几何与投影库 | 结果对不对 | GEOS、PROJ、GDAL/OGR、JTS、S2、H3 | 正确性优先，别自研 |
| 分析方法 | 得出什么结论 | 空间统计、网络分析、栅格代数、时空建模、机器学习 | 方法匹配业务问题 |
| 智能层 | 降低使用门槛、提升解译效率 | 遥感基础模型、嵌入、LLM 编排、Agent | 人机协同而非全自动 |
| 服务与呈现 | 怎么交付 | OGC API、瓦片服务、仪表盘、三维引擎 | 标准优先，避免锁定 |
层与层之间存在强耦合但不应强绑定：一旦某层的选择把上下游锁死（典型如把三维数据只存成某厂商私有格式），后续换引擎的代价会超过当初节省的成本。
3.2 数据层：格式收敛与“分析友好”的胜利
3.2.1 为什么 GeoParquet 成了分析默认
GIS 数据长期以 Shapefile 与 GeoPackage 为主。Shapefile 的限制是众所周知的：单文件 2GB、字段名 10 字符、编码混乱、无拓扑约束；GeoPackage 解决了这些，但在大范围扫描上仍非列式。GeoParquet 的思路是把几何编码成 WKB 列，其余属性走 Parquet 列存，从而直接继承 Parquet 的压缩率、谓词下推、列裁剪与生态兼容性——同一份数据可以被 DuckDB、Spark、Snowflake、BigQuery 直接读。
当前状态需要说清楚，因为这里最容易写错：GeoParquet 1.1.0 于 2024-06-19 发布；2.0.0-rc.1 于 2026-07-19 发布，2.0 的定位是“基于 Parquet 原生 Geospatial Logical Types”。但仓库 README 明确写着“社区已就该版本达成一致，但仍待 OGC 批准”（still pending OGC approval）〔来源：opengeospatial/geoparquet 仓库 README，访问 2026-11-03〕。
所以正确表述是：2.0 已达社区共识、处于 OGC 批准流程中，不能写成“已发布正式标准”。工程含义有三条：可以放心用于内部分析与数据交换；但跨工具链要做一次 round-trip 验证（新版本写出 → 旧版本读入），不能假设“写得出就读得进”；在“合同必须引用正式标准编号”的场景中，要同时注明版本号与候选状态。
配套的是 GeoArrow（内存中的列式几何表示）与 Arrow 生态。SedonaSpark 在 2025 年加入 GeoDataFrame.from_arrow() 路径，把分布式结果零拷贝回 GeoPandas，就是这一趋势的直接体现〔来源：Apache Sedona 2025 Year in Review，2026-01-11〕。
3.2.2 栅格：COG 与 Zarr 分工
云优化 GeoTIFF（COG）解决的是“单片大影像如何被 HTTP 范围请求按需读取”，本质是把 TIFF 重排为分块 + 金字塔 + 头部索引的顺序。它已是 OGC 正式标准（OGC 21-026《OGC Cloud Optimized GeoTIFF Standard》，批准日期 2023-05-08，发布日期 2023-07-14），不是草案也不是“事实标准”〔来源：OGC 21-026 规范页〕。技术上它依赖 TIFF v6 的两个特性——分块（tiles）与降分辨率子文件（reduced resolution subfiles），并建立在 OGC GeoTIFF 19-008r4 v1.1 与 BigTIFF 之上。
对分析工作流的实际含义：COG 是“无服务器栅格分析”的物理前提。凡是把“栅格入库”当默认动作的团队，都应先问一句“能不能留在 COG 上直接算”——多数分区统计、掩膜提取、重采样的任务，在对象存储上用 HTTP Range 就能完成，不必先建一套瓦片库。
Zarr 解决的是另一类问题：多维数组（时间序列、多波段、气候模型输出）的并行读写。它的分块与压缩策略面向对象存储优化，适合“同一地理位置、几万到几十万个时间片”的场景。二者不是替代关系——影像切片取 COG，时序立方体取 Zarr，正在成为共识。
3.2.3 三维：3D Tiles 的位置
OGC 3D Tiles 的准确状态是：1.1 版为社区标准（Community Standard），文档号 22-025r4；1.0 版为 18-053r2〔来源：OGC 3D Tiles 标准页〕。它的定位是“海量三维内容的分块流式传输”，不规定渲染方式——这一点常被误解为“标准不完整”，实际上是有意为之：渲染策略留给客户端竞争。
2.0 正在重写底座，要点是以 glTF 2.1 为基线 + 一组地理空间扩展，新增五类能力：矢量瓦片（Vector Tiles）、体素（Voxels）、时态动态瓦片（Time Dynamic Tiles）、AEC 工程扩展、3D 高斯泼溅（3D Gaussian Splatting）〔来源：CesiumGS/3d-tiles 仓库 next/2.0 README，访问 2026-11-03〕。扩展清单里值得注意的是 EXT_geospatial_crs（含 WKID 与 WKT2 两种写法）与 EXT_georeference——它们把“这个模型在地球上的哪里”从应用层约定变成格式层声明，这正是 BIM+GIS 长期扯皮的技术根因。
时间线要说准：OGC 于 2026 年 7 月 1 日发起 21 天公开评议（截止 2026-07-23），截至本报告资料截止日未见批准公告；仓库方面，2.0 的目录已在 2026-04-23 移入 next 分支。一个常被忽略的好消息是：OGC 原文明确 1.1 与 2.0 兼容，主要差异在 asset.version，因此数据侧不必重做。
判断：2026 年内 3D Tiles 2.0 处于“规范定稿前夜”，新项目应按 1.1 交付、按 2.0 设计扩展位，不要在 1.1 上做深度私有扩展。采购文件若写“必须支持 3D Tiles 2.0”，存在因标准未批准而无法验收的风险，稳妥写法是“支持 3D Tiles 1.1 及后续兼容版本”。
3.2.4 点云与矢量瓦片
点云的事实标准是 LAS 1.4 / LAZ（压缩）与 COPC（云优化点云，按八叉树组织，支持范围请求）。COPC 的价值与 COG 同理：让百 GB 级点云可以在浏览器里按视锥流式加载。
矢量瓦片（MVT）则是“大规模矢量渲染”的答案，但它有个常被忽视的代价：瓦片是为渲染优化的有损表示，裁剪与简化会破坏拓扑。用它做展示没问题，用它做分析（比如统计跨瓦片的面积）会得到错误结果。分析必须回到原始矢量数据。
本章小结
- 七层技术栈之间强耦合但不应强绑定；一旦某层把上下游锁死（典型是把三维数据只存成某厂商私有格式），换引擎的代价会超过当初省下的成本。
- GeoParquet 成为分析默认的原因很具体：几何编码为 WKB 列、属性走 Parquet 列存，同一份数据能被 DuckDB、Spark、Snowflake、BigQuery 直接读。
- 状态必须写准——GeoParquet 1.1.0 于 2024-06-19 发布，2.0.0-rc.1 于 2026-07-19 发布，但 2.0 仍待 OGC 批准，只能表述为“社区已达成共识、处于批准流程中”。
- COG 已是 OGC 正式标准（21-026，2023 年批准并发布），不是草案也不是事实标准；它是无服务器栅格分析的物理前提，“能不能留在 COG 上直接算”应成为入库前的第一问。
- 3D Tiles 1.1 是社区标准（22-025r4），2.0 以 glTF 2.1 为基线重写底座；2026 年处于规范定稿前夜，新项目按 1.1 交付、按 2.0 设计扩展位，不在 1.1 上做深度私有扩展。
- 矢量瓦片是为渲染优化的有损表示，裁剪与简化会破坏拓扑，用它统计跨瓦片面积会得到错误结果——展示可以用它，分析必须回到原始矢量。
思考与练习
- 拿你手上一个项目的数据层现状，按 3.1 节七层图逐层标“已定/待定”，找出最可能锁死上下游的那一层。
- 写一段 150 字以内的交付条款，说明三维数据的格式与版本，既不要求未批准的标准，也保留升级空间。
- 辨析：同事说“COG 和 Zarr 都是栅格格式，选一个用就行”。用 3.2.2 节的分工说明这句话会带来什么返工。
- 应用：给定“全国 5 米格网 DEM”与“十年月均气温”两类数据，分别给出格式、存储与读取方式，并说明理由。
- 你的团队准备采购三维平台。用 3.2.3 节的判断写三条验收标准，其中至少一条针对“模型在地球上的哪里”。
- 检查你的管线里是否存在“用 MVT 做分析”的操作；若有，指出误差来源并给出替换方案。