



























在GIS业务开发中,经常遇到一个核心需求:拿到SHP原始矢量,精准对应数据库中Geom原始存储值。
很多人分不清:WKT、WKB、EWKB,经常出现导出坐标精度丢失、二进制串对不上等问题。
本文结合真实实操踩坑,一次性讲透:
为什么SHP肉眼坐标一样,二进制Geom却不一样?
PostGIS真实存储格式是什么?
如何高精度正向生成数据库原生EWKB串?
如何从十六进制Geom逆推原始高精度坐标?
精准实现Hex与高精度坐标互相转换
示例:POINT \(107\.503611000347 35\.6885570000056\)
特点:可读、简单、不带坐标系。
示例:0101000000fab9a1293be05a404837c2a222d84140
特点:纯几何,不带SRID坐标系,PostGIS不原生存储这种。
示例:0101000020E6100000FCB9A1293BE05A405037C2A222D84140
多出一段:20E6100000 = SRID=4326
结论:PostGIS库里Geom字段存的全部是EWKB,不是WKB。
看上去几乎一样的坐标:
原始高精度:POINT \(107\.503611000347 35\.6885570000056\)
四舍五入后:POINT \(107\.503611 35\.688557\)
二进制EWKB完全不一样,绝对不能混用。
原因:浮点二进制存储极其敏感,哪怕末尾0.0000000001差异,Hex串完全改变。
QGIS导出CSV时,自动压缩小数位,永远得不到SHP原生高精度坐标,所以转出来Hex永远和数据库对不上。
-- WKT 转 PostGIS 原生存储 EWKB 十六进制
SELECT encode(
ST_AsEWKB(
ST_SetSRID(ST_GeomFromText('POINT (107.503611000347 35.6885570000056)'),4326)
),'hex'
) AS geom_hex;
解决endian报错、唯一正确写法
-- EWKB十六进制 逆推 原始高精度坐标
SELECT ST_AsText(
ST_GeomFromEWKB(
decode('0101000020E6100000A428756E7F145840C0D39D279E454440', 'hex')
)
) AS wkt_point;
SELECT
id,
ST_AsText(ST_GeomFromEWKB(decode(geom, 'hex'))) AS wkt_point
FROM 你的表名;
最稳定、零误差方案:超图iDesktop
SHP导入UDB文件数据源(不要直接进数据库)
打开属性表
查看Shape 字段
该字段值 = 数据库真实存储EWKB
✅ 无需转换、无精度丢失、完全一致。
数据库存的是EWKB,带4326坐标系头;
坐标小数少一位,Hex完全不一样;
QGIS导出WKT会丢精度,不可用于比对;
逆推Hex必须加 decode(xxx,'hex'),否则endian报错;
想要原始Geom,优先超图Shape字段,不要手动算。
此内容由惯性聚合(RSS阅读器)自动聚合整理,仅供阅读参考。 原文来自 — 版权归原作者所有。