第一次把外业回来的 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 把采集、编辑、成图、入库四段工序压到一条流水线上我第一次系统看这类平台的模块划分时最直观的感受是它不是在做一个更好的编辑器而是在做一条流水线。流水线的前提是每一段的输入输出都被定义清楚前一段的输出能直接当后一段的输入不用人工干预。落到空间数据生产上大致是这么四段工序传统做法平台化做法数据接入手工导出中间格式、逐项核对按模板批量接入、自动映射字段与编码图形编辑CAD 里按图面审美改按要素类型编辑、符号由样式驱动拓扑与检查事后单独跑检查工具编辑过程中实时提示、批量检查可配规则成图与入库出图一套、入库另一套同一份要素裁幅出图、按标准写库这张表里最关键的一行其实是第四行。传统做法中最耗时、最容易产生两套数据的就是成图和入库分开为了出图好看作业员会额外画一堆辅助线、填充、注记为了入库干净又得把这些删掉。平台化之后注记是要素的附属表达、填充是面要素的样式出图时渲染、入库时忽略物理上只有一份数据。这一条如果做不到所谓一体化就只是把两个软件放进同一个安装包而已。另外要说一句实际的话流水线不等于一键完成。接入、编辑、检查、入库每一段都仍然需要人尤其编辑这一段短时间内不存在自动把地形图修好这种事。平台省掉的是搬运和重复核对不是省掉判断。2.2 编码与专题分层平台能不能听懂你的数据判断一个数据工厂平台是否好用的核心指标我个人认为是它对编码体系的支持深度。空间数据的本质是每个要素有一个身份这个身份由要素分类代码、图层、属性字段共同决定。平台如果只把编码当成一个普通属性字段那它就只是个画图工具如果编码能驱动分层、驱动符号、驱动检查规则、驱动入库映射它才算真正听懂了你的数据。举个具体场景一笔道路边线要素代码是某一类它的线型、颜色、是否需要参与拓扑闭合检查、入库时落到哪张表、哪些属性必填全都应该由这个代码推导出来而不是由作业员去选。作业员要做的只是判对代码。这听起来像是把负担从选样式转移到了判代码但代码是业务信息样式是表达信息——把人的精力放在业务判断上才是对的。基于常见实践补充一句成熟的平台一般会提供编码表导入能力让你把国标或者甲方标准的要素分类表、属性字典表一次性导进去形成项目自己的数据字典。这一步一定要在开工前做中途改字典是灾难所有已经录入的数据都要重新校验一遍。2.3 模板、符号库和规则库把老作业员的经验变成配置这一层是我认为最被低估的。很多人挑平台只看编辑顺不顺手其实真正决定项目能不能批量复制的是模板。模板里通常包含这些东西坐标系与投影参数、图层与代码的对应、属性字段定义名称、类型、长度、值域、是否必填、符号样式、检查规则集合、出图图廓与图例规则。把这套东西配好、导出成一个模板文件下一个同类型项目直接套用新来的作业员拿到模板就能干出符合标准的活。我见过做得比较好的团队会把模板当资产管命名规范、版本号、适用比例尺、适用项目类型、变更记录都写清楚甚至用简单的文本文件做版本管理。也见过不做的团队每接一个项目重新配一遍配置的人一走下一个人全靠猜。区别就在这儿。规则库的部分通常可以用配置的方式描述拓扑和属性检查项比如面要素必须闭合同类要素不能重叠某个字段不能为空且必须在值域内。有些平台支持更灵活的表达式能写出类似下面的逻辑示意不是某个具体版本的语法{ rule_name: 道路中心线不能有悬挂点, target: layer:RDLINE, check: dangle, tolerance: 0.001, level: error, message: 存在未与其他线要素连接的端点 }能把这些规则沉淀下来项目质量就不再依赖某个老作业员有没有仔细看而是依赖规则跑没跑。这是平台化最实在的价值之一。3. 一体化生产的落地路径从外业文件到入库成果的完整链路3.1 开工前必须先定死的五件事我踩过的坑里一半以上都是开工前没定死。基于常见实践下面这五件事必须在第一批数据进来之前就确定中途改的成本极高坐标系统与投影平面坐标、高程基准、是否带带号、单位是米还是毫米。这一条错了后面所有东西全废。分层与编码标准用哪个版本的要素分类标准甲方有没有补充规定图层名怎么起。属性字典每个要素类型有哪些字段哪些必填值域是什么字段长度够不够放实际值。精度与容差图形接边容差、拓扑容差、采集精度要求。容差定得太松检查跑不出来定得太紧全是不影响的伪错误作业员会开始无视报错这比没有检查更危险。成果与交付形式交什么格式、分幅还是整幅、要不要出图、图廓规格是什么。这五件事定完之后写进模板才叫开工。很多项目出问题都不是技术问题是这五件事里有一件是在干到一半才拍脑袋定的。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 数据工厂这类平台的价值不在于某个功能特别好用而在于它把一个项目的约定变成了配置坐标系、编码、属性、规则、模板这些东西以前散在写满注意事项的文档里、散在老作业员的脑子里现在它们存在于一个可以被复制、被检查、被版本管理的地方。一个团队真正的技术积累其实就是这些配置。也有想提醒的地方。平台能规范化流程但它不能替你判断业务一条路该编成什么等级、一个面该如何拆分这些仍然是人的决定。所以不要指望上了平台就能减少对业务能力的要求恰恰相反平台把重复劳动拿掉之后剩下的部分更考验判断力。另外模板配得越细前期投入越大如果项目类型差异很大、标准各不相同收益会比想象中低这时候宁可少配几项把核心的编码和检查规则配好其他的按项目临时处理。对我自己来说判断一个空间数据项目会不会做砸现在只看一件事开工前那五件事有没有定死、有没有写进模板。定死了后面就是体力活没定死后面全是返工。这话听着朴素但确实是这些年踩出来的。