FireGeo实践解析：地理空间数据处理自动化与空间数据清洗的集成之道

做地理空间数据处理这几年，我越来越觉得“会画地图”和“能处理数据”是两码事。前者拉个图层设置一下样式就行，后者要在坐标系统之间来回倒腾，要给几百万条几何做相交判断，还要忍受跑了一个小时的脚本在最后一步内存溢出。

最近我一直在盯一批跨部门交换过来的建筑物轮廓和地块权属数据，Shapefile、GeoJSON、DWG、Excel 里的经纬度，什么格式都有。旧的常规流程——QGIS 看数、PostGIS 算空间关系、再用 Python 把结果整理成业务表——不是不能做，只是每一步都要手工衔接，规则写死在临时脚本里，没法复用，也没法对业务方解释“中间出了哪些错、哪些被纠正了”。在这个背景下，我开始关注开源软件 FireGeo。它不是又一个可视化大屏工具，而是想做“地理空间数据处理”这条链路里的集成层和规则执行层，听起来正好补上我工作流里最薄弱的那一环。

这篇文章不打算复述官网特性列表，而是从我实际评估和使用它的角度，聊聊它解决的问题、跑通一次真实数据处理过程的经验，以及和 GDAL、PostGIS、GeoPandas 这些老牌工具放在一起时，它的边界到底在哪里。如果你也经常被空间数据清洗、坐标转换、大批量空间关联这类事情困扰，这篇文章应该能帮你判断值不值得给它一次机会。

1. 为什么我会对一个新开源项目产生兴趣

1.1 旧工作流里的三个尴尬瞬间

先说一个典型场景：上游给我一个 CSV，带五万多行“经度”“纬度”字段，同时给我一个由几十个不规则多边形组成的开发区范围。需求很简单：把这些点过滤出来，落在开发区内的保留，并按归属地块打上 BlockID。

在 QGIS 里点上几个按钮很快，但业务上需要的是可重复执行的流程。下一次数据又来，不能“再手动导一次”。更麻烦的是，CSV 里的坐标没有写清楚坐标系。经度 120.3、纬度 30.2，在地图上显示是对的，可如果直接用平面几何算法去算，单位是“度”，不是“米”，缓冲区 50 米还是 50 度，结果完全是错的。

用 GeoPandas 也能做，但在几千万条记录面前先吃内存，空间连接又靠 GEOS 底层库扛，一旦碰到自相交几何，经常整批报错。用 PostGIS 绕开是绕开了，但建表、定约束、写空间索引，每一步都要反复确认类型和查询计划，最后操作本身只花了 1 分钟，前期准备工作反而用了一下午。

这不是单一工具的问题，而是处理流程碎片化的结果：一个用 QGIS 看结果，一个用 Python 做清洗，一个用数据库做空间计算，期间还要自己维护坐标系统、输入输出格式、规则版本。我缺的是一个能把这些粘起来的东西。

1.2 FireGeo 出现的时机

我是在梳理“地图数据自动化治理”方案时看到 FireGeo 的。项目定位是“面向地理空间数据集成的处理中间件”，源码开源，不绑定特定商业平台。看文档里的整体设计，它关心的不是画图好不好看，而是如何把一个原始数据源变成一份可以由下游应用安全使用的数据。

它的切入角度很合我意：把空间数据读取、坐标转换、几何校验、属性清洗、空间关联这一串动作，写成可重复执行的流程，而不是靠人工点击。这正好切中我在实际项目里最费时间的那部分。

不过，只看文档不做判断。以下所有内容，都是我按公开仓库和示例项目本地跑出来的经验。会尽量讲清楚“它到底做了什么”和“它在哪一步其实还是绕不开老工具”，避免吹捧。

2. FireGeo 的核心设计：数据、规则和算法是怎么分开的

2.1 数据集描述层：它不关心文件放到哪里，而关心数据怎么说清楚

FireGeo 的日常使用状态并不是一打开就能看到一个完整地图界面。用户通过配置来描述一份输入数据：是什么格式、包含哪些字段、几何字段放在哪一列、坐标系是 WGS84 还是 GCJ-02 之类的加密坐标，还是地方独立坐标系。

这句话听着抽象，举个例