第10章 平台架构：从“文件柜”到“成果中枢”

本章导读

第 9 章把一致性变成了可执行的检查，本章回答这些检查在哪里被执行：平台。先对照自然资办函〔2024〕1729号第（四）条，把政策语言拆成流程、数据、交换、服务四类能力（10.1 节），但大量平台只做到了第一类，退化成“带审批流的文件柜”。随后按表 10-1 的四层架构逐层展开：数据层的双态存储、追溯关系、与既有数据库融合三原则；业务层把测绘事项做成可配置的字典（表 10-2），并让规则引擎可配置、可版本化、可测试、可追踪；交换层在没有接口标准时采取“数据契约 + 适配器 + 交换执行”的三层解耦（10.5 节），按表 10-3 排出对接优先级；再补电子签章、归档、性能容量这些易被忽略的问题。反直觉的是 10.8 节的投入比例：数据侧 60%、流程侧 25%、交换侧 15%，而多数项目的投入恰好倒过来。读完你会明白，平台的成败不取决于审批流跑得多顺，而取决于入库的数据有没有人用；数据能不能被用，先要看第 11 章的合规底线。

学习目标

读完本章，你应当能够：

• 拆解自然资办函〔2024〕1729号第（四）条的要求，把它对应到流程、数据、交换、服务四类能力，并指出大量平台实际只做成哪一类（10.1 节）；
• 复述表 10-1 四层架构的职责、关键组件与常见缺陷，说明为什么数据层最容易被低估、交换层最容易被做偏（10.2 节）；
• 区分原始成果与入库数据两种形态，说明双态存储之间的一一对应追溯关系为何在合规语境下必需（10.3.1 节）；
• 设计一个可配置的测绘事项字典（表 10-2），指出事项硬编码在换地区部署时会造成什么问题（10.4.1 节）；
• 复述无统一接口标准前提下的“数据契约 + 适配器 + 交换执行”三层解耦策略，并按表 10-3 排出对接优先级及其依据（10.5 节）；
• 判断一个平台是否满足电子签章与在线归档要求，列出归档必须同时具备的完整性、可读性、可验证性与可追溯性（10.6 节）。

10.1 政策要求与真实需求的差距

政策对平台的要求是明确的。自然资办函〔2024〕1729号第（四）条要求：

鼓励建设“多测合一”服务平台，推进与用途管制、工程建设项目审批、不动产登记、地籍管理等系统信息互联互通、实时共享，为规划、用地、房管、登记等工作提供满足需要的测绘成果。

同一份文件还要求“规范成果资料提交、审核、更新、共享流程”，“不动产测绘成果经审核通过后，纳入地籍数据库统一管理”。

把这些要求拆开，实际上包含四类能力：

1. 流程能力：提交、审核、更新、共享四个环节要可管理、可追溯；

2. 数据能力：成果要能入库，且能与既有数据库融合；

3. 交换能力：与至少四类外部系统双向共享；

4. 服务能力：为多个业务场景提供“满足需要”的成果。

现实中，大量平台只做到了第 1 类（流程），第 2 类做了半截（能存不能融），第 3 类靠人工导出导入，第 4 类停留在“能查看”。

结果是平台退化成一个带审批流的文件柜。 本报告第 1 章提到“平台建成、业务不动”的风险，指的就是这种状态。

10.2 一个务实的架构分层

表 10-1　多测合一平台的四层架构

这四层里，最容易被低估的是数据层，最容易被做偏的是交换层。

10.3 数据层：不是“存文件”，而是“建库”

10.3.1 成果的双态存储

多测合一的成果有两种形态，必须同时保留：

• 原始成果：测绘单位提交的文件集合（DWG、PDF、XLSX、数据集、元数据）。它是法律意义上的交付物，必须原样保存、不可修改；
• 入库数据：从原始成果解析、校验、转换后进入空间数据库的结构化数据。它是业务使用的主体，可以更新、可以查询、可以关联。

两者之间必须建立一一对应的追溯关系：任何一个入库要素，都能追溯到它来自哪一份原始成果的哪个部分；任何一份原始成果，都能查到它被解析成了哪些入库数据。

这个追溯关系在多测合一的合规语境下是必需的——当成果出现质量争议时，需要判断问题出在“提交的成果”还是“解析入库的过程”。

10.3.2 与既有数据库的融合

1729 号文要求“不动产测绘成果经审核通过后，纳入地籍数据库统一管理”。这句话的技术含义是：多测合一的成果不是独立存在的，它要进入一个已经运行多年的数据库。

融合的难点在第 7 章已讨论过（新旧宗地的几何冲突）。这里补充平台侧的处理原则：

• 不覆盖历史，只追加版本：既有数据不应被直接修改，而应通过版本机制表达变化；
• 冲突显式化：新旧数据不一致时，不自动“抹平”，而是生成冲突记录，交人工决策；
• 变更留痕：每一次因多测合一成果引起的地籍数据变更，都要能追溯到具体的成果与审核记录。

10.3.3 元数据管理

第 5 章给出了元数据的最小集。平台侧的要点是：元数据不是附件，而是数据的一部分。 它应当在入库时自动生成、在查询时可检索、在交换时随数据一起流转。

如果元数据只在成果报告里以文字形式出现，那么它就无法被系统使用，“成果有效性判断”“跨库一致性检查”这些能力就无从谈起。

10.4 业务层：事项字典与规则引擎

10.4.1 事项字典：不要硬编码

第 3 章强调过：各地纳入多测合一的测绘事项清单不同（河北五项、湖南三项含房产、其他地方还有增减）。如果系统把事项硬编码在流程里，那么换一个地区部署就要改代码。

正确做法是把测绘事项做成可配置的字典：

表 10-2　测绘事项字典的字段设计

10.4.2 规则引擎：让规则可配置

第 9 章讨论的质检规则库，在平台层面需要一个执行引擎。设计要点：

• 规则与数据解耦：规则以配置形式存储（如表达式语言、决策表），而不是写在程序里；
• 规则可版本化：规则集有版本号，成果记录其所用的规则版本；
• 规则可测试：支持用样例数据验证规则是否正确；
• 规则执行可追踪：每次执行记录输入、输出、耗时、结果。

10.5 交换层：证据最薄弱的地方

10.5.1 一个必须承认的事实

多测合一领域目前没有国家或行业层面的接口标准。 本报告的检索未发现统一的数据交换格式或 API 规范。1729 号文只写“推进互联互通、实时共享”，没有规定如何互联。

地方实践中，交换方式差异很大：有的做数据库直连，有的做文件定时交换，有的做服务接口调用，有的干脆人工导出导入。

这不是一个小问题。 没有标准接口意味着：

• 每接一个外部系统就要定制开发一次；
• 外部系统升级时，接口可能失效；
• 跨地区、跨层级的数据汇聚难以实现。

10.5.2 在缺乏标准的情况下如何设计

建议采用“三层解耦”策略：

第一层：数据契约层。 定义本平台对外提供的数据集规范（字段、编码、格式、坐标系），独立于任何具体的外部系统。这个规范可以参照已有的国家标准（如 TD/T 1066-2021《不动产登记数据库标准》的空间要素组织方式）。

第二层：适配层。 为每个外部系统写一个适配器，负责把数据契约转换成该系统的格式。适配器是隔离变化的屏障——外部系统变了，只改适配器。

第三层：交换执行层。 统一的交换任务调度、失败重试、日志记录、监控告警。

这个设计不能消除定制工作，但能把定制工作限制在适配器这一层，避免它渗透到整个系统。

10.5.3 对接对象的优先级

表 10-3　外部系统对接的优先级与内容

优先级排序的依据是政策明确程度与业务必要性，而不是技术难度。

10.6 电子签章与在线归档

10.6.1 法律基础已经具备

多测合一的成果要实现“全程网办”，必须解决两个法律问题：电子文件是否有效、电子签章是否被认可。

第一个问题：《电子签名法》（2004 年通过，2019 年 4 月 23 日第二次修正）第三条明确“当事人约定使用电子签名、数据电文的文书，不得仅因为其采用电子签名、数据电文的形式而否定其法律效力”；第七条规定数据电文不得仅因其以电子形式存在而被拒绝作为证据使用。

更关键的是第四条至第六条：符合条件的数据电文分别视为满足法律要求的书面形式、原件形式、文件保存要求。其中“原件形式”要求“能够有效地表现所载内容并可供随时调取查用，能够可靠地保证自最终形成时起，内容保持完整、未被更改”。

这条要求直接转化为技术要求：电子成果必须具备防篡改能力。 常见的实现方式是哈希校验、时间戳、区块链存证。

第二个问题：《电子印章管理办法》（国办发〔2025〕33号，2025 年 9 月 27 日印发、10 月 9 日发布，自印发之日起施行）第五条规定，符合该办法的电子印章与实物印章具有同等法律效力，经电子签章的电子文件与加盖实物印章的纸质文件具有同等效力（法律、行政法规明确不适用的除外）。第 27 条要求行政机关及履行社会管理、公共服务职能的单位在业务活动中需用电子印章时，其业务信息系统应支持符合该办法的电子印章接入使用。

这为多测合一平台提出了明确的产品要求：必须支持合规电子印章的接入。 如果平台自建一套“图片章”，是不满足要求的。

10.6.2 归档的技术要求

测绘成果受档案管理法规约束（1729 号文明确要求“遵守测绘成果安全保密、档案管理和成果汇交有关规定”）。电子归档的要点：

• 完整性：成果文件、元数据、质检记录、审核记录、签章信息应当作为一个整体归档；
• 可读性：归档格式应当长期可读，避免依赖特定软件版本；
• 可验证性：能够验证归档后未被篡改；
• 可追溯性：能追溯到归档时的操作人、时间、系统环境。

10.7 性能与容量：一个容易被忽略的现实问题

多测合一的平台往往低估数据量。一个中型城市每年可能有数百个多测合一项目，每个项目的成果数据量从几十 MB 到数 GB 不等（含三维数据时更大）。十年积累下来，数据量可能达到 TB 级。

需要考虑的技术点：

• 冷热分离：近期项目（如 1 年内）在线存储、快速访问；历史项目归档存储、按需恢复；
• 空间索引的维护成本：数据量增长后，索引重建时间变长，需要有增量索引方案；
• 三维数据的流式服务：三维数据不适合整体加载，需要切片、LOD、按视锥调度；
• 并发访问：审核高峰期可能有大量并发查询，需要缓存与负载均衡。

10.8 平台建设的三条原则

原则一：数据先行，流程其次。 很多平台的失败在于把主要精力放在了流程审批上，而数据质量与可用性没有解决。结果流程跑通了，但成果没人用。建议的投入比例是数据侧 60%、流程侧 25%、交换侧 15%。

原则二：不做“唯一入口”就做不成。 第 13 章会看到，地方实践中凡是成功的案例，都伴随着“暂停线下办理”这类强制措施。平台如果只是“可选渠道”，实际使用率会很低。

原则三：接口标准化是对自己的保护。 即使现在没有统一标准，也应当按“数据契约 + 适配器”的方式设计。这样未来标准出台时，改动量最小。

本章小结

多测合一平台的政策要求包含流程、数据、交换、服务四类能力，但实践中多数平台只做好了流程这一类。

架构上应分四层（接入、业务、数据、交换），其中数据层的“双态存储”（原始成果 + 入库数据）与追溯关系是合规要求，交换层是证据最薄弱、最容易出问题的环节。

关键判断：

1. 事项必须字典化、规则必须可配置，否则换地区部署就要改代码；

2. 多测合一领域尚无统一接口标准，应采用“数据契约 + 适配器 + 交换执行”的三层解耦策略；

3. 电子成果的法律效力已有明确依据（电子签名法、电子印章管理办法（国办发〔2025〕33号）），平台必须支持合规电子印章接入，不能自建“图片章”；

4. 投入比例建议数据侧为主，流程侧次之，避免“流程跑通但数据没人用”。

最后提醒：1729 号文对平台的表述是“鼓励建设”，不是强制要求。但“规范成果资料提交、审核、更新、共享流程”是明确要求——即使不建平台，这套流程也必须建立。

思考与练习

1. 某市 2025 年上线的多测合一平台审批流跑得很顺，但成果仍以压缩包存放在文件服务器上，与外部系统靠人工导出导入。请对照 10.1 节的四类能力与表 10-1，指出它缺了哪几类能力，并说明最该先补哪一层、理由是什么。
2. 某平台把“用地核实、规划核实、房产测绘”三个事项写死在流程代码里，换到第二个城市部署时改了两个月。请用 10.4.1 节与表 10-2 说明正确做法，并列出至少四个必须做成字典字段的配置项。
3. 某平台对接外部系统时，把每种格式转换都写在业务代码里，其中一家外部系统升级后，三个业务模块同时失效。请用 10.5.2 节的三层解耦判断问题出在哪一层，并说明改造后失效范围应收缩到哪里。
4. 拿本地多测合一平台的建设方案、招标文件或对接文档，比对表 10-3 的对接对象与优先级，列出本地实际接了哪些、依据是否写清、哪些属于“视地方建设进度”的中优先级。
5. 今天为你所在项目画一张四层架构现状表（接入、业务、数据、交换），每层只填三项：现有组件、最缺的组件、本季度能补的一件事；再按 10.8 节的投入比例估一下资源下一步该往哪层偏。