【YashanDB知识库】为什么YashanDB只有Geometry类型,没有Geogrephy类型
本文内容来自YashanDB官网,原文内容请见 https://www.yashandb.com/newsinfo/7106889.html?templateId=1718516
背景:
● Geometry:投影坐标系,平面坐标系,笛卡尔坐标系,Srid默认2369,基于平面直角坐标系,在该坐标系内计算出的最短路径是一条直线,计算简单,执行起来更快,但是相对于地球球体表面的数据不准确。
● Geogrephy:地理坐标系,大地坐标系,经纬坐标系,球面坐标系,Srid默认4326(服务端存储一般用4326),基于球面坐标系,在该坐标系内计算出的最短路径是一段圆弧,该数据类型的计算考虑了地球是一个球型,计算复杂,执行时间相对慢,但是计算结果相对精确。
● Srid:全称Spatial Reference System Identifier,定义了地球海平面,球心位置,球心偏移,地球形状等信息,不指定SRID默认为0。
● PostGis的地理数据类型:Geometry和Geogrephy
● YashanDB的地理数据类型:Geometry,但是兼顾PostGis两种坐标系,通过指定Srid来实现两种数据类型的转换
yasdb兼容示例:
在yasdb中没有函数st_geogfromtext,postGis存在st_geogfromtext函数,yasdb可通过st_geomfromtext函数指定SRID的方式兼容
● PostGis:st_geogfromtext('POLYGON ((114.01758862581613 22.626209213735862, 114.01758862581613 22.622079565683535, 114.02268482294346 22.622079565683535, 114.02268482294346 22.626209213735862, 114.01758862581613 22.626209213735862))')
● YashanDB:st_geomfromtext('POLYGON ((114.01758862581613 22.626209213735862, 114.01758862581613 22.622079565683535, 114.02268482294346 22.622079565683535, 114.02268482294346 22.626209213735862, 114.01758862581613 22.626209213735862))',4326)
PostGis的ST_Distance(geometry A, geometry B)和ST_DistanceSphere(geometry A, geometry B)
● PostGis的ST_Distance函数返回的是笛卡尔坐标系的直线距离,ST_DistanceSphere返回的是球面坐标系的圆弧距离
● YashanDB目前支持ST_Distance函数,暂不支持ST_DistanceSphere函数,但是YashanDB的ST_Distance函数可以根据SRID自动识别需要计算的是笛卡尔坐标系下的距离,还是基于地理坐标系的圆弧距离,在YashanDB下计算圆弧距离用的是椭球坐标系而不是球面坐标系,在相对带来一些性能损失的情况下,比postGis的球面坐标系的计算方式更精确。
在使用st_distance函数计算两个地理位置距离的操作中,同一条sql语句在pgsql和yasdb****上计算的结果不一致:
YashanDB:
PostGis:
主要原因:
pgsql不根据SRID来区分经纬度还是投影坐标,需要用对应的函数显式声明,GeomFromText生成的就是geometry,GeogFromText生成的就是geography,否则pgsql会按照投影坐标系来计算两地之间的直线距离,而不是弧度距离,而yasdb是根据SRID来区分是geometry还是geography的。
改写方式:
pgsql需要显式使用geogfromtext函数来申明是一个球面坐标参数。
select st_distance(st_geogfromtext('POLYGON ((113.92505953616575 22.574317714342442, 113.89123260989561 22.574317714342442, 113.89123260989561 22.55111425204862, 113.92505953616575 22.55111425204862, 113.92505953616575 22.574317714342442))'), st_geogfromtext('POLYGON ((113.87828681559085 22.55245916933376, 113.87828681559085 22.54723397504624, 113.88905632391055 22.54723397504624, 113.88905632391055 22.55245916933376, 113.87828681559085 22.55245916933376))')) as dual;
改写后:
【推荐】编程新体验,更懂你的AI,立即体验豆包MarsCode编程助手
【推荐】凌霞软件回馈社区,博客园 & 1Panel & Halo 联合会员上线
【推荐】抖音旗下AI助手豆包,你的智能百科全书,全免费不限次数
【推荐】博客园社区专享云产品让利特惠,阿里云新客6.5折上折
【推荐】轻量又高性能的 SSH 工具 IShell:AI 加持,快人一步
· 一个费力不讨好的项目,让我损失了近一半的绩效!
· .NET Core 托管堆内存泄露/CPU异常的常见思路
· PostgreSQL 和 SQL Server 在统计信息维护中的关键差异
· C++代码改造为UTF-8编码问题的总结
· DeepSeek 解答了困扰我五年的技术问题
· 一个费力不讨好的项目,让我损失了近一半的绩效!
· 清华大学推出第四讲使用 DeepSeek + DeepResearch 让科研像聊天一样简单!
· 实操Deepseek接入个人知识库
· 易语言 —— 开山篇
· CSnakes vs Python.NET:高效嵌入与灵活互通的跨语言方案对比