【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;

改写后：