ArcGIS Pro 域和子类型迁移：编码值、默认值与批量质检
要素类复制到新地理数据库后，属性表照样能编辑，录入人员却发现下拉选项没了、默认值不对、同一字段在不同道路等级下本应有不同约束。域和子类型是数据模型的一部分，不是界面装饰。迁移时若只搬数据，质量控制会在最隐蔽的地方失效。
ArcGIS Pro 域和子类型迁移：先把问题拆成可验证的环节
GIS 工具往往能在几秒内给出一个结果，但“工具成功运行”并不等于结果可用。处理前先固定 数据版本、CRS、几何类型、字段语义和容差/尺度；处理后再核对数量、范围、面积或统计量。把这两组检查写进流程，问题才不会在交付阶段才暴露。
编码值域约束的是取值集合
域将内部编码和值描述固定下来，例如路面类型、状态、权属。迁移时需要同时检查域名、字段类型、编码和值描述；仅名称相同并不意味着内容一致。
子类型使同一表具备分支规则
子类型以一个整数/短整数字段区分业务类别，并可为不同类型分配默认值和域。复制要素类后，子类型字段存在并不等于这些关联仍在。
数据迁移与规则迁移需分别验收
先导入 schema、域和子类型，再导入数据；最后检查字段级、子类型级的域绑定和默认值，顺序反过来很容易让异常值提前进入库。
可执行实操流程
- 在源库导出域清单、编码值、子类型字段、默认值及字段域绑定；把它们作为迁移基线。
- 在目标 geodatabase 创建或导入域，确认字段类型与源端一致；特别关注 text 与 short/integer 的差异。
- 创建子类型并逐项设置默认值、域覆盖和类型名称，再建立 Feature Class 与字段绑定。
- 导入小批样本，按子类型统计关键字段的唯一值和空值，检查是否违反域的允许集合。
- 用新增、编辑、复制要素三种操作做人工冒烟测试；将导出后的 schema 报告与源端逐项比对。
# ArcPy 思路：先复制数据模型，再追加数据narcpy.management.CreateDomain(gdb, "road_status", "Road status", "TEXT", "CODED")narcpy.management.AssignDomainToField(fc, "status", "road_status")项目避坑与质量检查
迁移中常被忽略的是“同一字段在不同子类型下绑定不同域”。全局字段域看似正确，编辑特定子类型时仍会出现错误选项。验收脚本必须按 subtype code 枚举字段绑定，而不是只读取一次字段定义。
| 检查项 | 合格信号 | 异常时优先排查 |
|---|---|---|
| 输入一致性 | 范围、CRS、字段含义可解释 | 数据源、坐标定义、空值 |
| 处理结果 | 数量与关键统计量符合预期 | 参数、分组条件、单位 |
| 空间抽检 | 边界与典型位置无明显异常 | 容差、精度、几何有效性 |
把参数选择变成可复现的判断
面对不同数据批次，不要只沿用上一次的参数。先选一个包含正常、边缘和异常样本的小范围，分别记录候选参数下的数量、范围、关键统计值与肉眼可识别的空间差异。将选择理由和被否决方案一起保存，下一次数据更新时才能快速判断是否仍在同一适用边界内。
尤其要区分数据质量问题、参数不适配和业务规则变化：三者的修正位置不同。把源数据错误靠放宽参数掩盖，短期省事，长期会让结果无法解释。
建议把“处理前后要比什么”写入项目 README。 这比保存一串截图更能让同事复跑，也能在数据更新时迅速判断差异究竟来自源数据还是算法。
FAQ
复制要素类会自动带走域吗？
取决于工具与目标库设置，不应假定。迁移后要用 schema 报告核对域内容和绑定关系。
默认值为何没有生效？
可能是子类型默认值覆盖、字段域不兼容或编辑模板未刷新；按字段级和子类型级分别检查。
能否后补域再清理数据？
可以，但成本高。已入库的非法编码需要单独识别和回填，最好先迁移规则、后迁移业务数据。
总结
域和子类型把业务规则嵌入地理数据库；迁移成功的标志是规则、默认值和数据一起可用，而非只看到要素数量相同。真正可靠的 GIS 成果不是某一次按钮点击后的图层，而是一套知道输入边界、参数理由和复核证据的可复现流程。