把一张 DWG 直接拖进 ArcGIS属性表里刷出来二十几列英文Entity、Handle、LinetypeScale 混在一起很多人第一反应是发懵。我带过几个新人几乎每个人都会问同一句话这些字段到底哪些有用、哪些能删、哪些能拿来筛选。说白了ArcGIS 里的 CAD 字段就是 AutoCAD 实体属性在 GIS 侧的一份“翻译稿”它决定了你后面能不能按图层批量提取、能不能按颜色还原出图风格、能不能用句柄追溯回原图。这篇内容适合三类人看刚接手 CAD 转 GIS 的制图与规划从业者、需要批量处理图纸的数据工程师、以及被注记乱码和面要素消失折腾过的老手。我不讲教科书式的字段定义直接把每个字段的真实取值规则、转换前后的变形、以及能直接抄的实操脚本摊开讲。1. 先搞清 CAD 在 ArcGIS 里被拆成了什么1.1 一次读取四个要素类图层躲进了字段里这是理解所有 CAD 字段的前提也是最多人绕不过去的第一个弯。你把一个 DWG 拖进 ArcGIS展开那个数据集看到的不是“道路层”“标注层”“水系层”而是 Point、Polyline、Polygon、Annotation 四个要素类。也就是说CAD 里的几何类型被提升为一级容器而 CAD 里最直观的图层划分被压缩成了一个叫 Layer 的文本字段。这个设计带来的直接后果是你没法通过“打开某个图层”来筛选数据只能通过 Layer 字段做定义查询。想只看道路中心线写Layer 道路中线想排除图框写Layer 图框。而在 ArcMap 的内容列表里展开 CAD 要素类时看到的那些按图层分组的小图标本质上是软件按 Layer 字段自动做的一次分组渲染不是真的存在那么多个要素类。我见过有人为了把 CAD 的每个图层拆成独立文件手动一个一个做筛选再导出几十个图层能耗掉一整个下午。这个动作完全可以批量化第 4 节会给脚本。先把这层关系想明白几何类型是“壳”Layer 是“标签”其余字段全是贴在实体上的属性。1.2 为什么不按图层拆要素类有人会质疑按图层拆不是更符合 CAD 用户的直觉吗。站在 GIS 的角度这个选择其实很合理。CAD 图层数量是不受控的一张市政图几十上百个图层很常见如果每个图层都生成一个要素类数据源一加载就是几百个条目符号系统、坐标系统、字段结构全部要重复管理性能也扛不住。统一成四类之后字段结构是固定的符号化可以按 Layer 做唯一值渲染一次配置就能覆盖所有图层。代价就是所有“按图层操作”的动作都得落到 SQL 或者游标上。还有一个隐性好处同一图层里混着不同几何的情况在 CAD 里极其普遍一条“围墙”图层里既有线又有块参照。如果强行按图层拆这些混合几何就得处理成多要素类反而更乱。按几何类型拆天然就把这类问题解决了。注意如果你的业务强依赖“一个图层一个文件”正确的做法是转成地理数据库之后用 Layer 字段做要素类转要素类而不是在 CAD 数据集上反复折腾因为 CAD 源是只读的。1.3 只读属性带来的一连串限制CAD 数据集在 ArcGIS 里是只读的。这句话的含义比字面上更重不只是图形不能编辑字段值也不能改连字段本身都不能删。你打开属性表那些列全部是灰的。这个限制会引出三个实操上的连锁反应。第一任何字段清洗、改名、赋值都必须先转成地理数据库要素类或 Shapefile。第二CAD 要素类的 ObjectID 是运行时生成的刷新数据源、重开工程都可能变化绝对不能拿 ObjectID 当业务主键要唯一标识只能用 Handle。第三多个 DWG 想合并成一张表必须先转 GDB否则你只能一个个加载再合并字段对不齐的概率极高。我在一个道路改造项目里就吃过这个亏。当时图省事直接在 CAD 要素类上做符号化配置想着反正只是出图。结果甲方中途换了一版图纸文件名没变但内容全改了ObjectID 重排之前配好的个别要素覆盖样式全部错位。后来改成先转 GDB、用 Handle 建唯一索引再没出现过这种问题。2. 逐个拆解 CAD 标准字段的真实含义2.1 Entity判断几何来源的第一道开关Entity 是整张表里信息密度最高的一个文本字段它记录的是这个要素在 CAD 里原本是什么实体。常见取值包括 Polyline轻量多段线、Polygon闭合多段线或面域转成的面、Point点实体、Insert块参照、Text 与 MText单行与多行文字等等。这个字段最大的价值在于它能告诉你几何是怎么来的从而判断数据质量。举个典型场景一个“建筑轮廓”图层正常情况下应该全是 Polygon。如果你查一下Entity Polyline发现有几十条那多半是画图的人没闭合或者用直线一段段拼的。这些线在 CAD 里看着像闭合的但 ArcGIS 认不出来自然也不会生成面。另一个高频用途是识别块参照。CAD 里的块在 ArcGIS 里会退化成一个点要素Entity 值为 Insert块的内部图形完全看不到。想在 GIS 里看到块的形状只能在 CAD 端先炸开Explode再导出或者用面提取的方式处理。需要提醒的是不同版本的 ArcGIS 对同一种实体的命名可能存在细微差异比如文字实体在注记要素类里的取值各版本表现不完全一致。用之前先打开字段视图对着实际数据看一眼别照抄网上的字段值列表。2.2 Layer唯一的图层抓手也是中文最容易出事的地方Layer 字段存的是 CAD 图层名原样保留包括中文、空格、特殊符号。它是你在 CAD 数据集上能做定义查询的唯一可靠字段也是转 GDB 之后做分类统计、批量拆分的主要依据。这里有个细节值得说CAD 图层名允许出现|、$、-这类字符某些老图纸还会用$0$前缀表示匿名块图层。这些名字在 ArcGIS 里能正常读取但一旦你把它用作文件名、要素类名或者 SQL 的字符串条件就可能出问题。我的习惯是转 GDB 之后统一做一次图层名清洗把特殊字符替换成下划线原值另存一个字段保留。中文图层名的风险主要在编码环节。图纸如果在不同语言环境的机器之间流转过Layer 字段可能出现乱码。判断方法很简单打开属性表看图层名是否变成一堆问号或者生僻字。如果只是个别字段乱码而图形正常基本可以定位到编码问题如果整个属性表都异常那更可能是文件本身损坏。提示CAD 数据源的文件路径同样建议用纯英文。路径里带中文或者空格在某些版本的批处理工具里会直接报错这个坑很隐蔽因为手动打开完全正常。2.3 Color 与 Linetype符号化字段的取值规则和你想的不一样Color 字段是整型但它存的不是 RGB而是 AutoCAD 颜色索引ACI。取值范围 0 到 256其中0 表示 ByBlock随块256 表示 ByLayer随层1 到 255 才是具体的索引颜色。这一点极其关键很多人看到 Color 字段里一大片 256以为是空值或者默认值其实它的意思是“这个实体的颜色由所在图层决定”。这就解释了为什么你按 Color 做唯一值符号化出来的图一片灰白——因为绝大多数实体的 Color 都是 256真正有意义的颜色信息藏在图层定义里而图层的颜色 ArcGIS 是不会单独给你的。想让颜色可用要么在 CAD 端把颜色改成具体索引色要么在 GIS 侧根据 Layer 手工配一套调色板。真彩色RGB实体的表现更麻烦。CAD 里可以给实体指定任意 RGB 值但 ArcGIS 的 Color 字段只能存索引值真彩色实体在这个字段里往往退化成近似索引或者 0/256。这是个无解的结构性问题只能靠前期规范出图前要求 CAD 端统一用索引色别在关键图层上用真彩色。Linetype 是文本字段存线型名比如 Continuous、Dashed、DASHED2 之类。注意 CAD 的线型名通常是大写ArcGIS 读取时个别版本会做大小写转换做唯一值统计时可能出现DASHED和Dashed被当成两个值的情况清洗时统一转小写比较稳。LinetypeScale 是双精度浮点对应 CAD 的全局线型比例因子。这个值直接影响虚线间隔的疏密做图纸还原时有用但对 GIS 分析基本没意义。2.4 Handle、Elevation、Thickness身份标识与第三维信息Handle 是 CAD 实体的句柄一个十六进制字符串在同一个 DWG 文件内唯一。它是我认为整个字段列表里最被低估的一个。为什么重要因为它是唯一一个能稳定回溯到原图的标识。前面说过 ObjectID 不可靠而 Handle 由 CAD 自己生成只要图纸不重新生成句柄就不变。用它可以在“GIS 发现问题 → 回 CAD 定位实体”这条链路上省掉大量时间。我在做数据质检时会把有问题的要素 Handle 导成一个清单交给制图方他们直接在 CAD 里用句柄定位比描述“第三张图右下角那条线”高效得多。Elevation 是实体的标高对应 DXF 组码 38也就是 2D 多段线所在的 Z 平面高度。很多人以为这个字段能替代 Z 值其实要分情况2D 多段线的所有顶点共用一个 Elevation而 3D 多段线的 Z 值存在每个顶点上Elevation 字段可能恒为 0。判断数据到底有没有高程最直接的办法是看要素类属性里有没有勾选“包含 Z 值”而不是看 Elevation 字段。Thickness 是拉伸厚度对应组码 39表示实体沿法线方向拉伸的高度。二维制图里这个值通常是 0只有做三维建模时才有意义。LineWeight 是线宽注意它的单位是 0.01 毫米字段里存 25 表示 0.25 毫米别直接当毫米用。下面这张表是我常用的速查字段名以实际读取为准不同版本可能有增减字段名类型真实含义常见坑Entity文本CAD 实体类型版本间取值有差异需实测Layer文本图层名中文编码、特殊字符Color长整型ACI 索引色256 是随层不是空值Linetype文本线型名大小写不统一Handle文本实体句柄十六进制不可当数字排序Elevation双精度2D 实体标高3D 多段线可能恒为 0Thickness双精度拉伸厚度二维数据基本为 0LineWeight双精度线宽1/100 毫米单位换算易错Text文本注记内容长度上限多行文字易截断2.5 Annotation 专属字段注记能不能用全看这几个Annotation 要素类是四个里面最特殊的一个它只有文字字段结构和另外三个完全不同。核心字段包括 Text文字内容、TextSize字高、TextAngle旋转角、TextJustify对齐方式、Font字体名、FontStyle字形。Text 字段有长度限制超长文字会被截断多行文字MText在部分版本里支持不完整可能只读到第一行或者干脆读不到。我遇到过一张图纸的所有说明文字都是 MText导入后 Text 字段全空最后只能让制图方在 CAD 里把多行文字炸成单行文字重新导出。TextAngle 的单位是个必须实测的坑。AutoCAD 的 DXF 组码 50 用弧度表示旋转角而 ArcGIS 侧的 TextAngle 单位在不同版本里处理方式不一致你可能会看到 1.57 这种明显是弧度的值也可能看到 90 这种明显是角度的值。判断方法很土但有效找一条你确定是 90 度的竖向标注看字段值是多少一眼就清楚了。Font 字段存的是字体文件名比如 simsun.ttc。这个字段的意义在于排查乱码——如果 Text 内容正常但显示成方块是字体缺失如果 Text 内容本身就是乱码是编码问题两者处理方式完全不同。TextJustify 用一个整数编码表示对齐方式0 到 15 之间业务上基本用不到做注记还原时才有价值。3. 字段在不同流转环节里的变形记3.1 CAD 直读与 CAD 转地理数据库字段名会变很多人以为转成 GDB 之后字段还是一模一样实际上会用“CAD 转地理数据库”工具处理之后输出要素类的字段结构发生了明确变化。最典型的是新增了两个字段CADType记录实体类型替代原来的 EntityDocPath记录源文件路径。DocPath 这个字段是批量作业的宝藏。当你把十几个 DWG 一次性转进同一个 GDB 时所有要素混在一起靠什么区分来源就是 DocPath。做数据统计、按图纸批次回溯、按来源做符号区分全指望它。如果手工一个个转这个字段就白丢了。另一个变化是字段类型和长度会被规整。CAD 源里的文本字段长度是固定上限转 GDB 时可能被拉长或截断。我一般会在转完之后立刻跑一遍字段清单比对确认关键字段Layer、Handle、Text没有被截断。注意转换工具里的“参考比例尺”参数直接影响注记要素类的字号换算。设小了注记巨大无比设大了注记小得看不见。这个参数要和最终出图比例尺对齐别随手填默认值。3.2 转 Shapefile 的字段截断与曲线致密化Shapefile 是个好东西兼容性无敌但它的字段限制会狠狠咬你一口字段名最长 10 个字符文本字段最长 254 个字符。10 个字符的限制意味着 LinetypeScale 变成 LinetypeSc 之类多个字段还可能因为前 10 位相同而冲突被自动改名成 Linetyp_1、Linetyp_2转完之后你自己都分不清哪个是哪个。文本字段 254 的上限则会让长注记直接被砍掉尾巴。更隐蔽的问题是曲线。ArcGIS 的地理数据库支持真曲线CAD 里的圆弧读进来会保留为圆弧段。一旦转成 Shapefile曲线必须被打散成折线一条平滑的圆弧可能变成上百个顶点文件体积暴涨后续做拓扑和叠加分析也会变慢。我的建议很明确中间过程一律用文件地理数据库Shapefile 只在最终交付且对方明确要求时使用。如果必须转先在 GDB 里把字段名改成 10 字符以内的短名把长文本字段拆分或截断把曲线用要素转线的方式预先致密化别指望转换工具帮你兜底。3.3 坐标单位与空间参考字段解决不了的两个硬伤CAD 文件本身没有坐标系概念它只有图纸坐标World 坐标。ArcGIS 读进来之后要素类会处于“未知坐标系”状态你得自己定义投影。这里有个经典的单位陷阱。国内大部分 CAD 制图以毫米为单位而 GIS 分析普遍以米为单位。直接把 CAD 数据定义成某个投影坐标系一条 1000 米的路会变成 1000 公里。正确做法有两种一是在 CAD 端把图纸缩放 0.001 再导出二是在 ArcGIS 里用要素类转要素类工具环境里设置 XY 缩放因子 0.001。另一个硬伤是坐标原点太远。有些图纸的 World 坐标原点在几百万米开外导入之后图形显示异常、缩放卡顿甚至不显示。这种情况需要把 CAD 图形整体平移到原点附近再导出平移到 GIS 之后再用“移动”工具搬回正确位置。这两个问题都不是字段能解决的但它们会伪装成字段问题——比如你发现 Layer 字段只有部分要素有值一查发现是部分图形跑到极远坐标去了被裁剪掉了。4. 拿字段干活四个能直接抄的实操场景4.1 用 Layer 加 Entity 做批量筛选与提取这是最高频的需求把 CAD 的几十个图层拆成独立的要素类。手工点几十次不现实用 arcpy 循环几分钟搞定。import arcpy import os dwg rC:\data\sample.dwg out_gdb rC:\data\out.gdb arcpy.env.workspace dwg # CAD 工作空间下只有四个要素类 fcs arcpy.ListFeatureClasses() print(读取到的要素类:, fcs) for fc in fcs: if fc Annotation: continue # 注记单独处理 layers set() with arcpy.da.SearchCursor(fc, [Layer]) as cur: for row in cur: if row[0]: layers.add(row[0]) for lyr in layers: safe_name lyr.replace(|, _).replace($, _).replace(-, _) out_fc os.path.join(out_gdb, f{fc}_{safe_name}) # 用要素类转要素类通过 SQL 表达式过滤 arcpy.conversion.FeatureClassToFeatureClass( fc, out_gdb, f{fc}_{safe_name}, where_clausefLayer {lyr} )这段脚本的核心思路是先遍历 Layer 拿到底有哪些图层名再逐个用 SQL 过滤导出。注意 where_clause 里的字符串拼接如果图层名里带单引号会直接崩严谨的做法是用arcpy.AddFieldDelimiters处理或者先做一次字符替换。同样的思路可以用在 Entity 上。想快速找出所有未闭合的多段线对 Polyline 要素类做Entity Polyline的筛选再叠加一个长度校验短于某个阈值的要素基本就是碎线可以批量清理。4.2 用 Handle 做主键去重与溯源块参照的重复插入是 CAD 数据的常见问题。同一个井盖块被复制了两次、叠在同一个位置GIS 里就是两个完全重合的点做统计时数量翻倍。用 Handle 去重是靠谱的做法因为每个插入的块参照有独立的句柄。但如果想找出“几何位置相同但句柄不同”的重复项就得先按坐标分组再比对。更实用的场景是溯源把 GIS 里筛选出的问题要素 Handle 导成 CSV交给制图方在 CAD 里查。import arcpy fc rC:\data\out.gdb\Point_井盖 bad_list [] with arcpy.da.SearchCursor(fc, [Handle, SHAPEXY, Layer]) as cur: for handle, xy, layer in cur: # 示例坐标落在图框外的要素 if xy and (xy[0] 0 or xy[1] 0): bad_list.append((handle, layer, xy)) with open(rC:\data\handle_check.csv, w, encodingutf-8) as f: f.write(Handle,Layer,X,Y\n) for h, l, xy in bad_list: f.write(f{h},{l},{xy[0]},{xy[1]}\n)这套流程我在好几个项目里复用效果很稳。制图方拿到 Handle 列表在 CAD 的命令行里输入(handent 句柄号)就能定位到实体比任何文字描述都准。4.3 用 Color 和 Linetype 还原出图样式甲方经常提一个要求GIS 出的图要和原 CAD 图看起来一样。这个需求单靠 ArcGIS 默认符号化基本做不到但用字段能还原个七八成。思路是按 Layer 做唯一值符号化颜色不要从 Color 字段取因为它是 256 随层。正确做法是打开 CAD把每个图层的颜色记下来或者用脚本导出图层颜色对照表在 ArcGIS 里手工配一套图层到颜色的映射。线型同理Linetype 字段能告诉你这条线是实线还是虚线但虚线的间隔比例还得配合 LinetypeScale 调。一个省事的技巧在 CAD 里先把所有图层的颜色改成索引色导出后按 Color 字段做唯一值渲染配色能自动对应上。前提是图层内部颜色统一别一个图层里混着好几种颜色那样渲染出来会花。4.4 字段清单盘点接手陌生图纸的第一件事拿到一份别人做的 CAD 图别急着画图先花五分钟做一次字段盘点。这个习惯帮我避开了无数次返工。要盘点的内容就三样每个要素类有哪些字段、Layer 有多少个唯一值各有多少要素、Entity 的类型分布。这三项能快速告诉你数据质量如何——图层数超过两百通常意味着图层管理混乱Entity 里混着 Insert 和 Polyline 说明图层没有按几何类型分层。import arcpy from collections import Counter dwg rC:\data\sample.dwg arcpy.env.workspace dwg for fc in arcpy.ListFeatureClasses(): desc arcpy.Describe(fc) print(f {fc} | 几何类型: {desc.shapeType} | 要素数: {arcpy.GetCount_management(fc)}) fields [f.name for f in arcpy.ListFields(fc) if f.type ! Geometry] print(字段:, fields) if Layer in fields: with arcpy.da.SearchCursor(fc, [Layer]) as cur: for k, v in Counter(r[0] for r in cur).most_common(10): print(f {k}: {v})跑完这段图纸的家底基本就清楚了。再决定哪些图层要提、哪些要删、哪些需要人工核对心里有数。5. 常见问题与排查实录5.1 注记读不出来或者全是乱码这是出现频率最高的问题成因至少有四种得逐一排除。第一种注记是 MText 多行文字版本兼容问题导致读不到内容。验证方法是打开 CAD看这些文字是不是多行文字实体。解决办法是让制图方炸成单行文字或者在 CAD 里用文字转换命令批量处理。第二种字体缺失。Text 字段有内容但显示成方块或者问号说明字体文件在系统里找不到。这时候改字段没用得装字体或者把文字样式换成通用字体。第三种编码不匹配导致内容本身是乱码。这种情况 Text 字段里就是一堆异常字符。处理思路是把图纸另存为兼容性更好的 DXF 版本或者统一在相同语言环境的机器上做导出。第四种注记要素类的参考比例尺设置不当字小到看不见误以为没读出来。这个最容易排查把参考比例尺调大调小试一下就知道。5.2 明明看着是闭合的面转过来却没有这是 CAD 与 GIS 的几何认知差异导致的。ArcGIS 生成面要素的条件比较严格必须是首尾点完全重合的闭合多段线或者 Hatch、面域这类本来就是面的实体。视觉上看着闭合但差了几微米的线一律不会生成面。排查方法很直接打开 Polyline 要素类对 Entity 做统计如果面图层对应的线大量落在 Polyline 里基本可以确认是闭合问题。处理手段有两种一是在 CAD 端用闭合命令修复二是在 GIS 里用要素转面工具把线强制转成面但要注意容差设置容差太大会把不该连的线连起来。还有一种情况是面确实生成了但落在 Polygon 要素类里被其他数据盖住了缩放范围看看就能确认。5.3 字段是空的、字段少了、字段名对不上三个症状对应三类原因。字段全空但图形正常通常是数据源损坏或者读取时编码异常换个文件版本重新导出试试。字段数量比预期少最常见的原因是 CAD 文件里压根没有这类实体比如没有块参照Point 要素类就不会有 Insert 相关的值也可能是版本差异导致某些字段不再单独暴露。字段名对不上八成是经过了中间转换。转 Shapefile 会被截断成 10 字符转某些格式会被自动重命名。做字段比对时永远以当前要素类的实际字段清单为准别拿记忆里的列表对照。下面这张表是我整理的高频问题速查遇到问题先扫一眼现象最可能原因排查方向属性表全灰不可编辑CAD 源只读转 GDB 后再操作Color 大量为 256实体颜色随层去 CAD 端改索引色块参照只剩一个点块未炸开CAD 端 Explode 后重导面要素缺失多段线未真正闭合查 Polyline 中的 Entity 分布文字内容为空MText 兼容问题查是否为多行文字中文图层名乱码编码不匹配换版本另存后重试图形显示异常或卡顿坐标原点过远平移至原点附近长度面积数值离谱单位为毫米缩放因子设 0.001ObjectID 每次不同运行时临时生成改用 Handle 做主键外部参照内容缺失XREF 不被解析CAD 端绑定后重导5.4 几条踩过坑之后才明白的经验第一条不要试图在 CAD 数据集上做任何持久化的工作。符号化配置、字段计算、数据清理全部先转 GDB。CAD 数据集就是一个临时的读取通道把它当成只读的“预览层”来看待心态会好很多。第二条接图先问三件事单位是毫米还是米、图层命名有没有规范、有没有用外部参照和块。这三个问题问清楚能省掉后面 80% 的返工。我现在的习惯是拿到图纸先跑一遍 4.4 节的盘点脚本把结果发给制图方确认双方对齐之后再动手。第三条Handle 列表要养成随手导出的习惯。每次做完质检把问题要素的句柄存一份 CSV 归档后期扯皮的时候这就是证据。文件名带上日期和图纸版本号比什么记忆都可靠。第四条别迷信网上抄来的字段值列表。CAD 版本、ArcGIS 版本、文件编码任何一个变量都会让实际取值产生偏差。花三十秒打开字段视图看一眼真实数据永远比查文档快。第五条如果项目周期长、图纸会反复更新建议在 GDB 里建一套固定的字段映射规则Layer 清洗后的标准名、Handle 唯一索引、来源图纸批次号。这套规则一旦定下来后面每一版图纸都按同样流程走数据可比性会好非常多。这套东西说穿了不复杂难的是每次都按规矩来。我前几年图快跳过转换直接在 CAD 源上操作前后返工的时间够我把整个流程重做三遍。现在宁可多花半小时做规范化转换也不愿意在中途被数据问题打断。
