Question

更新：已向Microsoft报告。

在一个简单的（SQL Server 2012）表中，geography列（名称geopoint）填充了几个类似于此的简单行点。 POINT (-0.120875610750927 54.1165118880234)等执行

select [geopoint].[STAsText](),
       [geopoint].Lat lat,
       [geopoint].Long long 
from mytable

产生这个

Untitled1   lat long
POINT (-0.120875610750927 54.1165118880234) 54.1165118880234    -0.120875610750927

看起来像一个bug，但它太基本了，应该在发布之前被捕获。我做错了什么？

添加了信息

IT专业人员应该在MSDN上查找Microsoft在SQL服务器上的实现细节。由于实施方面可能存在差异。按照这种情况。作为对此的证明，我刚刚检查了PostGist对ST_AsText列geographic的实施情况。这很好用！结果是人们所期望的。因此，错误在于SQL的实现。以上示例的正确结果应为

POINT (54.1165118880234 -0.120875610750927 ) 54.1165118880234 -0.120875610750927

我敢说有很多可能与工作geographic列的函数有关的其他错误。由于该领域的基本功能尚未经过全面测试。

Answer 1

这是按预期工作的。

根据您的问题，您将数据存储在此模式中：

POINT (-0.120875610750927 54.1165118880234)

然后你声称纬度/经度根据<{p>}的MSDN documentation反转

Point(Lat, Long, SRID)。

您可能会发现您使用的语法与您声明的语法不同：

POINT(aValue anotherValue) vs Point(Lat, Long, SRID)

现在，问题是，MS SQL对数据做了什么？

事实证明，MS SQL将数据解释为开放地理空间联盟（OGC）知名文本（WKT），因此使用STPointFromText函数，因为格式最适合2-D点：

POINT(x y)

现在，后续问题，是否意味着POINT(Lat Long)？

来自示例代码

SET @g = geography::STPointFromText('POINT(-122.34900 47.65100)', 4326);

应该清楚的是，第一个参数不是纬度，而是经度（纬度范围的范围仅为-90到90），所以现在我们猜测格式为POINT(Long Lat)。但为什么呢？

如this article中所述，

如您所见[...]，经度首先在纬度之前指定。原因是因为在Open Geospatial Consortium（OGC）着名文本（WKT）表示中，格式为（x，y）。地理坐标通常由Lat / Long指定，但在这两者之间，X是经度，而Y是纬度。

您可能想知道为什么X坐标是经度而Y坐标是纬度。将地球的赤道视为x轴，而本初子午线是Y轴。经度定义为本初子午线沿x轴（或赤道）的距离。同样，纬度定义为赤道沿Y轴的距离。

Answer 2

这是一个错误。地理列的STAsText的返回值交换Lat和Long值。绝对是人们应该注意的错误。

SQL Geography POINT Lat，Long中的一个错误

2 个答案: