KingbaseES V8.6 GIS空间数据迁移路径与避坑实践

简介：《人大金仓-KingbaseES GIS数据迁移方案》V8.6面向数据库管理员、GIS开发人员及迁移实施团队，聚焦地理空间数据从ArcGIS、GeoScene、SuperMap等平台向KingbaseES迁移的实际需求，提供分平台的方法论与操作参考。压缩包内含1个PDF文件，约2.76MB，以单文档形式组织完整内容，适合离线查阅和项目归档。文档从KingbaseES的GIS能力及其与空间数据的关系讲起，随后按ArcGIS/GeoScene、SuperMap和第三方通用格式三条路径展开：既覆盖KDTS工具的数据抽取、转换、加载流程，也说明借助GIS软件自身导出导入功能的做法，并在各章给出迁移结果验证与FAQ。读者可据此掌握源库与目标库连接配置、迁移表字段选择、数据完整性与准确性核对等关键环节，减少跨平台迁移中的试错成本。目前已有137人学习。

1. 从空间库搬到 KingbaseES V8.6：为什么普通表的迁移套路在这里会失灵

一次常规业务库迁移，导出、建库、导入、核对行数，半天收工。但把同样一套流程套到 GIS 数据上，十有八九会在第三天卡住：表建好了，数据也进去了，ST_Area算出来的面积却是 0.003，或者外包框直接跑到南极洲。问题不在数据本身，而在几何列带了三样普通列没有的东西——类型修饰、坐标系标识和空间索引。KingbaseES V8.6 的内核与 PostgreSQL 高度兼容，这既是好消息也是陷阱：语法看着眼熟，于是很多人默认"直接 dump 过去就行"，结果在扩展安装、SRID 校验、WKB 精度上接连翻车。

这篇讲的是一套可复现的 KingbaseES GIS 数据迁移路径：从源端家底盘点开始，到路径选型、几何落地、索引重建，再到验收口径和五类典型故障的排查手法。适合手里有几十 GB 到几 TB 空间数据、准备做国产化替换的开发者，也适合已经迁完一轮但对不上数、想回头找原因的人。

2. 迁移前的家底盘点：几何类型、SRID 和扩展能力怎么摸清

动手导出之前，先把源端和目标端各拍一张"X 光片"。空间数据迁移里最贵的成本不是传输时间，而是迁完才发现坐标系标错、维度丢失、无效几何被静默丢弃。这三类问题都不会报错，只会在业务侧以"地图上位置偏了三百米"的形式冒出来，排查成本极高。

2.1 用四条 SQL 摸清源库的空间家底

先连上源库，把空间列的清单拉出来。下面这段在常见的 PostGIS 兼容库上都能跑，输出的结果可以直接当迁移清单用。

-- 1) 全库空间列清单：库名、表名、几何列名、声明类型、SRID、维度 SELECT f_table_schema, f_table_name, f_geometry_column, type, srid, coord_dimension FROM geometry_columns ORDER BY f_table_schema, f_table_name; -- 2) 声明为 Geometry 但实际混装多种类型的情况（最容易在目标端建表时翻车） SELECT ST_GeometryType(geom) AS gtype, count(*) AS cnt FROM gis.parcel GROUP BY 1 ORDER BY 2 DESC; -- 3) SRID 缺失或为 0 的记录，这些是后续坐标轴错乱的源头 SELECT count(*) AS srid_zero_cnt FROM gis.parcel WHERE ST_SRID(geom) = 0 OR geom IS NULL; -- 4) 无效几何：自相交、环未闭合、坐标重复点 SELECT count(*) AS invalid_cnt FROM gis.parcel WHERE NOT ST_IsValid(geom);

第一条查的是元数据视图geometry_columns，字段含义分别是：f_geometry_column是几何列名，type是建表时声明的类型（可能是笼统的GEOMETRY），srid是坐标系编码，coord_dimension是维度（2 表示 XY，3 表示 XYZ 或 XYM）。第二条用ST_GeometryType看实际存储的类型分布，如果一张声明为GEOMETRY的表里同时有ST_Point和ST_Polygon，目标端就不能建成带类型修饰的列，否则导入会整批失败。第三、四条是为后面的数据清洗做准备，ST_SRID(geom) = 0的记录必须业务方逐条确认坐标参考，机器猜不出来。

把结果导出成 CSV 存档，这份清单在后面做验收比对时还要用一次。

2.2 几何类型与 SRID 的映射表怎么定

盘点完之后，逐列决定目标端的写法。这一步定错了，后面所有 SQL 都是白干。下表是我一般会拿给业务方确认的对照口径。

SRID 的选择上，国内业务常见的是 CGCS2000 系列（地理坐标 EPSG:4490，投影坐标按高斯-克吕格分带）。如果源端用的是 WGS84（4326），而业务要求出图对齐国内底图，就需要在迁移阶段一次性做ST_Transform，而不是留到查询时每条 SQL 里转——后者会让空间索引彻底失效。

提示：SRID 映射表一定要落到文档里并让业务方签字确认，口头说"应该都是 4490"是迁移事故的高发起点。

2.3 目标端空间扩展的确认与初始化

KingbaseES 的空间能力通过扩展提供，装没装、叫什么名字，不同交付介质和版本会有差异，别凭记忆写。先连上去看一眼。

# 连接目标库，端口以实际部署为准，KingbaseES 常见默认端口是 54321 ksql -h 10.0.0.11 -p 54321 -U system -d gisdb

-- 已安装扩展 \dx -- 可用扩展清单（视图名在不同版本可能是 sys_available_extensions 或 pg_available_extensions） SELECT name, default_version, installed_version FROM sys_available_extensions WHERE name ILIKE '%gis%' OR name ILIKE '%spatial%'; -- 安装空间扩展，扩展名以上一步查询结果为准 CREATE EXTENSION postgis; -- 验证：能返回版本号就说明函数库已就位 SELECT postgis_version(), postgis_full_version();

\dx是元命令，列出当前库已安装的扩展；第二条查的是可用扩展清单，installed_version为空表示"有安装包但没启用"。CREATE EXTENSION如果报could not open extension control file，说明空间组件压根没随安装介质部署，这时候不是改 SQL 能解决的，得回到安装环节补装 GIS 组件。

扩展装完立刻做一次冒烟验证，别等到导入几千万行才发现函数缺失：

SELECT ST_AsText(ST_GeomFromText('POINT(116.39 39.9)', 4490)) AS pt, ST_SRID(ST_GeomFromText('POINT(116.39 39.9)', 4490)) AS srid, round(ST_Distance(ST_GeomFromText('POINT(116.39 39.9)', 4490), ST_GeomFromText('POINT(116.40 39.9)', 4490))::numeric, 6) AS deg_dist;

这段同时验证了三件事：WKT 解析可用、SRID 能正确写入、距离函数能跑通。注意最后算出来的deg_dist单位是度不是米，这是 4490 地理坐标系的固有特性，后面算面积时会再遇到。

3. 三条迁移路径怎么选：逻辑导出、文件中转与分批搬运

家底摸清之后才谈路径。空间数据的迁移路径比普通表少很多，因为几何列是二进制大对象，很多"看起来能走"的通道实际上会把几何打散成文本再拼回来，精度和 SRID 全丢。我一般只在三条路里选，按数据量分界：几十 GB 以内走逻辑导出，异构源或文件源走 GDAL 中转，TB 级超大表单表走分批搬运。

3.1 整库逻辑导出：sys_dump 与 sys_restore 的可用边界

先说清楚一条红线：数据库的物理备份文件不能跨内核版本直接拿来用。空间库迁移必须走逻辑导出，也就是把数据导成 SQL 文本或自定义格式，再在目标端重放。

# 源端导出：自定义格式 + 压缩，排除 spatial_ref_sys 避免与目标端冲突 sys_dump -h 10.0.0.20 -p 5432 -U gis_user -d gisdb \ -Fc -Z 6 \ --no-owner --no-privileges \ -T spatial_ref_sys \ -f /data/migrate/gisdb.dump

参数逐个说：-Fc指定自定义格式（custom），这是唯一支持并行恢复和选择性恢复的格式，纯文本的-Fp在大库上会非常慢；-Z 6是压缩级别，0 到 9，空间数据本身压缩率一般，6 是比较平衡的值，再往上 CPU 开销不划算；--no-owner --no-privileges去掉属主和权限语句，否则目标端没有同名角色会一路报错；-T spatial_ref_sys排除坐标系字典表，因为目标端扩展安装时已经写入了一份，覆盖会导致主键冲突。

恢复到目标端：

# 先只恢复表结构，验证建表语句能否通过 sys_restore -h 10.0.0.11 -p 54321 -U system -d gisdb \ --no-owner --no-privileges \ --schema-only \ /data/migrate/gisdb.dump # 结构无误后再并行恢复数据 sys_restore -h 10.0.0.11 -p 54321 -U system -d gisdb \ --no-owner --no-privileges \ -j 4 \ /data/migrate/gisdb.dump

--schema-only只导结构，这一步是"后悔药"：结构有问题就地改，不用等数据全灌进去再回滚。-j 4是并行度，只对自定义格式生效，一般设成 CPU 核数的一半到相等，设太高反而因为锁竞争变慢。

注意：工具名在不同交付版本里可能是sys_dump/sys_restore，也可能保留pg_dump/pg_restore兼容入口，用--help确认后再写进脚本，别把命令硬编码到一个不存在的二进制上。

如果sys_restore直接报解析错误，说明跨内核的归档格式不兼容。这时候退回纯 SQL 文本路线：sys_dump -Fp导出后用ksql -f重放，速度慢但兼容性好。我曾经在一个跨大版本的项目上，就是靠这条"慢路子"把 40 GB 数据搬完的，血泪经验是：先用一张一万行的小表试通整条链路，再动全量。

3.2 文件中转：Shapefile 和 GeoJSON 走 ogr2ogr

源端不是数据库而是 Shapefile、GeoJSON、FileGDB 时，GDAL 的ogr2ogr是最省事的通道。它直接写目标库，几何以 WKB 写入，不会经过文本拼装。

ogr2ogr -f PostgreSQL \ "PG:host=10.0.0.11 port=54321 dbname=gisdb user=system password=******" \ /data/shp/road.shp \ -nln gis.road \ -nlt PROMOTE_TO_MULTI \ -lco GEOMETRY_NAME=geom \ -lco FID=gid \ -lco SPATIAL_INDEX=GIST \ -lco ENCODING=UTF-8 \ -t_srs EPSG:4490 \ -progress

-f PostgreSQL是输出驱动，KingbaseES 协议层兼容，多数场景可以直接用；-nln指定目标表的 schema.table 全名；-nlt PROMOTE_TO_MULTI把单几何提升为多几何，这是 Shapefile 迁移的必备参数——Shapefile 一个图层里可能混着 Polygon 和 MultiPolygon，不升维的话建表类型会打架；-lco GEOMETRY_NAME=geom指定几何列名；-lco FID=gid指定主键列名；-lco SPATIAL_INDEX=GIST让驱动建表时顺手建 GiST 索引（小数据量方便，大数据量建议改成NONE，导完再手工建）；-lco ENCODING=UTF-8处理属性表编码；-t_srs做坐标转换。

属性乱码是这条路线的经典翻车点。老的 Shapefile 的 DBF 部分常用 GBK 编码，ENCODING=UTF-8只声明"目标端用什么编码"，源端编码要用-oo ENCODING=GBK指定。两个参数搞混，导入的中文地名就是一串问号。

3.3 大表分批搬运：按主键区间切片的脚本写法

单表过亿行时，一次性导出会遇到两个问题：事务日志暴涨、失败重来成本极高。分批搬运的核心是让每一批都是独立事务，断了从断点续。

# batch_move.py：按主键区间分批搬运，每批独立提交，支持断点续传 import psycopg2 SRC = "host=10.0.0.20 port=5432 dbname=gisdb user=gis_user password=******" DST = "host=10.0.0.11 port=54321 dbname=gisdb user=system password=******" BATCH = 50000 # 每批行数，按单行几何大小调整，几何越大批次越小 def move_table(table: str, geom_col: str, srid: int): src = psycopg2.connect(SRC) dst = psycopg2.connect(DST) cur_s = src.cursor(name="stream") # 命名游标，服务端流式读取，避免一次性拉满内存 cur_s.itersize = BATCH cur_s.execute(f"SELECT gid, name, ST_AsBinary({geom_col}) FROM {table} ORDER BY gid") cur_d = dst.cursor() n = 0 while True: rows = cur_s.fetchmany(BATCH) if not rows: break # 目标端用 ST_GeomFromWKB 还原，SRID 显式传入，不依赖源端元数据 cur_d.executemany( "INSERT INTO gis.%s (gid, name, geom) " "VALUES (%%s, %%s, ST_GeomFromWKB(%%s, %d)) " "ON CONFLICT (gid) DO NOTHING" % (table, srid), rows, ) dst.commit() # 每批独立提交，失败只回滚当前批 n += len(rows) print(f"{table}: {n} rows committed") src.close(); dst.close() if __name__ == "__main__": move_table("road", "geom", 4490)

关键点在三个地方。cursor(name="stream")建的是服务端游标，itersize控制每次网络往返拉多少行，这是避免客户端内存被打爆的关键；ST_AsBinary把几何序列化成 WKB，二进制通道不会丢精度，也不会被字符集干扰；ST_GeomFromWKB(%, srid)显式传 SRID，不依赖源端geometry_columns的元数据，因为源端标错 SRID 的情况太常见了。ON CONFLICT (gid) DO NOTHING让脚本可以重复执行，中断后从断点继续而不用清表重来。

提示：驱动层能连通不代表函数全兼容。跑全量之前，先用SELECT postgis_version()在目标端确认函数库，再拿 1000 行做一次端到端验证。

4. 几何字段落地：建表、批量写入与 GiST 索引的三个必调参数

数据能过去了，接下来决定它"存得好不好"。同一批几何，建表方式不同，查询性能能差出一个数量级；写入方式不同，导入耗时能差三倍。这一章的三节分别对应建表、写入、索引，每一节都有一个必须调的参数。

4.1 建表时几何列的 typmod 到底该不该加

CREATE SCHEMA IF NOT EXISTS gis; CREATE TABLE gis.road ( gid bigint GENERATED BY DEFAULT AS IDENTITY PRIMARY KEY, name varchar(128), grade smallint, geom geometry(MultiLineString, 4490) ); COMMENT ON COLUMN gis.road.geom IS 'CGCS2000 地理坐标，MultiLineString，单位：度';

geometry(MultiLineString, 4490)里的括号部分是类型修饰符（typmod），它带来两个强制约束：插入的几何类型必须是 MultiLineString，SRID 必须是 4490。好处是脏数据在写入时就被拦下来，坏处是导入性能有损耗——每条 INSERT 都要做一次类型和 SRID 校验，而且源端一旦有单几何混进来就整批失败。

我的做法是分阶段：导入阶段建不带修饰的geometry列，让数据先进来；导完做一次全量校验，把不合规的记录挑出来清洗；最后用ALTER TABLE ... ALTER COLUMN geom TYPE geometry(MultiLineString, 4490) USING ST_Multi(geom)补上约束。这样导入快，约束也不缺。

如果坚持一开始就带修饰，务必把源端的ST_Multi提升提前做掉：

-- 不带修饰的过渡表，先接住所有几何 CREATE TABLE gis.road_stage ( gid bigint, name varchar(128), grade smallint, geom geometry );

不带修饰的列不校验类型和 SRID，等于把校验责任交给了后续步骤，所以过渡表千万不要直接对外提供查询。

4.2 批量写入：COPY 加 WKB 十六进制是吞吐最高的组合

单条 INSERT 写空间数据是最慢的方式，因为每条都要走一次解析、一次索引维护。生产上我一般用COPY把数据先落到文本暂存表，再用一条INSERT ... SELECT做几何还原，一次成型。

-- 暂存表：几何先以 WKB 的十六进制文本形式落地 CREATE TEMP TABLE road_raw ( gid bigint, name varchar(128), grade smallint, geom_hex text ); -- 从 CSV 高速灌入，全程不碰几何函数，速度最快 \copy road_raw FROM '/data/migrate/road.csv' WITH (FORMAT csv, HEADER true, ENCODING 'UTF8') -- 一次性还原几何并写入正式表 INSERT INTO gis.road (gid, name, grade, geom) SELECT gid, name, grade, ST_Multi(ST_GeomFromWKB(decode(geom_hex, 'hex'), 4490)) FROM road_raw WHERE geom_hex IS NOT NULL AND geom_hex <> ''; ANALYZE gis.road;

decode(geom_hex, 'hex')把十六进制字符串还原成 bytea，ST_GeomFromWKB再把它解析成几何对象，第二个参数 4490 是 SRID。外面套一层ST_Multi是为了应对源端混着单几何的情况。WHERE geom_hex IS NOT NULL过滤空值，避免ST_GeomFromWKB拿到 NULL 后几何列变成空但行还在，这类"半条记录"最难查。

批量大小上，\copy单文件建议控制在 1 到 2 GB，再大就切成多个文件顺序灌。中间不要commit太频繁，一个文件一个事务，事务日志压力可控。

4.3 GiST 索引：建的时间点和两个参数决定成败

空间查询不走 GiST 索引，等于全表扫描。但索引建得太早，导入过程中每插一行都要维护一次索引树，导入时间可能翻两三倍。正确顺序是：清空表 → 灌数据 → 建索引 →ANALYZE。

-- 大批量导入期间临时放大维护内存，减少外部排序 SET maintenance_work_mem = '2GB'; SET max_parallel_maintenance_workers = 4; -- 建 GiST 索引，几何列直接建，不要包函数 CREATE INDEX idx_road_geom ON gis.road USING gist (geom); -- 常用"按投影坐标范围查"的场景，可以补一个表达式索引（代价是写入变慢） CREATE INDEX idx_road_geom_3857 ON gis.road USING gist (ST_Transform(geom, 3857)); -- 建完必须收集统计信息，否则优化器可能仍然选全表扫描 ANALYZE gis.road;

maintenance_work_mem是维护类操作（建索引、VACUUM）可用的内存，索引构建阶段调大到 1 到 2 GB 能显著减少磁盘临时文件；max_parallel_maintenance_workers控制并行建索引的进程数，表越大收益越明显，小表反而因为进程启动开销变慢。

表达式索引要谨慎。上面那个ST_Transform(geom, 3857)的索引，只有查询条件写成完全相同的表达式时才会命中，写成ST_Transform(geom, 3856)或者换个 SRID 就完全用不上。而且它会让每次写入都多算一次坐标转换，写入性能下降明显。我的习惯是：先用单列 GiST 索引扛住大部分场景，确有高频固定投影查询再补表达式索引，并且用EXPLAIN (ANALYZE, BUFFERS)确认真的命中了再保留。

5. 迁移避坑清单：五类翻车现场的现象、原因与解法

下面这五条都是我在真实迁移里遇到过、并且不止遇到一次的。每条按现象、原因、解决三步写，对着排查能省掉大量猜测时间。

5.1 面积算出来是 0.0003，或者大得离谱

现象：数据全部导入成功，ST_Area(geom)返回 0.0003 这种量级的数字，业务方说"我们这块地是 3000 平方米"。

原因：几何存的是地理坐标（单位是度），直接在度上算面积，得到的单位是"平方度"，没有任何业务意义。另一种反向情况是 SRID 标成了投影坐标系（单位米），但实际存的是经纬度，算出来的面积会大出十几个数量级。

解决：先确认ST_SRID(geom)的真实值，再决定算法。地理坐标下算面积要么转到等积投影，要么转 geography 类型再算：

-- 地理坐标下算平方米，先转 geography 再取面积 SELECT gid, round(ST_Area(geom::geography)::numeric, 2) AS area_m2 FROM gis.parcel LIMIT 10;

同时把 SRID 一致性做成约束，从根上堵住：

ALTER TABLE gis.parcel ADD CONSTRAINT parcel_srid_chk CHECK (ST_SRID(geom) = 4490);

5.2 恢复时报 type "geometry" does not exist

现象：sys_restore跑到建表语句就中断，报类型不存在，但明明已经装过空间扩展。

原因：两个可能。一是扩展装在了另一个库或者另一个 schema，当前search_path找不到；二是恢复时的连接用户不是扩展的属主，权限不足看不到类型。

解决：先在目标库确认扩展的实际安装位置，再显式设置搜索路径。

-- 确认扩展装在哪个 schema SELECT e.extname, n.nspname FROM sys_extension e JOIN sys_namespace n ON e.extnamespace = n.oid WHERE e.extname ILIKE '%gis%' OR e.extname ILIKE '%spatial%'; -- 恢复会话里显式指定搜索路径 SET search_path TO gis, public, "$user";

如果扩展压根没装，回到 2.3 节补装，别在恢复脚本里加CREATE EXTENSION硬扛——权限和依赖顺序都会出问题。

5.3 属性表中文全变成问号，几何却完好

现象：地图能正常渲染，但道路名称、行政区名全是???。

原因：源端 Shapefile 的 DBF 部分用 GBK 编码，ogr2ogr的-lco ENCODING=UTF-8只声明了目标端编码，没有告诉驱动源端是什么编码。

解决：源端编码用-oo（open option）指定，和目标端编码分开写：

ogr2ogr -f PostgreSQL "PG:host=10.0.0.11 port=54321 dbname=gisdb user=system password=******" \ /data/shp/road.shp -nln gis.road \ -oo ENCODING=GBK \ -lco ENCODING=UTF-8 \ -nlt PROMOTE_TO_MULTI

-oo是输入侧选项，-lco是输出侧选项，两者作用对象不同。遇到乱码先看源文件的实际编码，别盲目试 UTF-8。

5.4 导入越跑越慢，最后几乎停滞

现象：前 100 万行每秒几万条，到 500 万行掉到每秒几百条，磁盘 IO 打满。

原因：三个叠加因素。边插边维护 GiST 索引，索引树越深插入越慢；单个事务太大，回滚段和 WAL 持续膨胀；批量插入触发 autovacuum，和导入抢 IO。

解决：导入前把索引和非主键约束全部删掉，导入期间关掉该表的 autovacuum，导完再重建。

-- 导入前 ALTER TABLE gis.road SET (autovacuum_enabled = false); DROP INDEX IF EXISTS idx_road_geom; -- 导入完成后 ALTER TABLE gis.road SET (autovacuum_enabled = true); CREATE INDEX idx_road_geom ON gis.road USING gist (geom); ANALYZE gis.road;

另外把单批事务控制在 5 万到 20 万行之间，别一个事务干到底。

5.5 建了索引却始终不走，查询还是全表扫

现象：GiST 索引明明建了，EXPLAIN出来还是 Seq Scan，几十秒才出结果。

原因：查询条件把几何列包在函数里了，比如WHERE ST_Transform(geom, 3857) && ST_MakeEnvelope(...)，索引是建在geom上的，包了函数就用不上（除非正好建了同表达式的索引）。另一个常见原因是统计信息过期，优化器低估了选择率。

解决：把函数挪到常量侧，让几何列裸露在条件左边：

-- 错误写法：几何列被函数包裹，索引失效 SELECT * FROM gis.road WHERE ST_Transform(geom, 3857) && ST_MakeEnvelope(12900000, 4800000, 12950000, 4850000, 3857); -- 正确写法：先把查询范围转回存储坐标系，几何列保持裸露 SELECT * FROM gis.road WHERE geom && ST_Transform(ST_MakeEnvelope(12900000, 4800000, 12950000, 4850000, 3857), 4490);

改完之后再ANALYZE一次，用EXPLAIN (ANALYZE, BUFFERS)确认出现Bitmap Index Scan on idx_road_geom才算真正修好。

6. 验收与灰度切换：用一组 SQL 证明迁移真的没丢东西

迁移做完，最怕的不是报错，而是"看起来没问题"。行数对上了不代表几何对上了，几何对上了不代表坐标系对上了。我一般用下面这组口径做验收，每一项都有明确的通过标准，不靠感觉。

外包框那一条特别值得做，它能一次性抓出坐标轴翻转的问题。如果源端外包框的经度范围是 73 到 135，目标端变成 -90 到 90 之类的数字，就是坐标轴顺序反了，用ST_FlipCoordinates批量纠正后再比对。同样的手法可以用来抓"整批数据偏移"，只要对比几个采样点的坐标就能看出来。

面积总量比对要注意口径统一：两边都在 geography 下算，或者两边都转到同一个等积投影下算，不要一边算平方度一边算平方米。

灰度切换上，我的习惯是先切读不切写。用一套只读账号把报表类和地图服务的查询指到新库，跑一周，对比同一批请求的返回结果和响应时间。这期间源库继续接收写入，靠增量脚本把变更同步过去——增量同步按updated_at时间戳拉，几何列同样走 WKB 通道。等读侧稳定、验收项全绿，再做一次短窗口的停写切换，把写入口指过去。

最后说个我自己的教训：第一次做这类迁移时，我图省事跳过了"抽样点位比对"，只看了行数和外包框。结果上线一周后业务反馈某个区的边界线整体偏了大概两百米，回头查是那一批数据的 SRID 被标成了相邻带的投影坐标。从那以后我的验收脚本里固定加一条：随机抽 20 个要素，把ST_AsText(ST_Centroid(geom))的坐标打到日志里，和源端逐条对照。这条检查只花两分钟，但能拦住九成的坐标系事故。希望帮到你。

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