简介：人大金仓-KingbaseES GIS数据迁移方案面向需将GIS数据迁入国产KingbaseES数据库的管理员、开发者和实施人员，聚焦ArcGIS/GeoScene、SuperMap及通用格式迁移，梳理抽取、转换、加载到验证的流程。文档说明KingbaseES对矢量、栅格数据及主流GIS平台的支撑，再介绍KDTS迁移步骤、连接配置、表字段选择、结果比对与常见问题排查，对兼容性和完整性校验有参考价值。内容还覆盖KDTS的ETL操作、ArcGIS/GeoScene导出导入、SuperMap工具或API迁移及通用文件入库，并配套验证与FAQ。包内为1个PDF文件，约2.76MB，按平台与迁移方式组织目录，便于查阅。已有137人学习，适合推进GIS数据入库、国产数据库替换或迁移预研的技术人员参考。

1. 从一次“图层打不开”说起：KingbaseES V8.6 GIS 迁移到底管什么

模拟项目X 的 GIS 图层在 ArcGIS 里突然打不开，排查到最后不是数据丢了，而是 KingbaseES V8.6 GIS 数据迁移方案里提到的空间类型和 SRID 没对齐。这份方案管的是把矢量、栅格、三维数据从 ArcGIS/GeoScene、SuperMap 或通用格式迁到 KGIS 空间库，适合正在做国产化替代的 DBA 和 GIS 实施人员。

它不教你怎么写空间分析算法，重点在迁移链路：源库连接、KDTS 任务、参数、迁移后注册、结果验证和 FAQ。手上有大量图层、单表体量大，或者只有数据库备份没有 GIS 平台，这套流程更对路；图层少但拓扑关系复杂，反而要谨慎。

如果你正卡在“表迁过去了、业务打不开”这一步，先把注册和空间索引这两件事补上，再谈性能。

2. KGIS 能力与迁移路线选型：矢量、栅格、三维分别落在哪张表

2.1 空间数据在库里到底怎么存：geom 字段、元数据表与切片缓存

KingbaseES 的空间能力靠 KGIS 插件撑起来，落到表结构上并不神秘。矢量数据一般转成普通表，属性列照常存，空间位置单独放在一个几何字段里，常见字段名就是geom。行政区划、道路、POI 点这些数据，迁移时最怕的不是行数多，而是几何类型和 SRID 在源端、目标端不一致，ArcGIS 一打开就报错。

栅格数据的处理思路不一样。tif、img这类影像文件体积大，KGIS 更常见的做法是把元数据、实际存储路径、中心点、范围框、星历参数等信息存进表里，影像文件本身放文件系统或共享存储。这样查询范围、分辨率、波段信息时不用反复读大文件，读取时间和空间成本都能压下来。迁移时如果只搬了元数据表，路径没跟着改，业务端就会出现“表里有记录、影像打不开”的情况。

三维数据要看类型。带 Z 值、M 值的三维几何，TIN、POLYHEDRALSURFACE 这类体积对象，KGIS 有对应的存储和函数计算能力；倾斜摄影、三维模型这类数据不要硬塞进三维几何字段，按栅格或文件缓存的方式管更稳。切片缓存更是典型，瓦片本身留在文件系统或对象存储，库里存服务配置和路径，迁移时别把瓦片目录漏掉。

提示：迁移前先把“哪些数据进库、哪些数据留在文件系统”列清楚，栅格和切片缓存最容易在验收时才发现路径没改。

2.2 三条迁移路线怎么选：KDTS、平台原生、通用格式

这份 V8.6 方案里其实给了三条路，选错路线比参数调错更折腾。第一条是 KDTS 工具迁移，适合源端空间库表多、单表体量大，或者根本没有 GIS 平台、只有数据库备份的场景。KDTS 用插件方式动态加载源库访问接口，支持结构迁移、全量数据迁移、列名映射和表数据过滤，批量能力强，但它迁完之后的平台注册、空间索引、复杂对象要额外补。

第二条是 ArcGIS/GeoScene 平台原生的异构数据库迁移，适合少量图层、小数据量，或者拓扑、关系类、附件、版本化这些平台元数据不能丢的场景。平台自己导，元数据完整度高，缺点是数据量一上来就慢，大表迁移容易卡在长事务上。第三条是通用格式入库，SHP、GeoJSON、TIF 先导出，再按目标库的表结构写进去，适合第三方平台、跨平台交换和临时数据补录，缺点是坐标系、字段类型、编码要自己盯。

我一般按三个问题判断：源端还有没有 GIS 平台可用；单表数据和总图层量有多大；业务要不要保留拓扑、关系类、版本化。有平台、图层少、元数据复杂，优先平台原生；表多、单表大、只有备份，走 KDTS；只有文件包，走通用格式。别拿 KDTS 硬迁版本化数据，也别拿平台原生去搬几十张大表，前者补元数据补到哭，后者等到下班。

2.3 迁移前必须固定的五个基线

迁移前不把基线固定，后面出了问题只能靠猜。第一是源库版本和字符集，字符集不一致时中文表名、字段名、注释最容易翻车，先做小表试迁。第二是目标库版本和 KGIS 扩展，连上去先确认扩展在不在，别等建空间表才发现函数缺。第三是 SRID 和坐标系，源端是地理坐标还是投影坐标，目标端准备用哪个 SRID，迁移任务里不要留空，更不要写成 0。第四是空间索引和权限，目标 schema 的建表权限、查询权限、注册脚本执行权限要提前给足。第五是业务连接串，ArcGIS/GeoScene 连 KingbaseES 时实例端口不是默认 5432 的，要写成IP,端口的形式，否则连接测试能过、发布服务失败。

-- 目标库侧先确认版本、扩展和字符集 SELECT version(); SELECT extname FROM pg_extension WHERE extname = 'kgis'; SHOW server_encoding;

这段检查不复杂，但顺序很重要：先看版本，确认和方案文档标注的 V8.6 能力对得上；再看pg_extension里有没有 KGIS，扩展名以现场安装为准；最后看服务端编码，后面处理中文表名、注释、导入文件编码都靠它。字符集不一致时不要直接全量迁，先挑一张带中文属性和空间字段的小表跑通。

3. KDTS 迁移空间库：连接、任务、参数与注册的完整链路

3.1 源库与目标库连接：端口、SID/ServiceName、UnixDomainSocket

KDTS 迁移之前，ArcGIS 侧要先把源库和目标库的连接打通。常见做法是在 ArcMap 里打开 ArcToolbox，走“数据管理工具 -> 地理数据库管理 -> 创建企业级地理数据库”，先配源端空间库连接，再配 KingbaseES 目标库连接。目标库连接参数里要特别注意实例端口，端口不是 5432 时不能只写 IP，要写成10.0.0.12,5444这种形式；授权文件只能用*.ecp，选错文件后面启动地理数据库会失败。

ArcCatalog 里添加数据库连接后，源库和目标库都要做一次“启动地理数据库”。这一步很多人以为只是点一下，实际是在目标库里准备地理数据库的系统表和环境，没做这一步，后面 KDTS 迁过去的表在 ArcGIS 里只能当普通表看。源端连接如果走 SID 或 ServiceName，要在 KDTS 新建连接时选对；目标端 KingbaseES 可以选 JDBC 或 UnixDomainSocket，迁移工具和目标库在同一台 Linux 服务器上时，UnixDomainSocket 能少走网络层，传输效率更高。

-- 在目标库确认当前用户、库和 schema 权限 SELECT current_user, current_database(); SELECT nspname, nspacl FROM pg_namespace WHERE nspname = 'gis';

这段 SQL 用来确认迁移账号到底是谁、连的是哪个库、目标 schema 有没有建表权限。nspacl为空不代表没权限，可能是默认权限；最稳的办法是用迁移账号实际建一张临时表再删掉。权限问题在 KDTS 里往往表现为任务跑到一半失败，日志里只给一个笼统的建表错误，提前试一次能省很多排查时间。

3.2 新建迁移任务：模式、对象、包含/排除表与过滤

KDTS 新建任务分四步：选择数据源、选择模式、选择迁移对象、配置参数。任务名称不能重复，源库和目标库连接选错后面全白做。选择模式时可以勾“包含系统模式”，但业务迁移一般只选业务 schema；模式多的时候用左上角查询框搜，至少选一种模式，否则直接报错。选了模式但没选表，系统会认为不需要迁移对象，直接跳到配置参数，这一步容易误判成“任务没建成功”。

选择迁移对象时，可以迁整个模式下的全部表，也可以“包含指定表”或“排除指定表”。包含列表支持输入框手填、从列表选择、从文件导入模板；手填时多个表用逗号分隔，回车确认。表特别多的时候，我一般先从列表里按关键字筛，再导出模板核对一遍，避免漏表。KDTS 还支持表数据过滤迁移，适合按时间、区域做增量补录，比如只迁biz_date >= DATE '2022-01-01'的数据，过滤条件要先确认字段类型和空值，不然容易把边界数据漏掉。

3.3 关键参数：游标100、批量1000、提交100MB、大表拆分

KDTS 的参数不是越多越好，几个关键项直接决定迁移是稳还是崩。表默认处理方式里有“建表/重建表”和“导入数据”，默认全选；只迁结构就把导入数据取消，只迁数据就保留目标表。表排序依据默认按行数和大字段大小交替，源库 I/O 压力大时可以改成按行数或按大小，让大表错开。源库游标读取记录数默认 100，批量写入目标库默认 1000，每次批量提交大小默认 100MB，LOB 字段预读取默认 4000Byte。大表拆分阈值可以按行数或大小拆，拆最大块数设上限，含大对象表还能单独设游标读取记录数。

血泪经验：连接数拉满到 100，源库 I/O 先顶不住。迁移窗口有限时，把源库连接数和目标库连接数降到 20 到 30，游标保持 100，批量写入 1000 起步，提交大小 100MB，先跑一张中等表看耗时和日志，再决定要不要调大。大表不拆，长事务会把回滚段和日志撑得很难看；拆得太碎，任务调度开销又上来了，按行数拆到几百万一行块比较常见。

非对象设置里包括主键、检查约束、唯一约束、外键、索引、触发器、自动转换对象名、注释。默认全选，但数据量大时我一般先迁表结构和数据，外键、触发器、注释第二轮补，减少迁移中途失败；业务要求强一致时再全选，并且把外键、触发器放到数据校验之后建。表名、列名大小写默认不变，ArcGIS 对大小写敏感的场景不要为了“好看”改成全小写，后面图层打不开还得改回来。

3.4 迁移后注册与结果验证：acrpyRegister 脚本与比对

迁移状态显示“完成”只代表数据搬完了，不代表 ArcGIS 能正常用。迁移后在形如result/2021-12-02_15-15-15/SDE/AcrpyRegisterScript/的目录下会生成acrpyRegisterWithGeodatabase.py，要把它拷贝到 ArcGIS 所在机器的 Python 目录，比如c:\Python27\ArcGIS10.8，再执行注册。注册脚本跑完，目标库里的表才具备地理数据库行为，否则在 ArcCatalog 里看得到表、编辑不了，业务端一用就报错。

验证别只看行数。对象清单对一遍：表、视图、序列、函数、索引、约束有没有漏；行数对一遍：源端和目标端count(*)是否一致；几何对一遍：几何类型、SRID、范围框是否一致；空间索引对一遍：有没有 GIST 索引；权限对一遍：业务账号能不能查、能不能编辑。大表先抽分区或按范围框比对，别一上来全表算面积。

-- 目标表行数、几何类型、SRID 和范围框 SELECT count(*) AS row_cnt FROM gis.road; SELECT ST_GeometryType(geom) AS geom_type, ST_SRID(geom) AS srid, count(*) FROM gis.road GROUP BY 1,2; SELECT ST_Extent(geom) AS bbox FROM gis.road;

row_cnt用来和源端对行数；geom_type看是不是从面变成了多面、从线变成了多线；srid为 0 说明导入时坐标系丢了，后面面积、距离计算全不可信；bbox和源端范围框对不上，优先查 SRID 和投影参数，不要先怀疑数据丢失。

-- 查看空间索引是否存在（索引名按现场替换） SELECT indexname, indexdef FROM pg_indexes WHERE schemaname = 'gis' AND tablename = 'road';

pg_indexes里能看到索引定义，空间索引一般带gist和几何字段名。没有索引时范围查询会退化成全表扫描，数据量一大业务端就卡。迁移完先建索引再跑ANALYZE，让优化器拿到统计信息，别让业务拿第一天的慢查询当结论。

4. ArcGIS/GeoScene 与 SuperMap 原生迁移：小数据量为什么反而更稳

4.1 ArcGIS/GeoScene 异构库迁移：导出、连接、导入

少量图层或者小数据量迁移，用 ArcGIS/GeoScene 平台自己的异构数据库迁移更稳。步骤不复杂：在 ArcCatalog 里建好 KingbaseES 目标库连接，启动地理数据库；源端要素类或要素集导出为 XML 工作空间文档，或者直接复制要素类；在目标库连接下粘贴、导入。平台会顺带把字段、别名、域、关系类这些元数据带过去，比 KDTS 只迁表结构省事。授权文件仍然只能用*.ecp，目标库实例端口不是默认值时要写全，目标 schema 的权限要提前给。

导入后不要只看“导入成功”。打开属性表看字段别名有没有丢，查几何看 SRID 有没有变，跑一次范围查询看空间索引有没有建。数据量小的时候，平台原生迁移的元数据完整度优势很明显；数据量一大，导出文件大、导入事务长，反而不如 KDTS 分批跑。

4.2 SuperMap 平台迁移：数据源、导出、目标源、导入

SuperMap 侧迁移到 KingbaseES，常见做法是先在平台里打开源数据源，确认数据集、坐标系和字段结构，再导出为通用格式或直接写入目标数据源。目标数据源配置 KingbaseES 连接参数，端口、库名、schema、用户名密码要和 KDTS 里一致；导入后重建空间索引，检查数据集类型是点、线、面还是文本，别把 CAD 数据集当 GIS 要素类处理。平台版本不同，导出入口和 API 名称会有差异，具体以现场版本为准，但流程绕不开“源数据源 -> 导出/复制 -> 目标数据源 -> 验证”。

SuperMap 迁移最容易翻车的是坐标系。源数据集是投影坐标，目标数据源建成了地理坐标，导入时又不做投影转换，面积和长度就会差一个量级。导入前把坐标系、单位、SRID 记下来，导入后抽几个要素对比范围框。中文属性乱码也要看，源端字符集、导出文件编码、目标库编码三个环节有一个不一致就会出问题。

4.3 平台原生 vs KDTS 的边界：什么时候不要硬上 KDTS

平台原生和 KDTS 不是谁替代谁，边界很清楚。数据量小、图层少、拓扑规则、关系类、附件、版本化这些平台元数据不能丢，优先平台原生；表多、单表大、只有数据库备份、没有 GIS 平台，走 KDTS；只有 SHP、GeoJSON、TIF 文件包，走通用格式。KDTS 强在批量、结构迁移、列名映射、过滤迁移，弱在平台注册、复杂对象和元数据；平台原生强在元数据完整，弱在大数据量吞吐。

不要硬上 KDTS 的场景：业务要求保留版本化、附件、关系类、拓扑规则，或者迁移后马上要做编辑分析。KDTS 迁过去的是表和字段，平台行为要靠注册脚本和后续配置补，补不齐就会出现“数据在、功能残”。反过来说，几十张大表、单表上亿行，平台原生导出导入等到天亮，KDTS 拆表分批跑更现实。

5. 通用格式入库与避坑排查：SHP、GeoJSON、TIF 的五个翻车点

5.1 通用格式入库：先定 SRID 再建表

通用格式入库的第一步不是建表，是定 SRID。SHP 带.prj的，先读坐标系；GeoJSON 常见是 WGS84 经纬度，但业务数据不一定；TIF 要看投影信息和像元大小。目标表建的时候把几何类型和 SRID 写死，比如geometry(Point, 4490)，不要让数据库猜。建完表再灌数据，灌完建 GIST 空间索引，最后ANALYZE。字段类型也要提前对，SHP 的日期、数值精度、文本长度和数据库类型不是一一对应，长度不够会在导入时截断。

-- 建空间表并插入一个点，SRID 按实际数据替换 CREATE TABLE gis.poi ( id bigint PRIMARY KEY, name varchar(128), geom geometry(Point, 4490) ); INSERT INTO gis.poi (id, name, geom) VALUES (1, '样例点', ST_SetSRID(ST_MakePoint(100.1, 30.2), 4490)); CREATE INDEX idx_poi_geom ON gis.poi USING gist (geom);

geometry(Point, 4490)把几何类型和 SRID 都约束住，后面插入线、面或者 SRID 不一致的数据会直接报错，比事后查ST_SRID更早发现问题。ST_SetSRID只改元数据，不做坐标转换；源数据真是 WGS84、目标要 CGCS2000，得用ST_Transform，不要拿ST_SetSRID硬改。索引建在geom上，gist是空间索引类型，建完再批量灌数据还是灌完再建，看数据量，大表一般先灌后建更快。

栅格数据入库按元数据表走：路径、中心点、范围框、分辨率、波段数、文件大小各一列，文件放共享存储。路径要用业务服务器能访问的绝对路径或统一挂载路径，别在测试机写D:\data，到生产 Linux 上找不到。迁移后抽几个影像做范围查询，确认路径可达、范围框和实际影像对得上。

5.2 批量入库的脚本组织：文件清单、编码、失败重试

文件多的时候不要手点，用清单驱动。清单里至少放path、`srid

本文还有配套的精品资源，点击获取