简介面向需要将 GIS 数据从 ArcGIS、GeoScene、SuperMap 等平台迁移至国产数据库的 DBA、GIS 工程师与开发人员这份 KingbaseES V8.6 数据迁移方案系统梳理了空间数据入库的可行路径。压缩包仅含 1 个 PDF 文件约 2.76MB篇幅覆盖 KingbaseES GIS 能力介绍、基于 ArcGIS 的 KDTS 工具 ETL 流程、ArcGIS/GeoScene 软件迁移、SuperMap 平台迁移以及第三方通用格式数据入库等章节。每类方案均配有迁移结果验证方法与常见问题汇总读者可据此理解源库连接、目标库配置、GIS 表与字段选择、数据导入及完整性核对等关键环节也能借助 FAQ 排查迁移中的典型异常。目前已有 136 人学习适合作为国产数据库替代与 GIS 空间数据迁移项目的参考手册。1. 需求先立住GIS 数据迁移方案为什么不能“迁过去再说”某单位要把运行了七八年的空间库整体换到 KingbaseES 上图层四百多个、要素上千万第一版做法是拿桌面端一个图层一个图层地导导到第三天卡在最大的一张道路面上进程崩了还得从头来。GIS 数据迁移方案的难点从来不在“能不能连上库”而在于几何、空间参考、要素类注册这三样东西在库与库之间并不一一对应几何能搬过去坐标系可能丢了坐标系对了上层平台又认不出这是一张要素类表。这套 KingbaseES GIS 数据迁移方案把来源拆成 ArcGIS/GeoScene、SuperMap、通用文件三类每一类都给出选型判据、迁移参数、注册步骤和验收口径。它适合正在做国产化数据库替换的 DBA、负责实施交付的 GIS 工程人员也适合把“空间数据迁移”直接当成毕设或课设题目的学生——选题本身就带完整的需求、设计、实现、验证四段结构。2. 能力底座与总体设计KGIS 插件撑起的三类空间数据存储选型之前先把底座看清楚。很多迁移方案栽跟头是因为设计者脑子里还按普通关系表在规划等到几何字段、空间索引、栅格元数据一上来参数全错。KingbaseES 的空间能力由 KGIS 插件提供它决定了数据落到库里长什么样也决定了后面迁移工具该怎么配。2.1 矢量、栅格、三维在库里的三种落法矢量数据是迁移量最大的一类。行政区划、建筑物、POI 点、道路源端常见的形态是 .shp、.geojson、.kmlCAD 那边则是 .dwg、.dxf。落到库里形态统一变成“一张业务表 一个专门的几何字段”图层的属性进普通列空间位置进几何列。这是国内外主流 GIS 平台共用的存储结构也是迁移方案能通用化的前提。-- 矢量要素落库后的典型表结构属性列 一个带类型和 SRID 约束的几何列 CREATE TABLE gis.road_network ( gid bigserial PRIMARY KEY, name varchar(128), road_level integer, geom geometry(LineString, 4490) -- 4490 为常见地理坐标系的 SRID按源端实际值改 ); -- 空间索引决定范围查询的响应速度百万级要素没有它基本等于不可用 CREATE INDEX idx_road_network_geom ON gis.road_network USING gist (geom);这段建表语句里有两个参数值得盯住。geometry(LineString, 4490)是带约束的写法第一个参数限定几何类型第二个参数限定 SRID好处是脏数据进不来——往线图层插点会直接报错避免了迁移后一堆几何类型混杂、应用层判断不完的问题。代价是迁移工具写入时必须严格对齐类型源端的 MultiLineString 混合图层要先拆或统一转成 MultiLineString。USING gist是空间索引类型别用 B-TreeB-Tree 对二维范围查询没有意义建了也只是占空间。栅格数据走的是另一条路。KGIS 把影像的元数据存进库——实际存储路径、中心点、范围框、星历参数这些像元本体仍然以 tif、img 等文件形式留在文件系统里。这样做的收益是查询效率应用先查元数据表定位到具体文件再去读影像比把几百 GB 影像塞进大对象字段要合理得多。设计时要记住一点元数据里存的是路径迁移到新环境后路径前缀往往变了这一条后面会单独说。三维数据在 KGIS 里支持 Z 维度和 M 维度能存 TIN、POLYHEDRALSURFACE 这类体积对象也有一批函数算三维对象之间的关系。但三维模型、倾斜摄影测量数据不走这条路它们按栅格的方式存也就是元数据入库、本体外挂。这个边界搞混迁移时会出现“要素数对得上但打开图层是空的”这类玄学现象。2.2 迁移链路的四层分工与选型判据整条链路拆成四层每层的输入输出都固定下来后面不管是哪个平台做源端只是换第一层的实现。第一层是抽取层负责从源端把结构定义和数据读出来。源端可能是 Oracle Spatial 里的空间表也可能是带 GIS 平台元数据的 SDE 库还可能只是一堆备份文件。第二层是结构映射层把源端的类型、长度、约束翻译成目标库的等价物几何类型和 SRID 的映射在这一层完成它是整个方案里最容易丢信息的地方。第三层是装载层按批次把数据写进目标库批量大小、游标大小、大表拆分策略都在这一层配。第四层是注册与校验层负责把装载完的表变成上层 GIS 平台能识别的要素类并给出可核对的一致性证据。选型判据我一般按下面这张表走判断顺序是从上往下命中即停源端情况推荐路径主要理由需要提前准备图层少、体量小、有 ArcGIS/GeoScene 平台在线平台自带的异构库迁移平台负责元数据一致性改动最小目标库连接、授权文件要素量大或图层多有平台在线KDTS 工具迁移支持大表拆分、批量提交可断点重来源库只读账号、目标库 sde 模式只有 Oracle Spatial 备份库没有平台KDTS 工具迁移不依赖平台元数据可直连源库抽数源库实例可用、表清单源端是 SuperMap 平台平台数据源导出再入库坐标系与要素集结构跟随平台定义目标数据源参数源端只有 shp/geojson/tif 等文件通用格式入库无库依赖可脚本化批处理编码、字段名长度、投影文件源端是倾斜摄影、三维模型按栅格方式元数据入库本体体积大不适合塞库文件目录规划、路径一致性这张表真正起作用的地方在于第三行和第六行。前者是很多人没意识到的场景客户给你一个数据库备份平台上早就没有这套服务了界面化的迁移工具根本用不了只能靠工具直连库抽数。后者则是设计阶段就必须定死的等迁到一半再发现三维模型塞不进去返工成本极高。3. ArcGIS/GeoScene 侧的数据迁移KDTS 链路上的四个步骤与两个必经环节ArcGIS 和 GeoScene 的迁移在方案里占的篇幅最大因为绝大多数存量空间库都挂在这两个平台下面。这一章按执行顺序讲先让两边互相认识再建迁移任务最后把表注册成要素类。前两步是操作第三步是很多人漏掉、导致交付验收过不去的关键点。3.1 迁移前把源端和目标端都“认识”上平台侧的第一步不是导数据是建立企业级地理数据库连接。在桌面端工具箱里找到“创建企业级地理数据库”给源库和目标库各建一次。源库填 Oracle 的实例信息目标库填 KingbaseES 的连接信息。这里有个参数特别容易翻车实例那一栏如果端口不是默认的 5432必须写成“地址,端口”的形式比如10.0.12.30,5444用逗号分隔不能写冒号也不能只写地址。写错了表现是连接超时报错信息很含糊排查起来费时间。授权文件也有讲究只能用 .ecp 格式的授权文件选错文件类型当场报错。两个库都建好连接之后还要各自执行一次“启动地理数据库”这一步会在目标库里创建 sde 用户、sde 模式以及一批平台自用的元数据表。漏了这步后面 KDTS 把表导过去了平台侧一样识别不出来。# 目标库侧先确认扩展与 sde 模式就位再让平台去初始化能省掉一轮排查 ksql -U system -d gisdb -c CREATE EXTENSION IF NOT EXISTS kgis; # sde 用户与模式建议提前建好交给平台自动创建时权限容易出问题 ksql -U system -d gisdb -c CREATE USER sde WITH PASSWORD ******; ksql -U system -d gisdb -c CREATE SCHEMA sde AUTHORIZATION sde;这两条命令不是必须的平台初始化时也会做但提前手工建好有个实际好处出问题时边界清楚。如果平台初始化失败你能立刻区分是扩展没装上还是权限不足而不是对着一句笼统的报错猜。CREATE EXTENSION要求用具有相应权限的账号执行生产环境通常由 DBA 完成实施人员不要自己拿业务账号试。3.2 KDTS 任务的四步配置与参数取值KDTS 工具本身的机制值得先讲一句它用插件方式动态加载待迁移数据库的访问接口所以支持的源库类型可以扩展。它提供的能力包括结构迁移、全量数据迁移、列名映射、表数据过滤——这几项对 GIS 场景都有用尤其是列名映射源端字段名超长或者带特殊字符时能直接改掉。新建源连接和目标连接时需要填的项包括连接名称、数据库类型、数据库版本、服务器地址、端口、用户名、密码、数据库、驱动、URL、连接参数。其中 URL 由工具根据地址端口库名自动生成但生成规则依赖两个选择源库是 Oracle 时要选 SID 还是 ServiceName目标库是 KingbaseES 时要选 JDBC 还是 UnixDomainSocket。SID 是实例标识ServiceName 是服务名集群环境下各节点 SID 可能不同但 ServiceName 一致所以集群源库优先选 ServiceName。UnixDomainSocket 只在迁移工具和目标库装在同一台 Linux 机器上时能用走本机进程间通信省掉网络开销大批量导入时能明显快一截。建任务的四步是选择数据源、选择模式、选择迁移对象、配置参数。选择模式时要注意“包含系统模式”这个复选框默认不勾勾上会把系统自带的一堆模式也列出来选错了迁移范围翻倍。选择迁移对象支持三种方式直接在输入框敲表名回车确认多个表用逗号隔开从列表里勾选可以按模式、表名关键字、数据条数限制检索从文件导入工具提供模板下载。表多的时候一定用文件导入手敲绝对会漏。反过来也可以用“排除指定表”剔除日志表、临时表这类不该迁的东西两种方式操作一致结果相反。配置参数这一步是整章最值钱的部分默认值能跑通但跑得快不快、稳不稳全看这几个数参数默认值调整建议与触发条件源库游标读取记录数100宽表或 LOB 字段多时降到 20~50避免单次游标占用内存过高批量写入目标库记录数1000字段少、行数多的小表可提到 2000~5000明显提速每次批量提交大小100MB目标库事务日志吃紧时降到 20~50MB用时间换稳定LOB 字段预读取大小4000Byte有影像二进制、长文本时提到 64KB否则会被截断或反复重读大表拆分阈值按行数或按大小单表超过千万行时启用配合拆分最大块数一起设数据库连接数100源库压力敏感时降到 10~20别和生产业务抢连接表名/列名大小写不变目标端统一小写时改这里避免应用层加引号查询大表拆分是 GIS 场景的高频需求。一个要素类动辄几千万行一次性迁移中途失败就得重来。启用拆分阈值后工具按行数或按表大小把大表切成若干块逐块迁移某块失败只重跑该块。阈值定多少没有标准答案我一般按目标库单表能承受的写入量估单块控制在 300 万到 500 万行块与块之间留出提交间隔。带大对象的表还要额外设游标读取记录数上限否则块切了但游标还是撑爆内存。非对象设置那一栏包含主键、检查约束、唯一约束、外键、索引、触发器、自动转换对象名、注释默认全选实际实施中建议先取消外键和触发器等数据全部导完再单独建能省掉大量逐行校验时间——这是踩过坑之后的习惯不是理论最优。任务建完可以选“保存”作为预迁移任务也可以选“保存并迁移”直接跑。跑完看状态栏显示“完成”就是成功显示“失败”就点详情看日志日志里通常能定位到具体哪张表哪一行出的问题。3.3 迁移后注册acrpyRegisterWithGeodatabase 不能省数据导完、行数对得上不代表交付完成。ArcGIS/GeoScene 判断一张表是不是要素类靠的是 sde 模式下的元数据表KDTS 建出来的表对这些元数据一无所知。表现就是在目录树里能看到表、能看属性、能写 SQL 查但当成图层加载时空的或者能加载却不能编辑、不能做空间分析。这一步不做验收一定被打回。注册脚本通常由迁移过程自动生成放在结果目录下形如result/2021-12-02_15-15-15/SDE/AcrpyRegisterScript/的位置文件名是acrpyRegisterWithGeodatabase.py。用法是把它拷贝到装了桌面端的机器上放进对应版本的 Python 目录比如C:\Python27\ArcGIS10.8然后用带 arcpy 的 Python 解释器执行。# 迁移后批量注册要素类不做这一步表在平台里看得见、用不了 import arcpy # sde 连接文件需提前在目录树里建好指向目标库的 sde 用户 arcpy.env.workspace rD:\conn\kingbase_sde.sde # 逐个要素类注册gid 为主键列geom 为几何列列名按实际表结构改 for fc in arcpy.ListFeatureClasses(): try: arcpy.RegisterAsObject( in_datasetfc, oid_fieldsgid, shape_fieldsgeom, geometry_typePOLYLINE # 按图层实际类型改POINT/MULTIPOLYGON 等 ) print(registered: {0}.format(fc)) except Exception as e: # 单表失败不中断整体记录下来单独排查通常是主键或几何列名不匹配 print(failed: {0} - {1}.format(fc, e))这段脚本的关键在三个参数。in_dataset是要注册的表遍历拿到的名字可能带模式前缀实际执行时按环境调整。oid_fields是对象标识列必须唯一且非空源端如果没有主键迁移时就得补一列自增。shape_fields是几何列名KDTS 默认建成 geom如果迁移时做过列名映射这里要同步改。geometry_type决定平台怎么解释几何填错的表现是图层能加但显示异常或面积周长算不出来。批量注册一定要加 try 包裹并记录失败清单。几百个图层里总有几个因为主键缺失、几何为空、类型不匹配挂掉整体中断会让你不知道从哪张表继续。4. SuperMap 与第三方通用格式另外两条入库路径的取舍不是所有源端都挂着 ArcGIS。方案里另外两条路径覆盖的场景同样常见一条是 SuperMap 平台下的存量数据一条是散落在文件系统里的通用格式文件。这两条路径比前一条简单但各自的坑一点不少。4.1 SuperMap 平台侧数据源方式导出再入库SuperMap 的迁移思路和前一条不同它不需要中间工具转一手而是利用平台自身的数据源机制。基本做法是在平台里把待迁移的数据集导出成标准格式或直接以数据源方式连接目标库配置好 KingbaseES 的连接参数后把数据集复制或导入到目标数据源。配置连接时最关键的是坐标系。SuperMap 的数据集自带坐标系定义导入目标数据源时如果目标数据源没有对应的坐标系平台会做一次转换或者直接拒绝。我的做法是先查清楚源数据集的坐标系名称和 EPSG 编码在目标端建数据源时就指定同样的坐标系让两边从一开始就对齐不留给平台自动转换的机会——自动转换在投影参数不完全一致时会引入米级误差聚落边界这类数据跑完对不上排查成本极高。导入完成后同样要检查要素数。SuperMap 会在导入日志里给出成功与失败条数失败条数不为零时日志会指出是几何无效还是字段超长。几何无效的处理办法是先做一次修复自相交、未闭合环、重复点修完再导不要指望数据库端兜底。4.2 通用格式按文件入库编码、字段名、投影三件事shp、geojson、kml、tif、img 这些文件没有数据库依赖入库方式最灵活也最容易乱。批量入库一般写脚本按目录遍历逐文件解析后写入目标表。# 批量导入 shp 的思路示意读投影、读字段、按批写入投影缺失时直接跳过并记录 import os, shapefile def import_shp(shp_path, conn, target_table): reader shapefile.Reader(shp_path, encodinggbk) # 中文属性常为 gbk指定错会乱码 fields [f[0] for f in reader.fields[1:]] # 跳过 DeletionFlag if not os.path.exists(shp_path.replace(.shp, .prj)): return skip: missing .prj # 无投影文件不入库避免 SRID 猜错 rows [] for rec in reader.iterShapeRecords(): geom_wkt rec.shape.__geo_interface__ # 转 WKT 后交给空间函数入库 rows.append((rec.record[0], geom_wkt)) # 实际写入用批量 COPY 或 executemany避免逐行提交 return ok: {0}.format(len(rows))这段示意代码里三个点值得展开。encodinggbk对应的是 .dbf 里的属性编码中文环境下十有八九是 GBK用默认 UTF-8 读出来就是乱码且不会报错只是数据错了属于典型的黑匣子问题。检查 .prj 文件存在与否是硬性判断没有投影文件就不知道坐标系猜一个 SRID 塞进去后面所有面积、距离计算都是错的。字段名截断是 shp 格式的固有限制属性名最长 10 个字符源端如果用了长字段名读出来已经被截断了入库前要做一次映射表把截断后的名字还原成业务可读的名字否则应用层对不上字段。入库 SQL 侧可以走空间构造函数也可以走批量装载。数据量大时用 COPY 先灌临时表再用一条 INSERT ... SELECT 做几何转换比逐行执行快一个数量级-- 先把 WKT 和属性灌进临时表再一次性转换几何并落正式表 CREATE TEMP TABLE stg_road (gid bigint, name text, geom_wkt text); COPY stg_road FROM /data/road.csv WITH (FORMAT csv, HEADER true); INSERT INTO gis.road_network (gid, name, geom) SELECT gid, name, ST_GeomFromText(geom_wkt, 4490) -- 第二个参数为 SRID必须与 .prj 一致 FROM stg_road WHERE ST_IsValid(ST_GeomFromText(geom_wkt, 4490)); -- 无效几何先剔除进正式表再做修复ST_GeomFromText的第二个参数就是 SRID写错的表现是数据能进但空间关系全乱。ST_IsValid过滤放在插入前目的是保证正式表里不混入自相交、未闭合这类几何后续修复有明确的待处理集合。4.3 三条路径的选择矩阵把前面几条路径摆在一起对比实施时按这张表对号入座就不会走偏维度KDTS 工具迁移平台自带迁移通用文件入库适用数据量大千万级以上中几十万到百万小到中按文件批次是否需要平台在线否是否结构迁移能力强支持约束索引触发器依赖平台元数据弱需手工建表断点续传支持按大表分块不支持需自行设计坐标系处理依赖目标表定义平台统一管理靠 .prj 与 SRID 对齐典型翻车点参数过大导致内存溢出坐标系不一致引入偏移编码与字段名截断选择原则一句话能走平台就走平台平台不可用或数据量扛不住才上工具文件类数据没有选择余地只能走第三条。三条路径可以混用一个项目里往往是大表走 KDTS、小表走平台、历史档案走文件导入前提是三条路径的目标表结构由同一份设计文档约束否则迁移完成后会出现同类数据两套表结构的情况。5. 避坑与排查迁移现场最容易翻车的五个点这一章按“现象、原因、解决”三段式展开都是实际项目里遇到过、且重复率很高的故障。第一种迁移报告全绿但图层加载后要素少了一截。现象是行数对得上、抽样也对偏偏空间查询的范围结果比预期小。原因基本是两个空间索引没建或者大表拆分时某一块失败被跳过而整体状态仍标为完成。解决办法是迁移脚本末尾强制加一次索引重建并且逐表核对行数而不是只看任务总状态。核对 SQL 很简单SELECT count(*) FROM 表名与源端对比差异超过阈值就重跑该表。第二种几何全变“未知空间参考”或者面积算出来差一个数量级。现象是图层能打开、能看到形状但量算结果离谱。原因是 SRID 丢失或混用常见于源端是地理坐标系度而目标表按投影坐标系米定义或者入库时ST_GeomFromText的第二个参数随手填了个默认值。解决办法是在迁移前把源端每个图层的坐标系导出成清单与目标表定义逐条比对不一致的先做投影转换再入库不要留到数据库端补救。这个问题在毕设答辩里特别容易被问评委一句“你这个面积单位是平方米还是平方度”就能问穿。第三种应用报“列不存在”但表里明明有这一列。现象是数据库里能看到列应用查询报错。原因几乎都是大小写目标库建表时保留了双引号导致列名变成大写或混合大小写而应用拼 SQL 时没加引号被折叠成小写。解决办法是在 KDTS 配置参数里统一设置表名列名转小写建表脚本一律不加双引号应用侧的 SQL 也保持一致。第四种栅格图层能查到记录却显示不出来。现象是元数据表里有行加载影像时空白。原因是外挂影像文件的实际路径变了元数据里存的还是旧路径。解决办法是迁移前统计所有外挂文件的路径前缀迁移后在目标环境做一次批量替换替换完抽几个图层实际加载验证别只核对条数。第五种注册脚本跑完仍然报要素类不可编辑。现象是脚本输出成功打开图层发现编辑按钮是灰的。原因是目标库的 sde 用户权限不足或者几何列与平台预期的类型不一致。排查顺序是先确认 sde 用户对目标表有相应权限再确认几何列的类型声明与图层实际类型一致线图层必须是 LineString 或 MultiLineString最后看注册日志里有没有被吞掉的异常。注意这五条里有四条不会在迁移工具的日志里报错只能靠事后的数据核对发现。所以校验脚本必须在迁移开始前就写好而不是迁完了再想怎么验。6. 验收与答辩怎么证明数据“迁完了”而不是“迁过去了”验收这件事最怕的是只报一个“迁移成功”。我给自己的规矩是三层证据缺一层都不算交付。第一层是量级对齐。每张表记录源端行数、目标端行数、差异数差异必须为零大表按分块分别核对。这一层用脚本跑输出一张对照表比人工抽检可靠得多。第二层是几何对齐。抽样比对每类图层的范围框、几何有效性比例、面积或长度汇总值。-- 按图层核对几何层的一致性要素数、无效几何数、范围框、面积汇总 SELECT count(*) AS feature_cnt, count(*) FILTER (WHERE NOT ST_IsValid(geom)) AS invalid_cnt, ST_Extent(geom) AS bbox, sum(ST_Area(geom)) AS area_sum FROM gis.road_network;ST_Extent给出范围框源端和目标端各跑一次坐标值差异在容许范围内才算通过。area_sum是面积汇总投影一致时两边数值应当非常接近差得远说明 SRID 或投影出了偏差。invalid_cnt不为零就要逐个看无效几何在后续空间分析里会引发连锁问题。第三层是业务对齐。挑三到五个典型业务场景做端到端验证比如按行政区统计道路长度、按范围查询 POI 数量、加载一个影像图层的元数据叠加。这一层跑通才算真正可用。验收项判定标准执行方式表数量与结构与源端清单一一对应字段类型无降级结构比对脚本记录数每表差异为 0逐表 count 对照几何有效性无效几何为 0 或已登记修复ST_IsValid 统计空间范围范围框坐标差在容许范围内ST_Extent 双向比对坐标系每图层 SRID 与源端清单一致系统表查询比对要素类注册全部注册成功可编辑可分析平台侧实际打开验证典型业务场景三个以上场景结果一致端到端跑一遍答辩或交付汇报时讲清楚三件事就够了为什么这么选型用这张选择矩阵回答迁移过程的关键参数怎么定用参数表回答怎么证明迁对了用这三层证据回答。评委或甲方最想听的往往不是顺利的部分而是你踩过哪些坑、怎么定位的——把第五节那五个现象讲成排查故事比念一遍成功日志有说服力得多。从那以后我每次接手这类迁移都会在动手前先把校验脚本和验收表格写好跑通了再谈开始迁。没有后悔药的事只能提前留证据。希望这套结构能帮到你把自己的那套方案讲得更硬一点。本文还有配套的精品资源点击获取 KingbaseES GIS数据迁移方案：KDTS与要素类注册
简介面向需要将 GIS 数据从 ArcGIS、GeoScene、SuperMap 等平台迁移至国产数据库的 DBA、GIS 工程师与开发人员这份 KingbaseES V8.6 数据迁移方案系统梳理了空间数据入库的可行路径。压缩包仅含 1 个 PDF 文件约 2.76MB篇幅覆盖 KingbaseES GIS 能力介绍、基于 ArcGIS 的 KDTS 工具 ETL 流程、ArcGIS/GeoScene 软件迁移、SuperMap 平台迁移以及第三方通用格式数据入库等章节。每类方案均配有迁移结果验证方法与常见问题汇总读者可据此理解源库连接、目标库配置、GIS 表与字段选择、数据导入及完整性核对等关键环节也能借助 FAQ 排查迁移中的典型异常。目前已有 136 人学习适合作为国产数据库替代与 GIS 空间数据迁移项目的参考手册。1. 需求先立住GIS 数据迁移方案为什么不能“迁过去再说”某单位要把运行了七八年的空间库整体换到 KingbaseES 上图层四百多个、要素上千万第一版做法是拿桌面端一个图层一个图层地导导到第三天卡在最大的一张道路面上进程崩了还得从头来。GIS 数据迁移方案的难点从来不在“能不能连上库”而在于几何、空间参考、要素类注册这三样东西在库与库之间并不一一对应几何能搬过去坐标系可能丢了坐标系对了上层平台又认不出这是一张要素类表。这套 KingbaseES GIS 数据迁移方案把来源拆成 ArcGIS/GeoScene、SuperMap、通用文件三类每一类都给出选型判据、迁移参数、注册步骤和验收口径。它适合正在做国产化数据库替换的 DBA、负责实施交付的 GIS 工程人员也适合把“空间数据迁移”直接当成毕设或课设题目的学生——选题本身就带完整的需求、设计、实现、验证四段结构。2. 能力底座与总体设计KGIS 插件撑起的三类空间数据存储选型之前先把底座看清楚。很多迁移方案栽跟头是因为设计者脑子里还按普通关系表在规划等到几何字段、空间索引、栅格元数据一上来参数全错。KingbaseES 的空间能力由 KGIS 插件提供它决定了数据落到库里长什么样也决定了后面迁移工具该怎么配。2.1 矢量、栅格、三维在库里的三种落法矢量数据是迁移量最大的一类。行政区划、建筑物、POI 点、道路源端常见的形态是 .shp、.geojson、.kmlCAD 那边则是 .dwg、.dxf。落到库里形态统一变成“一张业务表 一个专门的几何字段”图层的属性进普通列空间位置进几何列。这是国内外主流 GIS 平台共用的存储结构也是迁移方案能通用化的前提。-- 矢量要素落库后的典型表结构属性列 一个带类型和 SRID 约束的几何列 CREATE TABLE gis.road_network ( gid bigserial PRIMARY KEY, name varchar(128), road_level integer, geom geometry(LineString, 4490) -- 4490 为常见地理坐标系的 SRID按源端实际值改 ); -- 空间索引决定范围查询的响应速度百万级要素没有它基本等于不可用 CREATE INDEX idx_road_network_geom ON gis.road_network USING gist (geom);这段建表语句里有两个参数值得盯住。geometry(LineString, 4490)是带约束的写法第一个参数限定几何类型第二个参数限定 SRID好处是脏数据进不来——往线图层插点会直接报错避免了迁移后一堆几何类型混杂、应用层判断不完的问题。代价是迁移工具写入时必须严格对齐类型源端的 MultiLineString 混合图层要先拆或统一转成 MultiLineString。USING gist是空间索引类型别用 B-TreeB-Tree 对二维范围查询没有意义建了也只是占空间。栅格数据走的是另一条路。KGIS 把影像的元数据存进库——实际存储路径、中心点、范围框、星历参数这些像元本体仍然以 tif、img 等文件形式留在文件系统里。这样做的收益是查询效率应用先查元数据表定位到具体文件再去读影像比把几百 GB 影像塞进大对象字段要合理得多。设计时要记住一点元数据里存的是路径迁移到新环境后路径前缀往往变了这一条后面会单独说。三维数据在 KGIS 里支持 Z 维度和 M 维度能存 TIN、POLYHEDRALSURFACE 这类体积对象也有一批函数算三维对象之间的关系。但三维模型、倾斜摄影测量数据不走这条路它们按栅格的方式存也就是元数据入库、本体外挂。这个边界搞混迁移时会出现“要素数对得上但打开图层是空的”这类玄学现象。2.2 迁移链路的四层分工与选型判据整条链路拆成四层每层的输入输出都固定下来后面不管是哪个平台做源端只是换第一层的实现。第一层是抽取层负责从源端把结构定义和数据读出来。源端可能是 Oracle Spatial 里的空间表也可能是带 GIS 平台元数据的 SDE 库还可能只是一堆备份文件。第二层是结构映射层把源端的类型、长度、约束翻译成目标库的等价物几何类型和 SRID 的映射在这一层完成它是整个方案里最容易丢信息的地方。第三层是装载层按批次把数据写进目标库批量大小、游标大小、大表拆分策略都在这一层配。第四层是注册与校验层负责把装载完的表变成上层 GIS 平台能识别的要素类并给出可核对的一致性证据。选型判据我一般按下面这张表走判断顺序是从上往下命中即停源端情况推荐路径主要理由需要提前准备图层少、体量小、有 ArcGIS/GeoScene 平台在线平台自带的异构库迁移平台负责元数据一致性改动最小目标库连接、授权文件要素量大或图层多有平台在线KDTS 工具迁移支持大表拆分、批量提交可断点重来源库只读账号、目标库 sde 模式只有 Oracle Spatial 备份库没有平台KDTS 工具迁移不依赖平台元数据可直连源库抽数源库实例可用、表清单源端是 SuperMap 平台平台数据源导出再入库坐标系与要素集结构跟随平台定义目标数据源参数源端只有 shp/geojson/tif 等文件通用格式入库无库依赖可脚本化批处理编码、字段名长度、投影文件源端是倾斜摄影、三维模型按栅格方式元数据入库本体体积大不适合塞库文件目录规划、路径一致性这张表真正起作用的地方在于第三行和第六行。前者是很多人没意识到的场景客户给你一个数据库备份平台上早就没有这套服务了界面化的迁移工具根本用不了只能靠工具直连库抽数。后者则是设计阶段就必须定死的等迁到一半再发现三维模型塞不进去返工成本极高。3. ArcGIS/GeoScene 侧的数据迁移KDTS 链路上的四个步骤与两个必经环节ArcGIS 和 GeoScene 的迁移在方案里占的篇幅最大因为绝大多数存量空间库都挂在这两个平台下面。这一章按执行顺序讲先让两边互相认识再建迁移任务最后把表注册成要素类。前两步是操作第三步是很多人漏掉、导致交付验收过不去的关键点。3.1 迁移前把源端和目标端都“认识”上平台侧的第一步不是导数据是建立企业级地理数据库连接。在桌面端工具箱里找到“创建企业级地理数据库”给源库和目标库各建一次。源库填 Oracle 的实例信息目标库填 KingbaseES 的连接信息。这里有个参数特别容易翻车实例那一栏如果端口不是默认的 5432必须写成“地址,端口”的形式比如10.0.12.30,5444用逗号分隔不能写冒号也不能只写地址。写错了表现是连接超时报错信息很含糊排查起来费时间。授权文件也有讲究只能用 .ecp 格式的授权文件选错文件类型当场报错。两个库都建好连接之后还要各自执行一次“启动地理数据库”这一步会在目标库里创建 sde 用户、sde 模式以及一批平台自用的元数据表。漏了这步后面 KDTS 把表导过去了平台侧一样识别不出来。# 目标库侧先确认扩展与 sde 模式就位再让平台去初始化能省掉一轮排查 ksql -U system -d gisdb -c CREATE EXTENSION IF NOT EXISTS kgis; # sde 用户与模式建议提前建好交给平台自动创建时权限容易出问题 ksql -U system -d gisdb -c CREATE USER sde WITH PASSWORD ******; ksql -U system -d gisdb -c CREATE SCHEMA sde AUTHORIZATION sde;这两条命令不是必须的平台初始化时也会做但提前手工建好有个实际好处出问题时边界清楚。如果平台初始化失败你能立刻区分是扩展没装上还是权限不足而不是对着一句笼统的报错猜。CREATE EXTENSION要求用具有相应权限的账号执行生产环境通常由 DBA 完成实施人员不要自己拿业务账号试。3.2 KDTS 任务的四步配置与参数取值KDTS 工具本身的机制值得先讲一句它用插件方式动态加载待迁移数据库的访问接口所以支持的源库类型可以扩展。它提供的能力包括结构迁移、全量数据迁移、列名映射、表数据过滤——这几项对 GIS 场景都有用尤其是列名映射源端字段名超长或者带特殊字符时能直接改掉。新建源连接和目标连接时需要填的项包括连接名称、数据库类型、数据库版本、服务器地址、端口、用户名、密码、数据库、驱动、URL、连接参数。其中 URL 由工具根据地址端口库名自动生成但生成规则依赖两个选择源库是 Oracle 时要选 SID 还是 ServiceName目标库是 KingbaseES 时要选 JDBC 还是 UnixDomainSocket。SID 是实例标识ServiceName 是服务名集群环境下各节点 SID 可能不同但 ServiceName 一致所以集群源库优先选 ServiceName。UnixDomainSocket 只在迁移工具和目标库装在同一台 Linux 机器上时能用走本机进程间通信省掉网络开销大批量导入时能明显快一截。建任务的四步是选择数据源、选择模式、选择迁移对象、配置参数。选择模式时要注意“包含系统模式”这个复选框默认不勾勾上会把系统自带的一堆模式也列出来选错了迁移范围翻倍。选择迁移对象支持三种方式直接在输入框敲表名回车确认多个表用逗号隔开从列表里勾选可以按模式、表名关键字、数据条数限制检索从文件导入工具提供模板下载。表多的时候一定用文件导入手敲绝对会漏。反过来也可以用“排除指定表”剔除日志表、临时表这类不该迁的东西两种方式操作一致结果相反。配置参数这一步是整章最值钱的部分默认值能跑通但跑得快不快、稳不稳全看这几个数参数默认值调整建议与触发条件源库游标读取记录数100宽表或 LOB 字段多时降到 20~50避免单次游标占用内存过高批量写入目标库记录数1000字段少、行数多的小表可提到 2000~5000明显提速每次批量提交大小100MB目标库事务日志吃紧时降到 20~50MB用时间换稳定LOB 字段预读取大小4000Byte有影像二进制、长文本时提到 64KB否则会被截断或反复重读大表拆分阈值按行数或按大小单表超过千万行时启用配合拆分最大块数一起设数据库连接数100源库压力敏感时降到 10~20别和生产业务抢连接表名/列名大小写不变目标端统一小写时改这里避免应用层加引号查询大表拆分是 GIS 场景的高频需求。一个要素类动辄几千万行一次性迁移中途失败就得重来。启用拆分阈值后工具按行数或按表大小把大表切成若干块逐块迁移某块失败只重跑该块。阈值定多少没有标准答案我一般按目标库单表能承受的写入量估单块控制在 300 万到 500 万行块与块之间留出提交间隔。带大对象的表还要额外设游标读取记录数上限否则块切了但游标还是撑爆内存。非对象设置那一栏包含主键、检查约束、唯一约束、外键、索引、触发器、自动转换对象名、注释默认全选实际实施中建议先取消外键和触发器等数据全部导完再单独建能省掉大量逐行校验时间——这是踩过坑之后的习惯不是理论最优。任务建完可以选“保存”作为预迁移任务也可以选“保存并迁移”直接跑。跑完看状态栏显示“完成”就是成功显示“失败”就点详情看日志日志里通常能定位到具体哪张表哪一行出的问题。3.3 迁移后注册acrpyRegisterWithGeodatabase 不能省数据导完、行数对得上不代表交付完成。ArcGIS/GeoScene 判断一张表是不是要素类靠的是 sde 模式下的元数据表KDTS 建出来的表对这些元数据一无所知。表现就是在目录树里能看到表、能看属性、能写 SQL 查但当成图层加载时空的或者能加载却不能编辑、不能做空间分析。这一步不做验收一定被打回。注册脚本通常由迁移过程自动生成放在结果目录下形如result/2021-12-02_15-15-15/SDE/AcrpyRegisterScript/的位置文件名是acrpyRegisterWithGeodatabase.py。用法是把它拷贝到装了桌面端的机器上放进对应版本的 Python 目录比如C:\Python27\ArcGIS10.8然后用带 arcpy 的 Python 解释器执行。# 迁移后批量注册要素类不做这一步表在平台里看得见、用不了 import arcpy # sde 连接文件需提前在目录树里建好指向目标库的 sde 用户 arcpy.env.workspace rD:\conn\kingbase_sde.sde # 逐个要素类注册gid 为主键列geom 为几何列列名按实际表结构改 for fc in arcpy.ListFeatureClasses(): try: arcpy.RegisterAsObject( in_datasetfc, oid_fieldsgid, shape_fieldsgeom, geometry_typePOLYLINE # 按图层实际类型改POINT/MULTIPOLYGON 等 ) print(registered: {0}.format(fc)) except Exception as e: # 单表失败不中断整体记录下来单独排查通常是主键或几何列名不匹配 print(failed: {0} - {1}.format(fc, e))这段脚本的关键在三个参数。in_dataset是要注册的表遍历拿到的名字可能带模式前缀实际执行时按环境调整。oid_fields是对象标识列必须唯一且非空源端如果没有主键迁移时就得补一列自增。shape_fields是几何列名KDTS 默认建成 geom如果迁移时做过列名映射这里要同步改。geometry_type决定平台怎么解释几何填错的表现是图层能加但显示异常或面积周长算不出来。批量注册一定要加 try 包裹并记录失败清单。几百个图层里总有几个因为主键缺失、几何为空、类型不匹配挂掉整体中断会让你不知道从哪张表继续。4. SuperMap 与第三方通用格式另外两条入库路径的取舍不是所有源端都挂着 ArcGIS。方案里另外两条路径覆盖的场景同样常见一条是 SuperMap 平台下的存量数据一条是散落在文件系统里的通用格式文件。这两条路径比前一条简单但各自的坑一点不少。4.1 SuperMap 平台侧数据源方式导出再入库SuperMap 的迁移思路和前一条不同它不需要中间工具转一手而是利用平台自身的数据源机制。基本做法是在平台里把待迁移的数据集导出成标准格式或直接以数据源方式连接目标库配置好 KingbaseES 的连接参数后把数据集复制或导入到目标数据源。配置连接时最关键的是坐标系。SuperMap 的数据集自带坐标系定义导入目标数据源时如果目标数据源没有对应的坐标系平台会做一次转换或者直接拒绝。我的做法是先查清楚源数据集的坐标系名称和 EPSG 编码在目标端建数据源时就指定同样的坐标系让两边从一开始就对齐不留给平台自动转换的机会——自动转换在投影参数不完全一致时会引入米级误差聚落边界这类数据跑完对不上排查成本极高。导入完成后同样要检查要素数。SuperMap 会在导入日志里给出成功与失败条数失败条数不为零时日志会指出是几何无效还是字段超长。几何无效的处理办法是先做一次修复自相交、未闭合环、重复点修完再导不要指望数据库端兜底。4.2 通用格式按文件入库编码、字段名、投影三件事shp、geojson、kml、tif、img 这些文件没有数据库依赖入库方式最灵活也最容易乱。批量入库一般写脚本按目录遍历逐文件解析后写入目标表。# 批量导入 shp 的思路示意读投影、读字段、按批写入投影缺失时直接跳过并记录 import os, shapefile def import_shp(shp_path, conn, target_table): reader shapefile.Reader(shp_path, encodinggbk) # 中文属性常为 gbk指定错会乱码 fields [f[0] for f in reader.fields[1:]] # 跳过 DeletionFlag if not os.path.exists(shp_path.replace(.shp, .prj)): return skip: missing .prj # 无投影文件不入库避免 SRID 猜错 rows [] for rec in reader.iterShapeRecords(): geom_wkt rec.shape.__geo_interface__ # 转 WKT 后交给空间函数入库 rows.append((rec.record[0], geom_wkt)) # 实际写入用批量 COPY 或 executemany避免逐行提交 return ok: {0}.format(len(rows))这段示意代码里三个点值得展开。encodinggbk对应的是 .dbf 里的属性编码中文环境下十有八九是 GBK用默认 UTF-8 读出来就是乱码且不会报错只是数据错了属于典型的黑匣子问题。检查 .prj 文件存在与否是硬性判断没有投影文件就不知道坐标系猜一个 SRID 塞进去后面所有面积、距离计算都是错的。字段名截断是 shp 格式的固有限制属性名最长 10 个字符源端如果用了长字段名读出来已经被截断了入库前要做一次映射表把截断后的名字还原成业务可读的名字否则应用层对不上字段。入库 SQL 侧可以走空间构造函数也可以走批量装载。数据量大时用 COPY 先灌临时表再用一条 INSERT ... SELECT 做几何转换比逐行执行快一个数量级-- 先把 WKT 和属性灌进临时表再一次性转换几何并落正式表 CREATE TEMP TABLE stg_road (gid bigint, name text, geom_wkt text); COPY stg_road FROM /data/road.csv WITH (FORMAT csv, HEADER true); INSERT INTO gis.road_network (gid, name, geom) SELECT gid, name, ST_GeomFromText(geom_wkt, 4490) -- 第二个参数为 SRID必须与 .prj 一致 FROM stg_road WHERE ST_IsValid(ST_GeomFromText(geom_wkt, 4490)); -- 无效几何先剔除进正式表再做修复ST_GeomFromText的第二个参数就是 SRID写错的表现是数据能进但空间关系全乱。ST_IsValid过滤放在插入前目的是保证正式表里不混入自相交、未闭合这类几何后续修复有明确的待处理集合。4.3 三条路径的选择矩阵把前面几条路径摆在一起对比实施时按这张表对号入座就不会走偏维度KDTS 工具迁移平台自带迁移通用文件入库适用数据量大千万级以上中几十万到百万小到中按文件批次是否需要平台在线否是否结构迁移能力强支持约束索引触发器依赖平台元数据弱需手工建表断点续传支持按大表分块不支持需自行设计坐标系处理依赖目标表定义平台统一管理靠 .prj 与 SRID 对齐典型翻车点参数过大导致内存溢出坐标系不一致引入偏移编码与字段名截断选择原则一句话能走平台就走平台平台不可用或数据量扛不住才上工具文件类数据没有选择余地只能走第三条。三条路径可以混用一个项目里往往是大表走 KDTS、小表走平台、历史档案走文件导入前提是三条路径的目标表结构由同一份设计文档约束否则迁移完成后会出现同类数据两套表结构的情况。5. 避坑与排查迁移现场最容易翻车的五个点这一章按“现象、原因、解决”三段式展开都是实际项目里遇到过、且重复率很高的故障。第一种迁移报告全绿但图层加载后要素少了一截。现象是行数对得上、抽样也对偏偏空间查询的范围结果比预期小。原因基本是两个空间索引没建或者大表拆分时某一块失败被跳过而整体状态仍标为完成。解决办法是迁移脚本末尾强制加一次索引重建并且逐表核对行数而不是只看任务总状态。核对 SQL 很简单SELECT count(*) FROM 表名与源端对比差异超过阈值就重跑该表。第二种几何全变“未知空间参考”或者面积算出来差一个数量级。现象是图层能打开、能看到形状但量算结果离谱。原因是 SRID 丢失或混用常见于源端是地理坐标系度而目标表按投影坐标系米定义或者入库时ST_GeomFromText的第二个参数随手填了个默认值。解决办法是在迁移前把源端每个图层的坐标系导出成清单与目标表定义逐条比对不一致的先做投影转换再入库不要留到数据库端补救。这个问题在毕设答辩里特别容易被问评委一句“你这个面积单位是平方米还是平方度”就能问穿。第三种应用报“列不存在”但表里明明有这一列。现象是数据库里能看到列应用查询报错。原因几乎都是大小写目标库建表时保留了双引号导致列名变成大写或混合大小写而应用拼 SQL 时没加引号被折叠成小写。解决办法是在 KDTS 配置参数里统一设置表名列名转小写建表脚本一律不加双引号应用侧的 SQL 也保持一致。第四种栅格图层能查到记录却显示不出来。现象是元数据表里有行加载影像时空白。原因是外挂影像文件的实际路径变了元数据里存的还是旧路径。解决办法是迁移前统计所有外挂文件的路径前缀迁移后在目标环境做一次批量替换替换完抽几个图层实际加载验证别只核对条数。第五种注册脚本跑完仍然报要素类不可编辑。现象是脚本输出成功打开图层发现编辑按钮是灰的。原因是目标库的 sde 用户权限不足或者几何列与平台预期的类型不一致。排查顺序是先确认 sde 用户对目标表有相应权限再确认几何列的类型声明与图层实际类型一致线图层必须是 LineString 或 MultiLineString最后看注册日志里有没有被吞掉的异常。注意这五条里有四条不会在迁移工具的日志里报错只能靠事后的数据核对发现。所以校验脚本必须在迁移开始前就写好而不是迁完了再想怎么验。6. 验收与答辩怎么证明数据“迁完了”而不是“迁过去了”验收这件事最怕的是只报一个“迁移成功”。我给自己的规矩是三层证据缺一层都不算交付。第一层是量级对齐。每张表记录源端行数、目标端行数、差异数差异必须为零大表按分块分别核对。这一层用脚本跑输出一张对照表比人工抽检可靠得多。第二层是几何对齐。抽样比对每类图层的范围框、几何有效性比例、面积或长度汇总值。-- 按图层核对几何层的一致性要素数、无效几何数、范围框、面积汇总 SELECT count(*) AS feature_cnt, count(*) FILTER (WHERE NOT ST_IsValid(geom)) AS invalid_cnt, ST_Extent(geom) AS bbox, sum(ST_Area(geom)) AS area_sum FROM gis.road_network;ST_Extent给出范围框源端和目标端各跑一次坐标值差异在容许范围内才算通过。area_sum是面积汇总投影一致时两边数值应当非常接近差得远说明 SRID 或投影出了偏差。invalid_cnt不为零就要逐个看无效几何在后续空间分析里会引发连锁问题。第三层是业务对齐。挑三到五个典型业务场景做端到端验证比如按行政区统计道路长度、按范围查询 POI 数量、加载一个影像图层的元数据叠加。这一层跑通才算真正可用。验收项判定标准执行方式表数量与结构与源端清单一一对应字段类型无降级结构比对脚本记录数每表差异为 0逐表 count 对照几何有效性无效几何为 0 或已登记修复ST_IsValid 统计空间范围范围框坐标差在容许范围内ST_Extent 双向比对坐标系每图层 SRID 与源端清单一致系统表查询比对要素类注册全部注册成功可编辑可分析平台侧实际打开验证典型业务场景三个以上场景结果一致端到端跑一遍答辩或交付汇报时讲清楚三件事就够了为什么这么选型用这张选择矩阵回答迁移过程的关键参数怎么定用参数表回答怎么证明迁对了用这三层证据回答。评委或甲方最想听的往往不是顺利的部分而是你踩过哪些坑、怎么定位的——把第五节那五个现象讲成排查故事比念一遍成功日志有说服力得多。从那以后我每次接手这类迁移都会在动手前先把校验脚本和验收表格写好跑通了再谈开始迁。没有后悔药的事只能提前留证据。希望这套结构能帮到你把自己的那套方案讲得更硬一点。本文还有配套的精品资源点击获取