第14章 痛点与瓶颈：为什么有的项目做成了，有的没做成

本章导读

前面十二章把制度、基准、数据模型、作业、质检、平台与合规逐块讲完，这一章换个角度问：规则和工具都在，为什么有的项目做成了，有的没做成？本章先把公开材料与工程实践中反复遇到的困难归纳成八类痛点，逐类给出表现、成因与可操作的对策（14.2—14.9 节）；其中 1729 号文解读承认的“地方保护、重复测绘”有官方来源，其余属工程实践共识，正文逐处标注。随后用表 14-1 按主因归类，指出八类中有五类的主因是制度而非技术（14.10 节）。本章的落点是一个反直觉判断：失败往往不是因为“合”得不够，而是责任、标准、数据边界“分”得不清楚（14.11 节）。只盯着事项合并的数量，就会把制度问题当成技术问题去解，越努力越错位。读完你会明白，技术团队在多测合一中的正确定位不是解决制度问题，而是把制度问题转化成可被看见、可被量化的证据——这也正是第 15 章算账时绕不开的前提。

学习目标

读完本章，你应当能够：

• 说出 14.2—14.9 节归纳的八类痛点名称，并按“表现、成因、可操作的对策”三段结构复述其中任意一类；
• 区分有官方或权威来源的判断与工程实践共识，指出 14.1 节为何要求逐处标注来源；
• 拆解 14.4 节的判断：为什么把数据处理当作“顺手做的事”，多测合一的成本模型就永远是错的；
• 对照表 14-1 说出八类痛点的主因类型，并指出哪五类的主因是制度而非技术；
• 判断一个平台项目的成败，用 14.6 节的指标——审核人员是否愿意主动使用它——给出结论并说明理由；
• 复述 14.11 节的反直觉观察，用责任、标准、数据边界三条“分不清”解释一个失败案例。

14.1 本章的方法

把公开材料中出现的问题与工程实践中反复遇到的困难放在一起，可以归纳出八类痛点。本章对每一类给出：表现、成因、可操作的对策。

需要说明：本章的一部分内容有官方或权威来源支撑（如 1729 号文解读承认的“地方保护、重复测绘”），另一部分是工程实践共识（无成文依据）。后者会明确标注。

14.2 痛点一：标准不统一，成果无法互认

表现：同一栋楼的建筑面积在不同事项的报告里差几百平方米；同一宗地的界址在两张图上不重合；绿地率的计算范围一处一样。

成因：第 3 章讨论的四套面积体系并行。规划、房产、土地、工程各有各的规范，各有各的历史，各有各的主管部门。这不是“有人做错了”，而是“本来就设计成不同”。

为什么难解决：统一面积口径意味着某个部门要放弃自己的计算规则，这是一个权责调整而非技术优化。团体标准的编制说明直言不讳：“因房屋面积计算等原因，相关的国家或行业标准未能立项。”

可操作的对策：

• 短期：不追求全局统一，而是建立“多口径并存 + 差值可解释”的数据模型（第 3 章 3.3 节、第 5 章 5.5 节）；
• 中期：在一个地区内推动规划、房产、登记三个口径的对照表，把差异显式化；
• 长期：以数据标准（编码、格式、元数据）为突破口，先统一“数据怎么组织”，再统一“数怎么算”。

14.3 痛点二：数据模型不统一，入库即返工

表现：测绘单位提交的成果格式各不相同；平台接收后需要大量人工转换；转换后的数据与既有数据库对不上；入库一次、返工三次。

成因：成果格式没有强制性标准（第 12 章）；各地平台的数据字典各写各的；既有数据库的坐标基准、要素定义、编码规则各不相同。

可操作的对策：

• 把数据字典当成合同附件：在委托合同中明确数据字典，作为验收依据；
• 提供官方转换工具：平台侧提供免费的格式转换与自检工具，让测绘单位在提交前发现问题（第 6 章 6.4 节）；
• 转换责任归属测绘单位：平台不代做转换，只做校验（第 6 章 6.4 节的核心判断）。

14.4 痛点三：CAD 到 GIS 的转换成本被严重低估

表现：项目预算里“数据处理”一项写得很小，实际执行时内业工时超过外业；返工频繁；不同作业员的转换结果不一致。

成因：行业内长期把“测绘”理解为“测+绘”，把数据处理视为附属工作。而多测合一的数据处理量是传统单事项的数倍（第 3 章表 3-5）。

可操作的对策：

• 在报价中显式列出内业工时：按第 6 章表 6-1 的六个环节分别估算；
• 把转换规则配置化：图层映射表、值映射表、拓扑规则都应做成配置，而不是每次重新写脚本；
• 建立转换质量的量化指标（第 6 章表 6-4），把“数据质量”写进验收标准。

这一条是本报告认为行业最需要改变认知的地方。 如果继续把数据处理当作“顺手做的事”，多测合一的成本模型就永远是错的。

14.5 痛点四：部门协同难，改革止步于竣工验收

表现：多测合一只在竣工验收阶段落地，前三个阶段照旧；成果在验收环节共享，但建设项目审批、不动产登记、用途管制等系统之间仍靠人工传递；部门之间对成果的理解不一致。

成因：竣工验收阶段涉及的主要是自然资源部门内部（规划核实、土地核验、地籍），协调成本相对低；而扩展到施工许可、工程建设许可，就要跨住建、人防、园林等多个部门，协调成本陡增。

来源支撑：自然资源部网站 2022 年的改革观察文章指出，部分地区改革仅停留在竣工验收阶段。这是一个有官方来源的判断。

可操作的对策：

• 以高频事项为突破口：先做使用频率最高、争议最小的事项，积累信任；
• 以数据共享代替流程合并：不一定要把流程合并到一个平台，先做到数据互认；
• 建立跨部门的规则仲裁机制：当两个部门对同一指标有不同要求时，有明确的裁决路径（这一点在实践中往往缺失）。

14.6 痛点五：平台建成，业务不动

表现：平台功能齐全、界面漂亮，但实际使用率低；建设单位仍走线下；测绘单位上传成果后又线下提交纸质；平台数据长期不更新。

成因：平台是“可选渠道”而非“唯一入口”；平台不能解决使用者的实际问题（如审核仍要人工看图纸）；平台的成果不能直接用于下游业务。

来源支撑：第 13 章湖南的“不得线下受理”是正面案例，说明强制入口是有效的；反面案例则普遍存在，但缺乏公开的系统性统计（属工程实践共识）。

可操作的对策：

• 让平台成为唯一入口（行政措施）；
• 让平台解决真问题：把审核人员最耗时的工作（如图属一致性核对、面积重算）自动化，让他们真正愿意用；
• 让成果能往下走：成果入库后能直接支撑登记、审批，而不是“入完库就躺着”。

判断平台成败的一个简单指标：审核人员是否愿意主动使用它。如果不愿意，说明它没有解决他们的痛点。

14.7 痛点六：合规风险被低估

表现：成果未定密就进共享通道；个人信息未脱敏就对外提供；测绘资质类别覆盖不全；质量责任主体不清。

成因：一线从业者更关注技术问题；合规要求分散在多部法规中，缺少一份“给技术人员的合规清单”。

可操作的对策：

• 使用本报告第 11 章表 11-3 的六条线自查清单；
• 把合规检查做成平台的强制流程节点，而不是靠人记得；
• 在项目启动会上明确“双责任”边界（哪些数据由建设单位提供、哪些由测绘单位生产）。

14.8 痛点七：数据安全与开放的矛盾

表现：一方面要求成果共享、数据开放、支撑“一张图”；另一方面要求严格保密、分级管控。基层单位往往选择“宁可不动”，导致数据价值无法释放。

成因：这是真实的制度张力，不是执行偏差。2026 年的政策动向也印证了这一点——一方面推进公共数据授权运营、天地图商业化，另一方面强化地理信息安全监管、推进数据分类分级保护。

一处具体证据：自然资源部《“一张图”总体设计》相关要求中提到采用“经国家认定的地理信息保密处理技术”，而地方为落实这一要求单列预算（据四川省自然资源厅 2026 年 8 月的公开采购信息，单列 40.1 万元）。这说明“脱密处理”是有实际成本的，不是一句口号。

可操作的对策：

• 把“密级”作为数据的第一个属性，在数据产生时就确定，而不是后期补；
• 建立分级共享的技术通道：涉密走涉密网、非涉密走政务网、公开走互联网，三条通道物理或逻辑隔离；
• 把脱密处理纳入预算与流程，不要假设“应该不涉密吧”。

14.9 痛点八：能力与人才的结构性缺口

表现：会测量的不懂数据库，懂 GIS 的不懂测绘规范；项目负责人难以同时驾驭外业组织、内业处理、合规要求；新人培养周期长。

成因：多测合一要求的是一复合能力结构，而传统的测绘教育与 GIS 教育是分开的。测绘专业重测量方法、轻数据工程；GIS 专业重空间分析、轻测量规范。

可操作的对策：

• 建立岗位能力矩阵：把项目所需能力拆成“测量、数据处理、规范理解、合规、项目管理”五类，明确每个岗位的要求；
• 把规范知识固化为工具：与其要求每个人记住几百条面积规则，不如做成计算器（第 7 章的核心主张）；
• 以项目带培养：多测合一的项目周期长、环节全，是培养复合人才的理想载体。

14.10 八类痛点的相互关系

表 14-1　八类痛点的成因归类

这张表最重要的信息是：八类痛点中有五类的主因是“制度”而非“技术”。

这解释了一个常见困惑：为什么技术团队再努力，项目还是做不好？因为技术只能解决技术问题，制度问题需要制度手段。技术团队能做的是：把制度问题转化为可被制度决策者看见的具体证据——比如用数据指出“两个口径的面积差了多少、影响了多少个项目”，这比说“标准不统一”有说服力得多。

14.11 一个反直觉的观察：多测合一失败往往不是因为“合”得不够，而是因为“分”得不清楚

在多测合一的讨论中，“合”是主旋律。但观察失败案例，常见的问题不是“事项合得不够多”，而是责任、标准、数据边界分得不清楚：

• 责任分不清：出问题时不知道是建设单位提供的材料错了，还是测绘单位测错了（这就是深圳“双责任”设计要解决的问题）；
• 标准分不清：不知道哪个指标按哪个口径，于是每个部门按自己的理解判定；
• 数据边界分不清：不知道哪些数据可以共享、哪些不能，于是要么过度保守、要么违规共享。

所以，“合”的前提是“分”得清楚。 这是本报告对多测合一方法论的一条核心判断。

本章小结

八类痛点中，标准不统一、部门协同难、平台业务两张皮、安全与开放矛盾、人才缺口这五类的主因是制度；数据模型不统一、转换成本被低估、合规风险被低估这三类可以通过技术与认知改进缓解。

关键判断：“合”的前提是“分”得清楚——责任分清楚（双责任）、标准分清楚（多口径并存且可解释）、数据边界分清楚（分级共享）。这三件事没做好，越“合”越乱。

技术团队在多测合一中的正确定位不是“解决制度问题”，而是把制度问题转化为可被看见、可被量化的证据，从而支撑制度决策。

思考与练习

1. 某市平台功能齐全、界面美观，上线一年使用率仍低，建设单位照旧走线下，测绘单位上传后又线下递交纸质成果。请用 14.6 节的三条成因定位问题，并给出你的改进顺序与理由。
2. 某项目验收时面积对不上，建设单位说按规划口径、测绘单位说按房产口径、登记部门说按登记口径，三方各有依据。请用 14.2 节的“多口径并存 + 差值可解释”与 14.11 节的“标准分不清”分析，并写出短期可落地的处理步骤。
3. 某测绘单位的报价单里“数据处理”只列了一行，占很小比例，项目实施后内业复核反复、返工三次。请用 14.4 节判断问题性质，并结合 14.3 节的“数据字典当成合同附件”提出两条合同修改建议。
4. 取本单位一份成果验收记录或一份平台使用通报，按表 14-1 的八类逐项打钩，统计本单位的痛点分布，再与表 14-1 的“主因类型”列比对，看偏差出在哪几类。
5. 今天就在自己的项目台账里挑两个近期项目，各写一条“可被制度决策者看见的证据”——用具体数字说明两个口径差了多少、影响了多少个项目，而不是只写“标准不统一”。