很多 GIS 团队已经把 GeoParquet 和 DuckDB 用在数据清洗、质量检查和批量分析里，但一到“让业务方在网页地图上看结果”，流程常常又回到另一套系统：导入 PostGIS，预生成 PMTiles/MBTiles，或者临时写一个代理服务。

MapLibre 社区 2026 年 8 月 15 日发布的 Martin DuckDB 后端进展，正好击中了这个断点。它的核心价值不是又多了一个数据库选项，而是让一份分析侧已经存在的 GeoParquet 文件，有机会直接变成标准矢量瓦片服务，被 MapLibre 这类前端地图客户端消费。

Martin DuckDB GeoParquet 矢量瓦片服务架构Martin DuckDB GeoParquet 矢量瓦片服务架构

先看 10 条可核验事实

  1. MapLibre 社区文章发表于 2026 年 8 月 15 日，主题是为 Martin TileServer 增加 DuckDB 后端。
  2. Martin 原本已经能从 PostGIS、PMTiles/MBTiles 提供矢量瓦片，也能处理 COG 和 GeoJSON 到瓦片的路径。
  3. 新实现让 Martin 通过 DuckDB 读取 GeoParquet 或 DuckDB 数据源并生成 MVT，目标是减少导入 PostGIS、预生成瓦片包或维护代理层的重复步骤。
  4. DuckDB spatial extension 提供 ST_AsMVT 和 ST_AsMVTGeom，这是把 DuckDB 查询结果接入矢量瓦片流程的关键能力。
  5. 实现中引入 DuckDBSource 和连接池；示例配置里的 pool_size 为 4，阻塞式 DuckDB 调用被放到 Tokio blocking pool 执行。
  6. GeoParquet 解析路径会识别 geometry column、校验 feature ID、读取属性列，并处理 EPSG:* 与 OGC:CRS84 等 CRS 表达。
  7. 生成瓦片时，查询会构造 tile envelope，把源几何转换到 Web Mercator，按 tile bounds 过滤，再通过 ST_AsMVTGeom 和 ST_AsMVT 组装 MVT。
  8. 端到端测试覆盖 catalog、TileJSON、实际矢量瓦片请求和解码后的 MVT 内容。
  9. 该能力目前仍放在 unstable-duckdb feature gate 下，文章明确列出 remote GeoParquet 测试、hot reload、CLI/discovery、查询取消和文档稳定化等后续工作。
  10. Overture Maps 2026-08-19.0 数据和 v1.18.0 schema 已发布，并提供 release data、changelog、bridge files、GERS registry 和 PMTiles 路径，说明开放地图数据正在持续以云原生格式进入生产链路。

它解决的不是“有没有地图”，而是“少搬一次数据”

传统 WebGIS 交付经常把分析和发布拆成两套管线。分析人员在 Python、DuckDB、GeoParquet、GeoPandas 或 notebook 里完成计算；发布人员再把结果导入空间数据库或切成瓦片。这个过程本身不复杂，但在日常项目里会制造很多摩擦：字段被改名、坐标系元数据丢失、预览版本和最终版本不一致、临时成果没人愿意走完整发布流程。

Martin 的 DuckDB 后端提供了另一种选择：如果分析结果已经是 GeoParquet，Martin 可以在服务启动时把它解析为一个瓦片 source，对外暴露 catalog、TileJSON 和 /{source}/{z}/{x}/{y} 这样的标准瓦片端点。前端仍然按熟悉的矢量瓦片方式加载，分析侧也不必为了预览地图而额外维护一个 PostGIS 实例。

这对 GIS 团队最直接的价值，是把“分析文件”和“地图服务”之间的距离缩短。尤其在城市 POI、建筑物、道路、分区、设施台账、巡检范围、灾害影响区这类矢量数据上，很多结果先要被人看一眼、改一轮、再决定是否进入正式产品。这个阶段如果每次都要导库、切片和部署，团队很容易把地图预览变成一个额外负担。

为什么它和 Overture、STAC、GeoParquet 的趋势有关

这次进展不应只看作 Martin 的一个功能点。更大的背景是：地理数据正在从“服务优先”变成“文件和服务并存”。Overture Maps 的 2026-08-19 release 继续提供 release data、changelog、bridge files、GERS registry 和 PMTiles 路径；STAC GeoParquet 相关工具也在把 STAC 条目转换成更适合批量查询的列式格式。

对实践团队来说，这意味着数据可能先以 GeoParquet、COG、PMTiles、STAC catalog 的形式出现，而不是先进入某个企业空间库。分析人员希望用 DuckDB 快速筛选和聚合，前端人员希望用 MapLibre 快速展示，运维人员则希望减少中间状态和临时服务。

DuckDB + GeoParquet + Martin 的组合，正好把这三类需求接到一起：DuckDB 负责就地查询，GeoParquet 负责列式存储和几何表达，Martin 负责把结果变成地图客户端能直接消费的 MVT。它不会替代 PostGIS，也不应该替代所有生产级空间服务，但它给了团队一个更轻的中间层。

GIS 团队怎么接入

第一类适合试点的场景，是数据质量审查。比如每月拿到一批道路、建筑物或 POI 数据，先用 DuckDB 做字段、范围、重复值和空间范围检查，再用 Martin 直接把 GeoParquet 暴露给 MapLibre 页面，让业务人员按区域查看异常点。

第二类是项目过程图层。规划、自然资源、应急和交通项目里，经常会产生很多中间结果：缓冲区、叠加区、候选点、风险分级、服务半径、覆盖缺口。它们未必都值得进入正式服务目录，但值得被审阅和复核。GeoParquet 直接出瓦片，可以降低这些中间图层的展示成本。

第三类是开放数据产品的快速验证。Overture 这类月度数据 release 带来大量道路、建筑物、地点和分区更新。团队可以先把关心区域的数据落到 GeoParquet，使用 DuckDB 做筛选，再用 Martin 提供临时矢量瓦片端点，比先设计完整数据库模型更适合早期探索。

不能忽略的落地风险

当前能力仍在 unstable-duckdb feature gate 下，这一点很重要。它适合被放进技术预研、内部工具、数据产品原型和非关键链路，不适合未经验证就替换正式生产发布体系。

并发和资源控制也需要提前设计。DuckDB 会在单次查询内部并行，Martin 又有连接池；文章提醒有效并行度大致受 pool_size 和 DuckDB threads 的共同影响。对于大 GeoParquet 文件，如果没有限流、缓存和超时策略，地图缩放和平移可能直接变成后端扫描压力。

CRS 是另一个必须前置的检查点。GeoParquet 管线可能保留几何，却丢掉 DuckDB 转换所需的 CRS 元数据。Martin 的解析器会处理 EPSG:* 和 OGC:CRS84，但团队仍应在数据入库前建立 schema、geometry column、SRID 和范围校验，避免“瓦片能出，但位置不可信”。

下周可以做什么

一个低风险试点可以这样做：选一份不涉密、范围可控、业务方熟悉的 GeoParquet 数据，比如某市建筑物或道路更新；用 DuckDB 做 3 到 5 条质量检查；配置 Martin 的 DuckDB source；用 MapLibre 做一个只读预览页；最后把加载速度、字段完整性、CRS 校验、瓦片正确性和审阅反馈记录下来。

验收标准不要只写“地图能打开”。更合适的标准是：同一份 GeoParquet 能被 DuckDB 查询和地图服务复用；TileJSON bounds 与实际数据范围一致；随机抽样要素在 QGIS、DuckDB 和 WebGIS 中位置一致；字段没有被静默丢弃；大范围缩放时后端负载可控。

这类能力的意义，不是让所有 GIS 服务都变成文件直出，而是给“分析到展示”的中间地带补上一条更短的路径。对很多团队来说，少搬一次数据、少维护一个临时库、少生成一套中间瓦片包，就足以让数据审查和业务沟通快一轮。

资料来源

  • MapLibre Community Post: GSoC'26: DuckDB Backend for Martin TileServer, 2026-08-15
  • Overture Maps: 2026-08-19 release notes
  • stac-geoparquet project page, 2026-08-12 release
  • Cesium Releases in August 2026
  • Planet PostGIS: PostGIS 3.7.0rc1 release note