0

在 SQL Server 2008 中转换为空间类型的知名文本 (WKT) 时，我在机器之间遇到了不一致的行为。看起来数据的存储方式相同，但转换回 WKT 的行为因机器而异！

这是我整理的一些内容以查明问题：

SET NOCOUNT ON;

DECLARE @TestTable TABLE (TestPoint GEOGRAPHY);
INSERT INTO @TestTable(TestPoint)  VALUES (geography::STGeomFromText('POINT(-124.957140999999993 39.326679)',4326));

DECLARE @PointAsText NVARCHAR(max);
SELECT @PointAsText = TestPoint.STAsText() from @TestTable;
PRINT @PointAsText;

DECLARE @PointAsBinary BINARY(22);
SELECT  @PointAsBinary = CAST(TestPoint AS BINARY(22)) from @TestTable;
print @PointAsBinary;

print @@version;

在我可用的各种机器上，我看到两个不同的结果：

点（-124.95714099999999 39.326679）
0xe610000000010C1EA5129ED0A94340492A53CC413D5FC0
Microsoft SQL Server 2008 R2（SP1） - 10.50.2500.0 （X64）
    6月17日2011 00:54:03 Windows NT 6.1上的
    Microsoft Corporation
    Developer Edition（64位）（Build 7601 : 服务包 1)

或者

POINT ( -124.957141 39.326679)
0xE6100000010C1EA5129ED0A94340492A53CC413D5FC0
Microsoft SQL Server 2008 R2 (RTM) - 10.50.1600.1 (Intel X86)
    Apr 2 2010 15:52:06 Windows Service Pack2
    版权所有 (c) Microsoft NT6 Corporation
    Build Developer Edition。0 )（管理程序）

另一个测试用例显示具有 2008 R2 (RTM) 的 X64 机器给出-124.95714099999999。因此，绝对表明 x86 与 x64。

我至少对缺乏浮点精度有点熟悉，但我不知道它是特定于架构的。似乎使用 SQL 空间存储涉及通过像这样的 WKT 转换的数据。我是否没有看到更合适的策略来处理这些数据？

4

2 回答 2

0

我以前从未见过这种行为......我也希望在运行相同版本/操作系统时转换是完全确定的。对于它的价值，我可以确认我在 SQL Server 2008 R2 (x64 10.50.2500) 和 SQL Azure (11.0.1831) 下都得到了正确的预期第一个结果 POINT (-124.95714099999999 39.326679)。

我可以请您检查一下，当您执行以下操作时，您是否也从这些机器上获得了相同的结果：

选择@PointAsText；

而不是：

打印@PointAsText；

我承认它有点抓不住稻草，但我只是想提出一些建议来隔离它肯定是@PointAsText 的值已经四舍五入，而不是 PRINT 可能应用的一些有趣的格式......

于 2012-02-10T22:57:37.653 回答
0

几个星期没有活动，所以我会用我所知道的来回答。

我对此的最佳理解是只需要避免使用众所周知的文本 (WKT)。我不确定众所周知的二进制 (WKB) 是否可以作为选项。

为了确保在数据库中使用 SqlGeography 时不会丢失精度/粒度，您可以在中间件或应用程序中使用 SqlGeography 类。该类是二进制可序列化的，以在这方面提供帮助。

通过 Well-Known-Text(WKT) 离开 SqlGeography 类的安全性是精度开始减弱的时候。最好仅在向用户展示或被迫与非 .NET 平台通信（例如使用 Web 服务）时才这样做。

于 2012-02-21T15:30:50.720 回答