南方iData数据工厂：基础空间数据一体化生产与增量更新实践

第一次把外业回来的 DXF、内业改过三遍的 DWG、入库前单独跑的 MDB，再加上几张用 Excel 维护的属性表，全部铺在同一个屏幕上对照的时候，我大概就明白了为什么这几年越来越多测绘和空间数据生产团队开始聊南方 iData 数据工厂这一类平台。不是因为大家都喜欢尝鲜，而是因为基础空间数据的生产链条实在太碎了：采集用一套、编辑用一套、成图用一套、入库检查又是另一套，中间靠人手工搬数据，搬一次丢一点，搬三次就说不清哪份是准的了。iData 数据工厂提的"一个平台、一套数据、一体化生产"，本质上就是冲着这个"碎"字去的：把采集、编辑、成图、质检、入库、更新这几段工序尽量拢到一个平台里，让同一条数据从头走到尾，而不是每换一道工序就换一个格式、换一份副本。这篇就按我自己的理解和实际作业经验，把这类平台的内核、落地路径、以及真正会翻车的地方讲透，新人能照着上手，老手也能对着挑刺。

1. 从"几套软件轮着切"到"一个平台"：基础空间数据生产的真实痛点

1.1 数据在软件之间搬来搬去，损耗到底发生在哪一步

先说说传统链路长什么样，因为不把这个说清楚，"数据工厂"这个词就只是一个好听的名字。一个典型的 1:500 或 1:2000 基础地形图生产项目，流程大致是：外业用全站仪、RTK 采集，回来导出成某种中间格式；内业用 CAD 系软件（或者基于 CAD 的二次开发工具）做图形编辑、符号化、成图；然后为了入库，再转成另一种能带属性的格式；最后用单独的检查工具做拓扑和属性检查，用单独的脚本写库。这里头有三次以上的格式转换，每一次转换都意味着一次"信息裁剪"。

裁剪掉的是什么？我列几个最常见的：图层名和要素代码的对应关系丢了，因为 DWG 的图层名是人起的，而入库标准要的是国标要素分类代码；线宽、颜色、线型这种"看着像"的符号信息，在转成 GIS 数据时大部分没有意义，但作业员往往会因为符号显示不正常而反复调整图形本身，改出一些本来不该有的小折点；属性字段在 DWG 里通常只能塞进扩展数据或者块属性，字段长度、类型、值域约束经常在转换时被静默截断或改写；还有闭合面的方向、重复点、微短边、悬挂点，这些在 CAD 里不影响看图，一入库就是一堆错误。

真正的损耗不在文件本身，而在信息与载体绑定得太松。图形是图形，属性是属性，标准是标准，三者靠人的记忆和一张写满注意事项的 Word 文档维系。人一多、图幅一多、工期一紧，就一定出问题。所谓数据工厂，第一步就是把这三者绑死：图形存在哪、属性挂在哪、按哪套编码校验，全都由平台里的模板和规则说了算，作业员不需要"记住"，只需要"照做"。

1.2 "一套数据"要治的是同源病，不是格式病

题面里的说法是"一个平台，一套数据（也有人写成'一套数码'，本质指的是同一套数据资产），一体化生产"。我特别想强调"一套数据"这四个字，因为很多人把它理解成"支持多格式导入导出"，那就理解偏了。

多格式互转解决的是格式病，一套数据解决的是同源病。什么叫同源病？就是同一个地物，在不同环节、不同人手里出现了多个版本：外业采的原线、内业修过的线、成图后为了美观再调整过的线、入库时被人顺手打断过的线。这四条线在数据库里可能就是四个要素，谁也不服谁。到了年度更新的时候，你根本不知道该以哪条为基准去叠最新的影像。

平台化的做法是：让这套数据只有一个主版本，图形、属性、符号表现、拓扑关系都是同一个要素的不同"视图"。编辑的时候改的是要素本身，符号是渲染出来的，图幅是裁出来的，入库是同一份要素换了个存储位置。听起来很理想，落地时也确实有折扣——后面第 5 节我会讲哪些折扣必须接受——但方向是这个方向，判断一个平台是不是真的"数据工厂"，就看它编辑的对象是"要素"还是"图形文件"。

1.3 哪些团队真的需要这类平台，哪些不需要

不是所有做空间数据的团队都值得上这类平台。我的判断标准比较土，就看三条：

• 数据要入库并长期维护，不是只交一张图或者一个 PDF；
• 作业人数在三人以上，或者图幅数量在几十幅以上，靠一个人盯全部细节已经盯不住了；
• 有明确的行业标准或者甲方标准要对齐，编码、分层、属性字典不是自己随便定的。

三条里中两条以上，平台化的收益就明显了。反过来，如果只是做一张规划示意图、一个汇报用的矢量底图，或者整个项目就一个人干两周，那用熟悉的 CAD 系工具反而更快，上平台的学习成本收不回来。这一点我在给同行做建议时从来都是这么说的，不劝人为了"先进"而先进。

2. iData 数据工厂的内核：一个平台里到底装了哪几层东西

2.1 把采集、编辑、成图、入库四段工序压到一条流水线上

我第一次系统看这类平台的模块划分时，最直观的感受是：它不是在做一个"更好的编辑器"，而是在做一条流水线。流水线的前提是每一段的输入输出都被定义清楚，前一段的输出能直接当后一段的输入，不用人工干预。落到空间数据生产上，大致是这么四段：

这张表里最关键的一行其实是第四行。传统做法中最耗时、最容易产生"两套数据"的就是成图和入库分开：为了出图好看，作业员会额外画一堆辅助线、填充、注记；为了入库干净，又得把这些删掉。平台化之后，注记是要素的附属表达、填充是面要素的样式，出图时渲染、入库时忽略，物理上只有一份数据。这一条如果做不到，所谓一体化就只是把两个软件放进同一个安装包而已。

另外要说一句实际的话：流水线不等于一键完成。接入、编辑、检查、入库每一段都仍然需要人，尤其编辑这一段，短时间内不存在"自动把地形图修好"这种事。平台省掉的是搬运和重复核对，不是省掉判断。

2.2 编码与专题分层：平台能不能"听懂"你的数据

判断一个数据工厂平台是否好用的核心指标，我个人认为是它对编码体系的支持深度。空间数据的本质是"每个要素有一个身份"，这个身份由要素分类代码、图层、属性字段共同决定。平台如果只把编码当成一个普通属性字段，那它就只是个画图工具；如果编码能驱动分层、驱动符号、驱动检查规则、驱动入库映射，它才算真正"听懂"了你的数据。

举个具体场景：一笔道路边线要素，代码是某一类，它的线型、颜色、是否需要参与拓扑闭合检查、入库时落到哪张表、哪些属性必填，全都应该由这个代码推导出来，而不是由作业员去选。作业员要做的只是判对代码。这听起来像是把负担从"选样式"转移到了"判代码"，但代码是业务信息，样式是表达信息——把人的精力放在业务判断上才是对的。

基于常见实践补充一句：成熟的平台一般会提供编码表导入能力，让你把国标或者甲方标准的要素分类表、属性字典表一次性导进去，形成项目自己的"数据字典"。这一步一定要在开工前做，中途改字典是灾难，所有已经录入的数据都要重新校验一遍。

2.3 模板、符号库和规则库：把老作业员的经验变成配置

这一层是我认为最被低估的。很多人挑平台只看编辑顺不顺手，其实真正决定项目能不能批量复制的是模板。模板里通常包含这些东西：坐标系与投影参数、图层与代码的对应、属性字段定义（名称、类型、长度、值域、是否必填）、符号样式、检查规则集合、出图图廓与图例规则。把这套东西配好、导出成一个模板文件，下一个同类型项目直接套用，新来的作业员拿到模板就能干出符合标准的活。

我见过做得比较好的团队，会把模板当资产管：命名规范、版本号、适用比例尺、适用项目类型、变更记录都写清楚，甚至用简单的文本文件做版本管理。也见过不做的团队，每接一个项目重新配一遍，配置的人一走，下一个人全靠猜。区别就在这儿。

规则库的部分，通常可以用配置的方式描述拓扑和属性检查项，比如"面要素必须闭合""同类要素不能重叠""某个字段不能为空且必须在值域内"。有些平台支持更灵活的表达式，能写出类似下面的逻辑（示意，不是某个具体版本的语法）：

{ "rule_name": "道路中心线不能有悬挂点", "target": "layer:RDLINE", "check": "dangle", "tolerance": 0.001, "level": "error", "message": "存在未与其他线要素连接的端点" }

能把这些规则沉淀下来，项目质量就不再依赖"某个老作业员有没有仔细看"，而是依赖规则跑没跑。这是平台化最实在的价值之一。

3. 一体化生产的落地路径：从外业文件到入库成果的完整链路

3.1 开工前必须先定死的五件事

我踩过的坑里，一半以上都是"开工前没定死"。基于常见实践，下面这五件事必须在第一批数据进来之前就确定，中途改的成本极高：

1. 坐标系统与投影：平面坐标、高程基准、是否带带号、单位是米还是毫米。这一条错了，后面所有东西全废。
2. 分层与编码标准：用哪个版本的要素分类标准，甲方有没有补充规定，图层名怎么起。
3. 属性字典：每个要素类型有哪些字段，哪些必填，值域是什么，字段长度够不够放实际值。
4. 精度与容差：图形接边容差、拓扑容差、采集精度要求。容差定得太松，检查跑不出来；定得太紧，全是不影响的"伪错误"，作业员会开始无视报错，这比没有检查更危险。
5. 成果与交付形式：交什么格式、分幅还是整幅、要不要出图、图廓规格是什么。

这五件事定完之后写进模板，才叫"开工"。很多项目出问题都不是技术问题，是这五件事里有一件是在干到一半才拍脑袋定的。

3.2 外业数据接入与清洗

外业回来的数据五花八门：有的给 DXF，有的给带编码的文本点文件，有的给自定义格式。接入这一段的核心工作不是"导入"，而是映射与清洗。映射指的是把外业字段对到标准字段上，比如外业的"点号"对到标准里的"点标识"，外业的"类型码"对到要素代码。清洗指的是把这些常见问题处理掉：

• 重复点、极短边（小于容差的线段），这些放在图上看不出来，进拓扑检查就是一片红；
• 高程异常值，比如某个点高程明显偏离邻域，通常是记录错误；
• 闭合面没闭合，差几毫米，肉眼看不出来；
• 属性空值或者明显超出值域的编码。

这部分我建议做一个接入前的批处理环节，把它当成固定工序，而不是"谁接谁顺手清一下"。顺手清的结果一定是每个人清的标准不一样。

3.3 内业编辑、拓扑构建与接边

编辑这一段是耗时最长的，也是平台体验差异最大的地方。我关心三件事：编辑效率、拓扑感知、批量处理能力。

编辑效率看的是快捷键、捕捉、追踪、要素级复制，以及撤销重做的稳定性。这里有个经验：不要用鼠标去找菜单，一个成熟作业员应该能在不看界面的情况下完成八成操作。项目开工前花半天时间把常用命令的快捷键按作业员习惯配一遍，这半天能省后面几十个小时。

拓扑感知指的是平台在你画线的时候就知道这条线该跟谁连、连上之后要不要打断对面。传统 CAD 是"画完再说"，平台化是"边画边约束"。我实测下来的体会是，一开始不习惯，觉得束手束脚，但一旦接受，返工率会明显下降，尤其是线状要素密集的区域。

接边是另一个大头。分幅作业的情况下，相邻图幅之间的要素必须在边界处严丝合缝：位置接上、属性一致、同一个要素不能在两幅里各有一份。平台通常提供接边检查和接边处理工具，但工具只能发现和辅助修改，判断还得人做——比如两幅的同一段路，一幅按主干道编的、一幅按次干道编的，工具不知道哪个对，得你定。

3.4 质检、成图与入库

质检我建议分三层跑，不要一把梭：

第一二层是"机器能判死的"，必须做到零容忍；第三层往往掺着人工判断，报出来之后要有人复核。我特别反对把三层混在一起跑，因为第三层经常出大量"看起来是错其实是对的"条目，一旦混在一起，作业员很快就学会"全部忽略"，第一二层的真错误也被淹没了。

成图这一段现在的平台基本都能做到"数据驱动出图"：图廓、图例、比例尺、注记、符号全部按模板渲染，改数据就改图。要注意的是注记的自动避让永远不可能完美，重要的图幅还是需要人工微调，这部分时间要算进工期里，别指望零人工。

入库则是把校验通过的要素按标准写到目标库里。这里最容易忽略的是入库后的回读验证：写完之后随机抽几个要素读回来，看看图形、属性、编码是不是和平台里一致。我见过写库脚本把某个字段长度截断的情况，图上看不出任何异常，数据已经悄悄坏了。

4. 长期维护的命门：增量更新与版本留痕

4.1 为什么全量重做这条路走不通

基础空间数据不是"做完就交"的东西，它要维护、要更新，可能每年一次，也可能按季度。早期很多团队的做法是：新影像来了，重新采一遍，全量替换。这个做法在数据量小的时候能忍，数据量一大就彻底走不通——人力消耗和全量重做一样，而且每次重做都可能引入新的不一致，历史数据里那些经过人工判断的细节全丢了。

增量更新的思路是：把新影像、新测量成果和现有数据叠在一起，只处理和变化相关的部分。哪些变了？新增的道路、拆除的建筑、改线的河道、变化的权属边界。这部分工作是"发现变化—判断变化—编辑变化"，比全量重采省得多，但前提是平台必须支持要素级编辑和变更记录。如果平台只能整幅处理，增量就无从谈起。

4.2 变更怎么留痕，怎么回滚

变更留痕这件事，我在实际项目里吃过亏才知道有多重要。当时的场景是：某个区域的建筑轮廓被改了一版，改完之后发现改错了，但已经合并进主数据，也没有记录，只能靠人工比对旧备份找回来，折腾了两天。

基于常见实践，比较稳妥的留痕方式有这么几种，可以按项目重要性选：

• 变更集（Change Set）：每次提交形成一批变更记录，记录要素的新增、修改、删除，包含操作人、时间、变更前后内容，可以按批次回滚；
• 历史表：主表存当前状态，历史表存每次变更的快照，查询用主表，追溯用历史表；
• 版本分支：按项目或者按区域拉分支，合并到主线时统一审核。

我个人的偏好是第二种加第一种：主表保证查询性能，变更集保证能整批回滚，历史表保证单个要素能追到完整演变过程。代价是存储和写库逻辑复杂一点，但换来的确定性是值得的。

还有一点必须做：变更审核。留痕只解决"能不能回滚"，不解决"改得对不对"。重要的变更应该有一道审核，至少是抽查，尤其是跨图幅、跨区域的接边变更。这不是流程上的官僚主义，我见过太多次一处改动导致相邻三幅图对不上的情况。

5. 我在实际作业里踩过或见过别人踩的坑

5.1 接边和图幅边界的一致性

接边问题的根子在于分幅是人为切割，地物是连续的。一条河从中间穿过图幅边界，如果两幅的作业员各自画各自的，边界处差半米，单幅看都没问题，拼起来就是断的。更隐蔽的是属性不一致：同一段路，两幅的等级代码不同；同一个面，两幅的边界点顺序不同导致拼接处出现极窄的缝隙或者重叠。

我的处理方式是：接边不放在最后做，而是在编辑阶段就定期做。具体做法是图幅边界附近留一条"缓冲带"，比如边界内 50 米，这一段先明确谁负责，或者由同一个人统一处理。等全部画完再接边，工作量会成倍增加，因为那时候每条线都带着属性、注记和拓扑关系，动一处牵全身。

另外，接边检查一定要包含属性对比，不能只比几何。只比几何的检查工具会告诉你"位置对上了"，但不会告诉你代码不一样。

5.2 图形改了、属性没跟上

这个坑我踩得最多，也是我认为最该被平台化解决的一类问题。典型场景：把一个建筑面拆成两个，图形操作很顺畅，但拆出来的两个面还继承着原来那个面的属性，其中一个面的户数、面积、用途其实变了，作业员忘了改。或者把一条线打断成两段，其中一段的含义已经变成了另一个要素类型，代码没改。

要减少这类问题，方法有三个：一是让平台在图形变更时主动提示需要复核的属性，比如拆面之后强制弹出属性面板；二是把能算的属性交给规则算，比如面的面积、线长，不让人手填；三是把"图形与属性一致性"作为一条独立的检查规则跑，比如"同一代码的要素，其某字段取值范围应当一致"。

人工提醒永远不如机制提醒。我见过最有效的做法是把属性面板设置成"图形变更后必须确认才能继续"，一开始大家嫌烦，两周之后就习惯了，错误率肉眼可见地降下来。

5.3 坐标系、单位与精度的小数位

这类问题属于"低级但致命"。常见的有三种：

• 单位混淆：外业给的是毫米，平台按米处理，所有数据放大一千倍，图上什么都看不见，还以为是显示问题；
• 带号问题：投影坐标带了带号，而标准要求不带，或者反过来。表现是数据和标准底图错开几百公里；
• 小数位截断：某个字段定义成两位小数，实际值需要四位，写库时被截断。这个最阴险，因为它不影响看图，也不一定被检查工具发现。

我的做法是在接入和入库两个环节各做一次显式的单位和范围检查，把数据范围打印出来看一眼，如果 X 坐标动辄几百万、Y 坐标几百万，那基本就是带号的问题。另外，属性字段长度和精度在设计字典时就按"最坏情况"留，宁可多留一位，不要刚好卡住。

5.4 大图层卡顿与操作习惯

数据量上去之后，性能问题会直接影响作业习惯，而作业习惯一变，数据质量就会跟着变。比如打开一幅图要等半分钟，作业员就会尽量避免切换视图，于是就不去做那些需要反复对照的检查；拖动卡顿，就会少放几个节点，导致线形粗糙。

常见的改善手段有：按需加载（只加载当前视图范围内的要素）、图层分级显示、把注记和符号渲染与要素编辑解耦、编辑时临时关闭复杂样式。这些设置通常平台里都有，但默认值不一定适合你的数据量，需要按项目调。

还有一个习惯问题：不要在编辑过程中开着全量实时拓扑检查。数据量大的时候它会拖慢一切，正确做法是编辑时开轻量的局部提示，阶段性跑全量检查。这个平衡点每个项目不一样，得自己试出来。

6. 平台选型和团队推广：功能清单之外该看什么

6.1 和传统工具链摆在一起比什么

如果只看功能清单，几乎每个平台都能写出一长串"支持 XXX"。我在选型时真正会去验证的是下面这几件事，而且都会要求拿真实项目数据做验证，不看演示数据：

这六项过不了三项，功能写得再多我也建议慎重。因为空间数据生产是长周期、重复度高的活，短期看功能，长期看的是模板能不能复用、错误能不能被规则拦住。

6.2 推给团队时的现实做法

平台再好，团队不用也是白搭。我自己带人推的时候总结了几条：

第一，不要一次性全换。找一个规模小、工期宽、标准清晰的项目做试点，把整个链路跑通，把模板配好，把坑踩一遍。试点的目标不是产出多少数据，而是产出一套能被复制的模板和一份"哪些做法可行、哪些不行"的清单。

第二，让作业员参与模板配置。配置模板的人如果不干具体的活，配出来的东西一定会在细节上别扭。最了解"这个字段实际填什么"的就是天天填的人。

第三，把检查结果和作业员的反馈循环打通。检查报出来的错误，如果作业员普遍认为"这不是错"，那要么是规则定错了，要么是容差定错了，必须回去改配置，而不是让作业员忍着。规则库是活的，不是刻在石头上的。

第四，保留一份学习成本预算。从熟悉的工具切到平台，前两周效率一定下降，这是正常的。如果按原有的工期压任务，作业员会用"最像老工具的方式"去用新平台，等于白换。

7. 写在最后的一点个人体会

我用下来最大的感受是，iData 数据工厂这类平台的价值不在于"某个功能特别好用"，而在于它把一个项目的约定变成了配置：坐标系、编码、属性、规则、模板，这些东西以前散在写满注意事项的文档里、散在老作业员的脑子里，现在它们存在于一个可以被复制、被检查、被版本管理的地方。一个团队真正的技术积累，其实就是这些配置。

也有想提醒的地方。平台能规范化流程，但它不能替你判断业务：一条路该编成什么等级、一个面该如何拆分，这些仍然是人的决定。所以不要指望上了平台就能减少对业务能力的要求，恰恰相反，平台把重复劳动拿掉之后，剩下的部分更考验判断力。另外，模板配得越细，前期投入越大，如果项目类型差异很大、标准各不相同，收益会比想象中低，这时候宁可少配几项，把核心的编码和检查规则配好，其他的按项目临时处理。

对我自己来说，判断一个空间数据项目会不会做砸，现在只看一件事：开工前那五件事有没有定死、有没有写进模板。定死了，后面就是体力活；没定死，后面全是返工。这话听着朴素，但确实是这些年踩出来的。