★ FEATURED ARTICLE 简介这份资料面向国土三调内业处理与地理信息系统用户聚焦土地调查中VCT格式数据转换、检查与整理等环节适合需要提升矢量数据流转效率的测绘地理信息从业者及初、中级技术人员使用。压缩包共7个文件约18.09MB包含3个xml配置与元数据文件、2个zip压缩包工具箱及示例数据、1个pyt工具箱脚本和1份docx使用说明类型搭配覆盖工具部署、脚本调用与操作参考便于按类型快速定位所需材料。已有4663人学习说明其在国土调查相关场景中具备一定参考价值。读者可借助脚本与示例数据了解VCT与文件地理数据库互转、土地分类、地块合并、边界校正、属性赋值及数据一致性检查等功能的组织方式并结合说明文档完成工具配置与结果核对减少重复处理与格式衔接中的试错成本对初次接触此类转换流程的人员也较为友好。1. VCT 不是另一个 Shapefile交付前最后一公里卡在哪凌晨一点交付目录里放着一份图斑 GDB对方要的是几个纯文本的 VCT。很多用 arcgis 做内业的人第一次遇到这种交付格式都会愣一下——明明 Shapefile 和地理数据库都能打开为什么还要单独导出一个后缀是 .vct 的文本文件原因很朴素交换格式只认“结构”不认软件。它把文件头、要素代码、属性表结构、几何坐标、注记、属性记录按固定段落平铺成文本任何一家软件都能读但也意味着任何一个段落写错整份数据就废了。这套 V1.2 工具箱解决的就是这段“最后一公里”把图斑层按段落规则导出成 VCT把属性表结构声明写进头部再提供一个回读比对的口子让你在交付前自己先查到问题。适合三类人常年做数据汇交的作业员、负责质检把关的岗位以及要把历史 GDB 批量转成可 diff 文本的开发者。2. 拆开工具箱看结构.pyt 脚本、参数项与 VCT 段落怎么对上拿到一个压缩包先别急着双击运行。我一般会先把目录结构和入口类型看清楚再决定是在 ArcMap 里挂载还是在 ArcGIS Pro 里用命令行调。这一步花十分钟能省掉后面两小时的报错排查。2.1 先确认入口类型与运行环境解压后看根目录如果是一个.tbx说明它是二进制工具箱内部多半是模型构建器或者封装好的脚本工具如果是一个.pyt加若干.py文件那就是纯 Python 工具箱可以直接读源码。这两种的调试方式完全不同.tbx出问题只能看工具的运行消息.pyt出问题可以直接在编辑器里下断点。环境上有一条硬边界ArcMap 走的是 Python 2.7 加 32 位后台地理处理ArcGIS Pro 走的是 Python 3.x 加 64 位。同一个.pyt如果在文件开头写了from arcpy import env又在中间用了print xxx这种 Python 2 的语法扔进 Pro 里必然报语法错误。判断方法很简单用文本编辑器打开主脚本搜一下print# 快速判断脚本的 Python 版本倾向 import re with open(rD:\tools\VCT工具箱\VCTExport.py, r, encodingutf-8, errorsignore) as f: src f.read() # Python 2 特征print 后直接跟字符串、except 用逗号 py2_hits len(re.findall(r^\s*print\s[^(], src, flagsre.M)) # Python 3 特征f-string、pathlib、os.makedirs(exist_ok...) py3_hits len(re.findall(rf\|f|pathlib|exist_ok, src)) print(py2 风格语句:, py2_hits, py3 风格语句:, py3_hits)这段脚本不做任何修改只做一件事数一数两种风格的语句各出现了多少次。re.M让^匹配每一行的行首避免把字符串里的 print 也算进去errorsignore是为了防止 GBK 编码的中文注释直接让读取抛异常。结果里 py2 命中明显多的脚本就不要往 Pro 里塞反之亦然。我见过有人把 ArcMap 时代的工具箱硬挂到 Pro 上工具面板能显示一点运行就提示“脚本无效”翻车点就在这儿。挂载前还有一件事要做确认arcpy能单独导入。在 ArcMap 的 Python 窗口或者 Pro 的 Python 窗口里敲import arcpy; print(arcpy.GetInstallInfo()[Version])能出版本号说明站点包正常。这一步是排除法把“环境坏了”和“工具写错了”分开——很多所谓的工具箱报错根子在站点包被别的 Python 环境污染了。2.2 VCT 文本的段落骨架从文件头到属性记录要判断导出的结果对不对得先知道正常长什么样。VCT 是纯文本段落之间用方括号或者固定关键字分隔整体顺序大致是文件头、要素代码、属性表结构、几何数据、注记、属性数据。文件头声明坐标系类型、坐标单位、坐标缩放因子这些东西几何段里放的是按缩放因子取整后的整数坐标属性段里是按行排列的逗号分隔记录。拿一段示意片段来看不同来源的 VCT 头部字段会有差异以你手里实际文件为准[文件头] Version,2.0 CoordinateSystemType,平面直角坐标系 Dim,2 XAxisDirection,东 YAxisDirection,北 XScale,0.001 YScale,0.001 CoordinateUnit,米 [要素代码] FeatureCodeType,线 [属性结构] TableName,DLTB Field,YSDM,Char,6 Field,DLMC,Char,60 Field,TBMJ,Float,15,2关键在XScale和YScale这两行。它们决定了坐标在文本里保留几位小数缩放因子 0.001 意味着坐标乘以 1000 之后取整存储回读时再除回来。如果导出脚本按 0.001 写入而导入端按 0.01 解析出来的图斑位置会整体偏移两个数量级肉眼一看就是“数据跑到赤道附近去了”。所以拿到工具箱之后第一件事是打开导出的 VCT 用文本编辑器看一眼这两行的实际值和你源数据的坐标系约定是否一致。属性结构段里的Field行更麻烦。字符型字段带长度浮点型字段带总长和小数位一旦长度写小了导出时不会报错而是默默截断。地类名称这种字段截断一两个字从数据本身根本看不出来但质检比对时属性一致性检查会整片飘红。2.3 核心工具的参数面板该填什么工具箱里通常有三类工具数据检查、导出 VCT、导入 VCT。参数面板看着简单填错一个就前功尽弃。下面这张表是我自己的填法对应的是最常见的图斑层导出场景参数项建议取值说明与影响输入要素图斑面层单个图层不要一次塞整个数据集混合几何类型会让要素代码段写乱输出路径纯英文路径如D:\work\out\DLTB.vct中文路径在部分脚本里会因编码问题写空文件要素代码字段YSDM这类标准代码字段为空时导出会跳过该要素且不提示名称字段地类名称字段仅用于文本可读性不参与几何计算坐标缩放因子与源数据精度匹配一般为 0.001两端不一致会导致坐标整体偏移输出编码GBK 或 UTF-8与接收方约定一致选错则中文属性全变问号且不可逆是否写入注记按需注记段量大时文件体积翻几倍解析也慢表里最容易被忽略的是“要素代码字段为空”这一条。脚本的逻辑通常是遍历游标取到代码就写一行几何取不到就continue。这意味着你的图层里如果有几十个图斑代码为空导出的 VCT 会安静地少几十条记录文件本身完全合法打开也不报错。所以导出之前的属性检查不是可选项是必做项。3. 跑通第一次导出从 GDB 图斑到 VCT 交换文件的完整链路环境确认完参数也知道填什么了接下来就是把第一次导出真正跑通。这一章按“先查、再跑、后验”的顺序走每一步都有可抄的东西。3.1 导出前的四项前置检查我一般不会上来就点运行而是先用一段脚本把源数据扫一遍把能提前发现的问题一次性列出来。检查项就四个坐标系是否已定义、要素代码是否为空、面积字段口径是否一致、几何是否有空值或自相交。import arcpy fc rD:\work\三调交付.gdb\DLTB arcpy.env.workspace rD:\work\三调交付.gdb # 1) 坐标系是否已定义 sr arcpy.Describe(fc).spatialReference print(坐标系:, sr.name if sr.name ! Unknown else 未定义必须先定义投影) # 2) 要素代码为空的数量 null_code 0 with arcpy.da.SearchCursor(fc, [YSDM]) as cur: for (code,) in cur: if code is None or str(code).strip() : null_code 1 print(要素代码为空:, null_code) # 3) 面积字段与几何面积的一致性容差 0.5 平方米 bad_area 0 with arcpy.da.SearchCursor(fc, [TBMJ, SHAPEAREA]) as cur: for (attr_area, geo_area) in cur: if attr_area is None or abs(float(attr_area) - geo_area) 0.5: bad_area 1 print(面积不一致要素:, bad_area) # 4) 几何是否为空 empty_geom sum(1 for (g,) in arcpy.da.SearchCursor(fc, [SHAPE]) if g is None) print(空几何要素:, empty_geom)逻辑很直白SearchCursor逐行扫SHAPEAREA是 arcpy 提供的几何面积令牌不用自己算。容差取 0.5 平方米是个经验值因为面积字段一般保留两位小数加上投影带来的微小差异超过这个数就说明属性面积不是从当前几何算出来的可能来自更早的版本或者别的坐标系。要素代码为空那一项最要命前面说过它会安静地丢要素。这四项里任何一项不为零都不要往下走。坐标系未定义的去定义投影代码为空的去补代码面积不一致的先重算面积字段空几何的直接删掉或者修复。顺序不能反先修几何再算面积不然算完还得再算一遍。3.2 用 arcpy 调用工具箱里的导出工具参数面板点一次只能跑一个图层批量场景就得走脚本。调用的前提是知道工具箱的别名和工具名这个不用猜用 arcpy 列一下就行import arcpy tbx rD:\tools\VCT工具箱\VCT工具箱.tbx arcpy.ImportToolbox(tbx, vct) # 第二个参数是别名后面调用时用 # 列出该别名下所有工具确认实际方法名 print([t for t in dir(arcpy.vct) if not t.startswith(_)])ImportToolbox的第二个参数是给这个工具箱起的短别名起什么名字都行只要后面调用时对得上。dir()列出的是别名对象上挂载的方法也就是工具在脚本里的真实名字通常是把工具名里的空格和下划线处理过的形式比如“导出VCT”可能变成ExportVCT或者ExportVCT_ascii之类。先打印出来再写调用比凭感觉猜方法名靠谱得多。确认方法名之后正式调用大致是下面这个样子import arcpy, os arcpy.ImportToolbox(rD:\tools\VCT工具箱\VCT工具箱.tbx, vct) arcpy.env.overwriteOutput True out_dir rD:\work\out if not os.path.isdir(out_dir): os.makedirs(out_dir) layers [DLTB, XZDW, LXDW] # 图斑、线状地物、零星地物 for name in layers: src os.path.join(rD:\work\三调交付.gdb, name) dst os.path.join(out_dir, name .vct) # 关键字参数名以工具实际参数为准可用 arcpy.vct.ExportVCT.__doc__ 查 arcpy.vct.ExportVCT( in_featuressrc, out_vctdst, code_fieldYSDM, scale_factor0.001, encodingGBK ) print(已导出:, dst, os.path.getsize(dst), 字节)这段的要点有三个。overwriteOutput打开是为了让重复运行不报“输出已存在”调试阶段非常有用。循环里每个图层单独导出是因为混合几何类型会让要素代码段混乱图斑是面、线状地物是线、零星地物是点必须分开写。最后打印文件字节数是自检的第一道关如果某个图层导出的文件只有几百字节基本可以断定是空图层或者参数没传进去。关键字参数名是个坑。不同版本的工具箱里参数名可能是in_features也可能是input_feature写错了会直接抛TypeError。稳妥的做法是运行前先print(arcpy.vct.ExportVCT.__doc__)看一眼文档字符串里面通常列了参数名和顺序。或者用位置参数调用按工具参数面板从上到下的顺序传虽然可读性差点但不会因为名字对不上而失败。3.3 导出后回读用要素数量做第一道体检文件生成出来不等于成功。我习惯在导出之后立刻做一次轻量回读统计几何段里的要素条数和源图层的要素数对一下。这个方法不能验证几何精度但能挡住“空文件”“少一半”这类低级事故成本极低。import arcpy, re def count_vct_geometry(path): 统计 VCT 几何段中的要素数量按段标记切换状态 in_geom False count 0 with open(path, r, encodinggbk, errorsignore) as f: for line in f: s line.strip() if s.startswith([): # 进入几何段开始计数进入属性段或注记段则停止 in_geom (几何 in s) continue if in_geom and s: count 1 return count src_count int(arcpy.GetCount_management(rD:\work\三调交付.gdb\DLTB)[0]) vct_count count_vct_geometry(rD:\work\out\DLTB.vct) print(源要素:, src_count, VCT 记录:, vct_count, 一致 if src_count vct_count else 不一致需排查)in_geom是个状态开关遇到方括号开头的段落标记就切换只在几何段内累加非空行。这里没有去解析坐标内容因为大多数 VCT 的几何段是一条要素一行行数就等于要素数如果你们那边的格式是一条要素跨多行就把计数条件改成“以要素序号开头的行”具体看文件前几十行长什么样再定。errorsignore依旧是防编码问题读文件这一步不该因为一个乱码字节就崩掉。数字对上了说明导出链路是通的对不上先查要素代码为空的数量再查是否有多部件要素被合并或者拆分。这一步花不了半分钟但能在交付前把大部分“看起来正常其实缺数据”的情况挡下来。4. 反向导入与增量更新把 VCT 变回可编辑的图斑层导出只是半个循环。实际作业里更常见的是拿到别人给的 VCT要导回地理数据库做编辑或者把两期数据做增量比对。导入端的问题比导出端更隐蔽因为文本是人写的、机器生成的、不同软件生成的格式细节千差万别。4.1 编码、分隔符与换行符的三重陷阱VCT 是文本文本就有编码。国土行业里 GBK 还是主流但也不排除有些工具默认吐 UTF-8。判断方法不用猜用二进制方式读前几百个字节看有没有 BOM再试着按两种编码各解一次看哪种不乱码def sniff_encoding(path): with open(path, rb) as f: raw f.read(4096) if raw.startswith(b\xef\xbb\xbf): return utf-8-sig for enc in (gbk, utf-8): try: raw.decode(enc) return enc # 先试 GBK能解开就用 GBK except UnicodeDecodeError: continue return gbk # 都失败时兜底配合 errorsignore 使用 enc sniff_encoding(rD:\work\in\DLTB.vct) print(推断编码:, enc)顺序上先试 GBK 是有讲究的GBK 的字节范围比 UTF-8 宽一段 UTF-8 中文用 GBK 解通常会报错但一段 GBK 中文用 UTF-8 解几乎必然报错所以“先严后宽”能提高命中率。utf-8-sig那个分支是专门对付带 BOM 的文件BOM 三个字节如果不剥掉第一个段落标记就变成\ufeff[文件头]所有按startswith([)写的解析逻辑全部失效这个坑非常经典。分隔符和换行符同样会咬人。有的导出工具用逗号有的用制表符换行有的是\n有的是\r\n。用 Python 的open(..., newline)打开再统一处理比事后replace干净。字段值里如果本身含逗号比如某些备注字段还得考虑引号包裹这一层要看你手里的数据实际有没有这种情况先用几行样本验证别一上来就写完整解析器。4.2 图层名与要素代码的映射关系VCT 里通常不存“DLTB”这种数据库图层名而是存要素代码。导回地理数据库时得有一张映射表把代码翻译成要素类名。这张表不同地区的约定不完全一样但结构大同小异VCT 段/代码目标要素类几何类型常见字段图斑类代码DLTB面要素代码、地类名称、图斑面积线状地物代码XZDW线要素代码、宽度、长度零星地物代码LXDW点要素代码、面积注记段ZJ注记注记内容、字体、角度映射表要落成配置文件而不是写死在脚本里因为同一套工具箱在不同项目上复用时图层命名习惯经常变。我一般做成一个两列的 CSV第一列是 VCT 里的代码或段名第二列是目标要素类名脚本读 CSV 建字典遇到表里没有的代码就记一条警告跳过而不是直接崩掉。跳过要留痕日志里写清楚“第 N 行代码 XXX 未匹配已跳过”否则数据少了你都不知道从哪少的。4.3 增量更新里最容易搞错的两个字段增量场景下VCT 里常带变更类型标识新增、删除、修改和要素唯一标识。这两个字段是导入逻辑的分支依据处理错了会出现“改了没生效”或者“删了又冒出来”。要素唯一标识的作用是匹配新旧记录它必须在两期数据之间保持稳定。如果导出时用的是数据库自增 OBJECTID那换一次库 ID 就全变了增量比对直接失效正确做法是业务上指定的标识字段导出导入都带着走。变更类型的处理顺序也有讲究先删、再改、后增这个顺序能避免“新增的图斑被后面一条删除记录又干掉”这种逻辑冲突。导入脚本的基本骨架是这样import arcpy, csv mapping {} with open(rD:\tools\VCT工具箱\layer_map.csv, encodingutf-8) as f: for row in csv.reader(f): if len(row) 2: mapping[row[0].strip()] row[1].strip() # 代码 - 要素类名 arcpy.ImportToolbox(rD:\tools\VCT工具箱\VCT工具箱.tbx, vct) gdb rD:\work\导入结果.gdb for code, fc_name in mapping.items(): target gdb \\ fc_name arcpy.vct.ImportVCT( in_vctrD:\work\in\%s.vct % code, targettarget, encodingGBK, update_mode增量 # 全量/增量按工具实际枚举值填 ) print(导入完成:, fc_name)循环读取映射表一层代码对一类要素。update_mode这类枚举参数填错不是报错而是行为不对比如填了“全量”跑增量数据结果是把目标要素类清空重建之前编辑的内容全没了。这个参数面板上一般有下拉框脚本里建议先打印__doc__确认枚举字面量别凭记忆写中文。导入完成后务必用要素数量和变更类型分布做一次交叉核对新增数、删除数、修改数三者之和应该等于输入文件里的记录总数。5. 避坑排查五个让人卡到后半夜的现场工具箱本身不复杂卡人的地方几乎全在数据边界上。下面这五条是我自己踩过的按“现象、原因、解决”整理遇到同类问题可以先照着对一遍。5.1 导出成功但文件是空的现象工具面板显示运行成功绿色对勾输出目录里也有文件但用文本编辑器打开只有文件头和几行结构声明几何段一条数据都没有。原因输入路径或者图层名里带了中文或空格脚本内部用命令行方式调用某些组件时失败了但失败被吞掉工具仍然返回成功。另一种可能是输入要素类本身是空图层或者筛选条件把要素全过滤掉了。解决先把输出路径换到纯英文短路径下重试比如D:\out\test.vct别放在桌面或者深层中文目录里。再看输入图层用GetCount数一下真实数量。如果数量正常、路径也干净还是空就去工具的运行消息里翻详细输出看几何写入那一步有没有被跳过——很多时候是要素代码字段名写错游标取不到值全部continue掉了。5.2 中文属性变成问号或者乱码现象几何坐标正常要素数量也对但打开文本一看地类名称、备注这些中文字段全是问号或者出现奇怪的方块字符。原因导出编码和文件实际写入编码不一致。脚本按 UTF-8 读源数据按 GBK 写文件中间没有做转换或者反过来的情况。还有一种少见但更麻烦的源数据库的字段本身存的就是错误编码的历史数据导出只是把问题原样搬了出来。解决先在 arcpy 里把字段值打印出来看是否正常正常说明源数据没问题问题出在写文件那一步。固定用一套编码贯穿始终导出参数里的 encoding 和打开文件时的 encoding 必须一致。已经导出的乱码文件不要试图手工修直接重导编码损坏是不可逆的。源字段本身就乱码的得回到数据源头重录这个没有捷径。5.3 坐标整体偏移图斑跑到别的地方现象导入后图形能显示但位置明显不对和底图套不上或者整体平移了几百米到几公里。原因坐标缩放因子两端不一致或者导出时做了投影变换但没更新文件头里的坐标系声明。还有一种是精度丢失坐标以整数存储缩放因子取 1 而不是 0.001所有坐标被四舍五入到整米看着像偏移实际是精度被吃掉了。解决打开 VCT 文件头逐行核对XScale、YScale、CoordinateUnit三个值再和源数据的坐标系、单位对上。导入端也用同一个缩放因子去解析不要一边 0.001 一边 0.01。判断是不是精度问题有个简单办法看偏移量是不是恒定的整数值恒定说明是缩放因子的事不恒定说明是真做了投影。5.4 字段被悄悄截断属性对不上现象导入回地理数据库之后属性表里某些文本字段变短了最后几个字没了或者小数位变少了面积值有细微差异。整个过程没有任何报错。原因VCT 属性结构段里声明的字段长度比源数据的实际长度短。导出时按声明长度截断写入导入时按声明长度建字段一来一回数据就少了。浮点字段的小数位同理声明两位第三位往后就没了。解决导出前先扫一遍所有字符字段的实际最大长度和声明的对比不够就改结构声明。下面这段就是干这个的import arcpy fc rD:\work\三调交付.gdb\DLTB fields [f.name for f in arcpy.ListFields(fc) if f.type String] report {} with arcpy.da.SearchCursor(fc, fields) as cur: for row in cur: for name, val in zip(fields, row): n len(str(val)) if val else 0 if n report.get(name, 0): report[name] n for name, maxlen in report.items(): declared [f.length for f in arcpy.ListFields(fc, name)][0] flag 超长! if maxlen declared else print(name, 实际最长, maxlen, 字段声明, declared, flag)ListFields(fc, name)的第二个参数是通配符用来精确取单个字段的定义拿length属性就是声明长度。实际最大长度超过声明长度在正常数据里不该出现但如果出现了说明数据是绕过字段校验写进去的导出前必须清理否则截断必然发生。5.5 同一个工具箱在 ArcMap 能跑在 Pro 报脚本错误现象工具面板在 Pro 里也能显示出来参数也能填一点运行就报“脚本无效”或者语法错误换到 ArcMap 里同样的数据同样的参数却是好的。原因要么是 Python 版本差异2 和 3 的 print、异常语法、字符串编码处理全都不同要么是.tbx工具箱内部引用了 ArcMap 专有的组件。还有一种是 Pro 的 64 位后台地理处理对内存的要求更高大数据量的时候表现不一样。解决先确认脚本的 Python 版本倾向方法在第二章给过了。能改的就改把 print 语句、except Exception, e这类语法升上去不能改的比如依赖了 32 位专有库就老老实实在 ArcMap 里跑别硬升。文件数量大、单个要素特别复杂的场景在 Pro 里跑之前先把数据切成几块分批处理减少单次内存占用这个习惯比事后排查内存溢出省事得多。6. 进阶用法把导出压进流水线再补一套验证闭环单个图层手工点一遍没什么真正耗人的是一批几十个图层、每天早上都要重跑一次的场景。我的做法是把前面第二、三章的片段拼成一个可重复执行的脚本用配置文件驱动图层清单、字段名、输出路径全放外部脚本本体不改。批处理的关键不是循环而是失败处理。循环里某个图层导出失败了不能让它把整批打断也不能悄悄跳过不管import arcpy, os, time arcpy.ImportToolbox(rD:\tools\VCT工具箱\VCT工具箱.tbx, vct) arcpy.env.overwriteOutput True jobs [ (DLTB, 面, YSDM), (XZDW, 线, YSDM), (LXDW, 点, YSDM), ] out_dir rD:\work\out ok, fail [], [] for name, geom, code_field in jobs: src os.path.join(rD:\work\三调交付.gdb, name) dst os.path.join(out_dir, name .vct) try: arcpy.vct.ExportVCT( in_featuressrc, out_vctdst, code_fieldcode_field, scale_factor0.001, encodingGBK ) ok.append((name, os.path.getsize(dst))) except Exception as e: fail.append((name, str(e))) arcpy.AddWarning(%s 导出失败: %s % (name, e)) continue # 单个失败不影响后续图层 time.sleep(1) # 给文件句柄一点释放时间 for name, size in ok: print(OK, name, size) for name, err in fail: print(FAIL, name, err)try/except包住单次调用continue保证后面的图层继续跑最后统一汇总成功和失败清单。time.sleep(1)那一行不是玄学某些环境下文件句柄释放有延迟连续写同一个目录偶尔会撞上“文件被占用”加一秒能显著降低这种偶发失败率。验证环节我固定做三件事。第一要素数量比对源图层数量和 VCT 几何段行数必须相等第三节的函数直接复用。第二属性抽样比对随机抽二十条记录把源库字段值和 VCT 属性段对应行的值拉出来对重点看中文和带小数的字段这两类最容易出问题。第三坐标系回环把导出的 VCT 导进一个临时库读数出来的坐标系声明和源数据是否一致不一致就是文件头写错了。这三件事做完一份 VCT 才算能交出去。缓冲区分析、面积汇总、图层叠加、空间数据库、字段映射这些概念在这里都不是重点重点是每一份文件都能被追溯哪个图层、什么时间、谁导的、导完的校验结果是什么。血泪经验是这样来的早年间有一次交付前赶时间跳过了回读验证结果一个图层的要素代码字段名写成了另一个名字导出安静地少了三百多条记录对方验收时才发现整批返工。从那以后我每次导出 VCT 都强制走一遍“数量比对、属性抽样、坐标系回环”这三步哪怕只改了一个参数也要走。多花五分钟能换回一整天。希望帮到你。本文还有配套的精品资源点击获取
阅读完成 · 觉得有帮助？
