企业官网建设流程全解析

简介：《人大金仓-KingbaseES GIS数据迁移方案》面向需要将ArcGIS、GeoScene、SuperMap等平台空间数据迁入国产数据库的DBA、GIS开发与运维人员，围绕KingbaseES V8.6的GIS能力与迁移路径展开。文档共1个PDF文件，压缩包约2.76MB，内容按源端平台组织章节，便于按迁移场景检索。正文先介绍KingbaseES对矢量、栅格数据的存储与空间分析支持，再分别说明基于KDTS工具的ETL迁移流程、ArcGIS/GeoScene自带功能导出导入方法，以及SuperMap与第三方通用格式的入库方式，并配有迁移结果验证和FAQ。读者可据此掌握源库连接、目标库配置、表字段选择、数据校验与常见问题排查等要点，形成从迁移准备到结果核验的完整操作思路。已有137人学习，适合作为国产数据库GIS迁移的实施参考。

1. 把存量空间库切到国产库：这份 V8.6 方案先替你踩了哪些坑

GIS 数据迁移最容易翻车的地方，从来不是建表和导数，而是导完之后几何字段还在、坐标系却悄悄变了，或者 ArcGIS 连上去看不见要素类。KingbaseES V8.6 的这份 GIS 数据迁移方案，把矢量、栅格、三维三类空间数据在库里的落点，以及从 ArcGIS、GeoScene、SuperMap 和通用文件格式四条入口搬进来的操作步骤，逐条写死了。它面向的是把存量空间库从 Oracle Spatial 一类商用库切过来的 DBA 和 GIS 开发，也适合项目里只迁几个图层的实施人员。文档版本 V8.6、2022 年 9 月发布，配套的还有一本 KGIS 参考手册，两份对着看才完整。

2. KGIS 空间底座：矢量、栅格、三维在库里各长什么样

迁移方案能不能落地，第一步取决于你对目标库里「空间数据长什么样」有没有清楚的认识。很多人拿着 Oracle Spatial 的经验直接往 KingbaseES 上套，建完表发现几何字段类型对不上、图层在客户端里读不出来，回头再改就是几百万行数据重导。这一章先把落库形态讲清楚，再谈路线选型。

2.1 三类 GIS 数据的落库形态与字段结构

矢量数据是迁移里占比最大的一块。行政区划、建筑物、POI 点、道路这些数据，源端可能是.dwg、.dxf、.shp、.kml、.geojson，但进了空间数据库之后，统一变成「一张普通表 + 一个专门存空间位置的几何字段」，常见命名是geom。这一点和 Oracle Spatial 的SDO_GEOMETRY字段是对应的，区别在类型名和函数前缀，迁移时最容易在这里出问题。

栅格数据的处理思路不太一样。KGIS 具备栅格存储能力，但文档里明确的做法是：影像的实际文件仍然放在文件系统或对象存储上，库里存的是元数据——实际存储路径、中心点、范围框、星历参数等属性信息。这样做的收益是查询效率，因为按范围框检索比反复读影像文件快得多，同时省掉了把几十 GB 影像塞进库里的空间成本。三维模型、倾斜摄影这类成果，文档明确说不要按三维几何存，走栅格那套元数据方案。

三维这块值得单独说一句。KGIS 支持表示高度信息的 Z 维度和附加信息的 M 维度，也支持 TIN、POLYHEDRALSURFACE 这类体积对象建模，还带了一批计算三维对象关系的函数。但如果你手上是 BIM 模型或者倾斜摄影的 OSGB 成果，别指望按几何体整体塞进去，那是另一条技术路线。判断标准很简单：能在库里用 SQL 算出两个对象相交关系的，走几何；只能整体展示的，走文件加元数据。

2.2 KGIS 插件装没装，决定了一半的迁移方案

KingbaseES 本身是关系型数据库，空间能力来自 KGIS 插件。这个关系必须先理清楚：没有 KGIS，geometry类型不存在，ST_开头的函数不存在，空间索引也建不了，任何迁移工具导过来都只是一堆带文本字段的普通表。

所以动手之前的第一件事是确认插件状态。常见做法是连上目标库跑一条查询，看扩展和版本是否就位：

-- 确认 KGIS 扩展已安装及其版本 SELECT extname, extversion FROM sys_extension WHERE extname IN ('kgis', 'postgis'); -- 确认几何类型可用：能查到类型定义说明插件生效 SELECT typname FROM sys_type WHERE typname IN ('geometry', 'geography');

这两条查不出结果，后面所有步骤都是白做。遇到过有人折腾一下午连接参数，最后发现是目标库建库时没装插件，血泪经验。插件装好之后，还要确认目标库的默认 schema、用户名权限、表空间规划，尤其是空间索引会额外占用存储，大盘要提前算进去。

另一个容易忽略的点是几何子类型。同样是geometry，声明成geometry(Point, 4326)和裸geometry是两回事。前者会在写入时做强校验，后者什么都能塞。从 Oracle Spatial 迁过来的表，源端的维度信息和 SRID 往往藏在元数据表里，不会自动带过来，需要在建表阶段就决定好，否则迁完做空间查询会出现「明明是同一片区域，ST_Intersects却返回空」的玄学现象。

2.3 四条迁移路线的选型依据

文档给了四条入口，选错了不是不能做，是要多花几倍时间。判断维度其实就三个：数据量、源端有没有 GIS 平台在跑、要不要保留要素集和要素类的组织关系。

第一条是 KDTS 工具迁移，适用于源端是 Oracle Spatial 且数据量巨大，或者压根没有 GIS 平台、只有一份数据库备份文件的情况。它的优势是绕开 GIS 平台直接搬库，缺点是迁移后必须补一步 SDE 注册，否则客户端读不到。

第二条是 ArcGIS / GeoScene 平台自带的异构库迁移，适合少量图层、小数据量。操作是在客户端里建企业级地理数据库连接，然后导要素类。数据量一大就慢得没法看，这是它的边界。

第三条是 SuperMap 平台侧的数据源挂接与数据集拷贝，逻辑和第二条类似，差别在工具界面和类型映射表。

第四条是第三方通用格式，也就是 shp、geojson 这类文件直接入库，适合零散数据补齐或者一次性初始化。常见做法是走 GDAL 的ogr2ogr。

选型定下来之后再动手，比中途换方案省事得多。下面两章按路线拆开讲。

3. KDTS 搬大库：连接串、四个迁移任务参数与迁移后注册

KDTS 是这套方案里承担主力的一条路。它的设计思路是插件式动态加载待迁移数据库的访问接口，所以同构异构都能走，支持结构迁移、全量数据迁移、列名映射和表数据过滤。听起来很美，但真正决定成败的是连接参数填对没有、任务参数调对没有、迁移后注册做没做这三件事。

3.1 源库与目标库连接的填法与三个易错字段

新建连接的字段一共十来个：连接名称、数据库类型、数据库版本、服务器地址、端口、用户名、密码、数据库、驱动、URL、连接参数。大部分是照填，但有几个地方常年出事。

第一个是端口。如果 KingbaseES 的实例端口不是默认的 5432，在 GIS 客户端里配置连接时要在地址后面直接跟端口，写成192.168.4.30,5444这种形式，注意是逗号不是冒号。这个细节在 KDTS 和 ArcCatalog 里的表现还不完全一样，配错了报错信息又很含糊，通常只说连接失败。

第二个是 URL 的生成方式。源库是 Oracle 时要在SID和ServiceName之间选一个；目标是 KingbaseES 时要在JDBC和UnixDomainSocket之间选。选SID还是ServiceName，取决于源端是不是集群——集群环境下各节点 SID 可能不一致，但 ServiceName 是一致的，这种情况必须选ServiceName，否则你连上的是某一个节点，数据可能不全。UnixDomainSocket只在迁移工具和目标库装在同一台 Linux 机器上时可用，走本地进程间通信，传输效率比走网络高，能用就用。

第三个是驱动。驱动信息会随数据库类型和版本动态调整，但它不是无脑自动的。源端 Oracle 的版本如果和下拉框里的版本对不上，驱动加载会失败，这时候要么升级客户端组件，要么在连接参数里手工补齐。

连接建完之后，建议先在工具里做一次连通性测试，别急着建任务。连通性过了，再确认账号权限——源端要能读元数据和全表，目标端要能建表、建索引、建约束。权限不足的表现往往是任务跑到一半失败，日志里一句权限拒绝，前面几小时白等。

3.2 新建迁移任务的四步与影响成败的参数

新建任务分四步：选择数据源、选择模式、选择迁移对象、配置参数。前两步基本是点选，第三步有个细节：模式比较多的时候用左上角的查询框检索，别一屏一屏翻；如果没选表就继续，系统会认为你不需要迁移对象，直接跳过第三步进第四步，很多人以为这是 bug，其实是设计如此。

第三步里可以全迁、包含指定表、排除指定表。包含/排除支持三种录入方式：输入框直接写表名，多个用逗号分隔回车确认；从列表选择，可以按模式、表名关键字、数据条数限制检索；从文件导入，需要先下载导入模板按规则填好再传。表多的时候用文件导入，比手敲靠谱。

第四步的参数是重头戏，直接决定迁移速度和成功率。

大表拆分阈值这一组也值得单独看。可以按行数拆、按大小拆，还能设拆分最大块数，含大对象的表另有游标读取记录数上限。GIS 表的特点是「行数不多但单行巨大」，一条道路要素的几何可能几十 KB，一张几万行的路网表实际体积能到几十 GB。这种表按行数拆没意义，要按大小拆，并且把拆分块数控制在合理范围，否则并发写会把目标库的连接数打满。

非对象设置那一栏，主键、检查约束、唯一约束、外键、索引、触发器、自动转换对象名、注释，默认全选。迁移阶段建议先关掉外键和触发器，等数据全部落地再单独补，不然约束校验会把整个导入过程拖成线性。索引同理，几百万行数据带着索引写入，速度能差三到五倍。

表名列名大小写有个坑：默认是「不变」，但源端 Oracle 的元数据默认大写，目标端如果建库时用了小写规范，迁过来之后应用里的 SQL 全要大改。这种事没有对错，只有约定，动手前和应用方对一次，别迁完了才发现。

3.3 迁完必须做的 SDE 注册：脚本放哪、怎么跑

这是整份方案里最容易被跳过、也最容易导致「迁完了但用不了」的一步。KDTS 把表和数据搬过去了，几何字段也在，但 ArcGIS / GeoScene 认不出这是一份地理数据库，因为缺少 SDE 层面的注册信息。

文档给的做法是：迁移完成后，到迁移结果目录下找注册脚本。路径形态是result/2021-12-02_15-15-15/SDE/AcrpyRegisterScript/，里面的acrpyRegisterWithGeodatabase.py拷到 ArcGIS 所在机器上，放到 ArcGIS 自带的 Python 2.7 目录下（对应 10.8 版本是C:\Python27\ArcGIS10.8），然后执行。

执行前先确认要素类在目标库里可读，用一段简单的 arcpy 探一下：

# 在 ArcGIS 自带的 Python 2.7 环境里执行 # 用途：确认注册前要素类可枚举，避免脚本跑完才发现连不上 import arcpy sde_path = r"Database Connections\kbase_gis.sde" arcpy.env.workspace = sde_path # 列出该连接下所有要素类，正常应能看到刚迁过来的图层 feature_classes = arcpy.ListFeatureClasses() for fc in feature_classes: print(fc)

这段脚本跑不出东西，说明连接本身有问题，先回去查 3.1 里的端口和 URL 类型，别硬着头皮跑注册。能列出来，再执行注册脚本：

# 切到 ArcGIS 自带的 Python 目录，用脚本自带的参数方式执行 cd /d C:\Python27\ArcGIS10.8 python acrpyRegisterWithGeodatabase.py "Database Connections\kbase_gis.sde" "roads"

参数说明：第一个是 SDE 连接文件路径，第二个是待注册的要素类名。脚本内部做的是往地理数据库的系统表里写元数据，包括要素类的几何类型、空间参考、字段映射关系。注册失败最常见的原因是几何类型不在 SDE 支持列表里，比如自定义的复合几何，或者 SRID 未定义。这时候要么在源端把几何降级成标准类型，要么在注册前手工修正空间参考。

注册完成后别急着宣布完工，回到 ArcCatalog 里刷新一次，看要素类的「预览」页能不能正常渲染，属性表能不能打开。能渲染才是真的通了。

4. 平台直连与通用格式：小数据量迁移的三条快车道

KDTS 适合搬大库，但为了迁三个图层去配一套迁移任务，性价比太低。三条快车道分别对应 ArcGIS/GeoScene、SuperMap 和通用文件格式，共同点是操作在客户端完成，不用碰迁移工具。

4.1 ArcGIS/GeoScene：企业级地理数据库的创建与要素类落库

这条路的第一步是在客户端里建企业级地理数据库连接。在 ArcMap 的 ArcToolbox 里依次进入数据管理工具、地理数据库管理、创建企业级地理数据库，源库和目标库各建一次。源端 Oracle 要填实例信息，目标端 KingbaseES 要在 ArcCatalog 里通过「数据库连接」→「添加数据库连接」录入参数，前面说的端口写法在这里同样适用。

连接建好之后，两边都要做一次「启动地理数据库」。这一步需要 ArcGIS 授权文件，注意只认.ecp格式，别拿别的授权文件往里塞，会直接报错。启动成功之后，源库和目标库在目录树里都会显示成地理数据库节点的图标，而不是普通数据库连接。

接下来是导要素类。少量数据最快的做法是直接在 ArcCatalog 里复制粘贴，或者用转换工具批量跑：

# 用 arcpy 批量把要素类从源地理数据库导到目标库 # 适合图层数量在几十个以内的场景 import arcpy arcpy.env.overwriteOutput = True source_ws = r"Database Connections\ora_source.sde" target_ws = r"Database Connections\kbase_gis.sde" arcpy.env.workspace = source_ws for fc in arcpy.ListFeatureClasses(): out_fc = "{}\\{}".format(target_ws, fc) # FeatureClassToFeatureClass 会一并带上几何类型和空间参考 arcpy.FeatureClassToFeatureClass_conversion(fc, target_ws, fc) print("done: {}".format(fc))

逻辑说明：arcpy.env.workspace指向源库后，ListFeatureClasses()枚举的是要素数据集根目录下的所有要素类。如果源端有要素数据集（Feature Dataset）嵌套，需要先用ListDatasets()递归进去，否则会漏掉一整层。FeatureClassToFeatureClass_conversion的第二个参数是目标工作空间，第三个是输出名称，重名会报错，所以上面加了覆盖开关。

参数上最需要注意的是空间参考。默认会继承源要素类的坐标系，但如果目标库的 SRID 定义和源端不一致，写入时会做一次隐式转换，精度可能受影响。稳妥做法是在导出前显式指定arcpy.env.outputCoordinateSystem，让转换在可预期的地方发生。另外字符串字段的长度也会被截断，源端VARCHAR2(4000)到目标端如果按字节算长度，中文会少一半，这个要在建表阶段就对齐。

4.2 SuperMap：数据源挂接与数据集类型的对应关系

SuperMap 侧的思路是把 KingbaseES 当成一个数据源挂进来，然后在工作空间里做数据集拷贝。挂接时需要填数据库类型、服务器、端口、库名、用户名密码，以及一个容易填错的「数据源别名」，后续所有操作都靠这个别名引用。

数据集类型的映射关系是这条路的核心：

拷贝时最容易忽略的是网络数据集和拓扑。这类数据不是一张表能表达的，背后有一整套关系表，整体拷贝过去大概率是坏的。实践中的做法是只迁基础要素，网络和拓扑在目标端重新构建，成本比修复低得多。

栅格数据集要注意路径。SuperMap 里挂的影像如果还是源机器的绝对路径，迁到目标环境后一定读不到。要么把影像文件一并搬到目标机并保持相对目录结构，要么在挂接后批量更新路径字段。

4.3 shp / geojson 走 GDAL 入库的完整命令

零散数据、外部单位提供的数据、历史归档数据，基本都是 shp 或 geojson。这类数据用ogr2ogr最省事，一条命令搞定建表、导数据、建空间索引。

# 把 shp 导入 KingbaseES，自动建表并写入几何 ogr2ogr -f "PostgreSQL" \ "PG:host=192.168.4.30 port=5432 dbname=gisdb user=gis password=***" \ ./roads.shp \ -nln public.roads \ -nlt PROMOTE_TO_MULTI \ -lco GEOMETRY_NAME=geom \ -lco FID=id \ -lco SPATIAL_INDEX=GIST \ -t_srs EPSG:4326 \ --config PG_USE_COPY YES

逐项说明：-f "PostgreSQL"指定驱动，KingbaseES 兼容这条协议所以能直接复用；-nln指定目标表名，带上 schema 避免落到默认 schema；-nlt PROMOTE_TO_MULTI把单部件几何统一提升为多部件，避免同一批数据里几何类型混杂导致建表失败，这是 shp 导入最常见的报错来源；-lco GEOMETRY_NAME指定几何字段名，-lco FID指定主键字段名，两个都建议显式给，别用默认值；-lco SPATIAL_INDEX=GIST让工具顺手把空间索引建上；-t_srs做坐标转换，源数据没有.prj文件时不要加这个参数，否则会按错误的前提做转换。

--config PG_USE_COPY YES是性能开关，走 COPY 协议而不是逐条 INSERT，几十万要素的量级差别很明显。geojson 的处理一样，把文件名换掉即可，但如果 geojson 里混了多种几何类型，建议先按类型拆成多个文件，一次导一种，比事后修表省事。

导入完成后跑一句检查，确认几何确实写进去了：

-- 检查导入结果：行数、几何类型分布、SRID SELECT count(*) AS rows, ST_GeometryType(geom) AS gtype, ST_SRID(geom) AS srid FROM public.roads GROUP BY 2, 3;

返回的 SRID 是 0，说明源文件没带坐标系信息，需要手工补一次ST_SetSRID，不然后续所有空间查询都会算错距离。

5. 避坑排查：六条现场记录，从连不上到几何报错

这一章的东西，文档里的 FAQ 只是点到为止，实际现场遇到的问题往往更具体。下面六条按「现象 → 原因 → 解决」记，都是从失败里换来的。

5.1 连接、权限与工具版本相关

现象一：KDTS 连接测试一直失败，报错信息只说连接不上，没有细节。原因多半在端口写法。KingbaseES 实例端口不是 5432 时，地址栏必须写成IP,端口的逗号形式，写成冒号或者分两栏填都会解析失败。另一个可能是源端 Oracle 集群选了SID而不是ServiceName，连上了某个节点但该节点上没有目标数据。解决办法是把地址改成逗号分隔形式重试，集群源库一律切到ServiceName，改完先做连接测试再建任务，别跳过测试直接跑。

现象二：任务跑到一半失败，日志里只有一句权限拒绝。原因是账号权限只覆盖了部分对象。源端需要能读元数据视图和全表数据，目标端需要建表、建索引、建约束、写系统表的权限，缺一项就会在中途断掉。解决办法是迁移前用目标账号手工建一张带几何字段的测试表再删掉，把建表、建索引、写元数据这条链路走通；源端用同样的账号做一次全表count(*)抽样。这两步做完再跑正式任务，能挡掉大部分中途失败。

现象三：迁移速度极慢，一张几万行的表跑了两小时。原因通常是约束和索引没关。默认配置下主键、唯一约束、外键、索引、触发器全开，每写一批数据都要维护一遍索引，几百万行累积下来就是灾难。解决办法是在「非对象设置」里先取消索引、外键、触发器，等全量数据落地后再单独补建；同时把「每次批量提交大小」和「批量写入目标库记录数」按实际行宽调一调，宽表调小反而更快，因为单次事务太大容易触发检查点。

5.2 几何、坐标系与注册相关

现象四：数据迁完了，ArcCatalog 里能看到表，但打开要素类报「无法获取空间参考」。原因是 SDE 注册没做，或者做了但失败。KDTS 只搬表和几何字段，不写地理数据库的系统元数据。解决办法是回到迁移结果目录找AcrpyRegisterScript下的注册脚本，按 3.3 的步骤执行；执行前先用 arcpy 确认要素类可枚举。注册仍失败的话，检查几何类型是否在 SDE 支持范围内，自定义复合几何需要先降级成标准类型。

现象五：同一片区域，ST_Intersects查出来是空的，但数据肉眼可见都在。原因是 SRID 不一致。源端和目标的坐标系声明不同，一个按 4326 存，一个按投影坐标存，几何坐标值差着几个数量级，空间查询自然对不上。这个问题的隐蔽之处在于它不报错。解决办法是迁移后立刻按表统计 SRID 分布，出现 0 或者两种以上 SRID 就要处理；确认源端坐标系后统一ST_SetSRID或ST_Transform到目标 SRID，再重建空间索引。玄学问题基本都是坐标系惹的。

现象六：面数据迁过来之后，面积计算偏大或者出现自相交。原因是环方向和几何有效性。不同平台对面要素的外环顺时针/逆时针约定不一样，直接搬过来会出现「洞变成面」的情况；源数据本身的自相交在小数据量下看不出来，进了库一做叠加分析就炸。解决办法是导入后统一跑一次有效性检查，对无效几何做ST_MakeValid修复，必要时用ST_ForceRHR规范环方向。这一步建议做成固定动作，别等业务方报错了才回头查。

6. 迁完不算完：三层验证与一份几何自检 SQL

迁移任务状态显示「完成」，只代表数据搬过去了，不代表能用。验证要分三层做，每层解决不同的问题，跳过任何一层都可能在上线后返工。

第一层是行数和空几何。这层最基础，但对大表来说反而是唯一能快速跑完的检查。第二层是几何有效性，重点看有没有自相交、环方向错误、SRID 缺失。第三层是空间查询和索引，这层决定了业务能不能跑起来——很多迁移事故不是数据丢了，是索引没建，一个范围查询扫全表，页面直接卡死。

把三层串成一份可以直接改库名就跑的脚本：

-- 第一层：行数与空几何，两边对得上才算搬完 SELECT count(*) AS total, count(*) FILTER (WHERE geom IS NULL) AS geom_null FROM public.roads; -- 第二层：几何类型与 SRID 分布，出现 0 或多种 SRID 必须处理 SELECT ST_GeometryType(geom) AS gtype, ST_SRID(geom) AS srid, count(*) AS cnt FROM public.roads GROUP BY 1, 2 ORDER BY 3 DESC; -- 第二层补充：无效几何清单，先看数量再决定修不修 SELECT count(*) AS invalid_cnt FROM public.roads WHERE NOT ST_IsValid(geom); -- 第三层：空间索引是否生效，看执行计划里有没有走索引扫描 EXPLAIN (ANALYZE, BUFFERS) SELECT id FROM public.roads WHERE ST_Intersects(geom, ST_MakeEnvelope(113.0, 23.0, 113.5, 23.5, 4326));

参数上要注意ST_MakeEnvelope的最后一个参数是 SRID，必须和表里的 SRID 一致，不一致的话要么转换要么查不到。EXPLAIN的输出重点看两处：有没有走索引扫描，以及实际扫描行数和返回行数的比例，比例悬殊说明统计信息过期，跑一次ANALYZE再试。

我现在做任何一次空间库迁移，收尾都固定按这个顺序走一遍：先跑行数比对，再跑 SRID 分布，最后跑一条带EXPLAIN的空间查询，三个结果都正常才敢交付。有一次图省事跳过了 SRID 检查，上线第二天业务方反馈地图上要素偏移了几百公里，回头查是源端有一批数据没带坐标系，补了半天的ST_SetSRID。从那以后这条检查就没再从流程里拿掉过。希望帮到你。

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