Несоответствие между компьютерами в преобразовании WKT для пространственных типов SQL - PullRequest
Новая
       74

Несоответствие между компьютерами в преобразовании WKT для пространственных типов SQL

0 голосов
/ 10 февраля 2012

Я испытываю противоречивое поведение на разных машинах с преобразованием в общеизвестный текст (WKT) пространственных типов в SQL Server 2008. Похоже, что данные хранятся одинаково, но преобразование обратно в WKT действует по-разному в зависимости отmachine!

Вот что-то, что я собрал, чтобы точно определить проблему: 

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;

На разных машинах, которые у меня есть, я вижу два разных результата:

POINT( -124.95714099999999 39.326679)
0xE6100000010C1EA5129ED0A94340492A53CC413D5FC0
Microsoft SQL Server 2008 R2 (SP1) - 10.50.2500.0 (X64)
17 2011 2011
Авторские права (c) Microsoft Corporation
Developer Edition (64-разрядная версия) в Windows NT 6.1 (сборка 7601: пакет обновления 1)

или

POINT ( -124.957141 39.326679)
0xE6100000010C1EA5129ED0A94340492A53CC413D5FC0
Microsoft SQL Server 2008 R2 (окончательная первоначальная версия) - 10.50.1600.1 (Intel X86) * 10312010 15: 53: 02
Авторские права (c) Microsoft Corporation
Developer Edition для Windows NT 6.0 (сборка 6002: пакет обновления 2) (гипервизор)

Еще один тестовый примерпоказывает, что машина X64 с 2008 R2 (RTM) дает -124.95714099999999 .Итак, определенно указывает x86 против x64.

Я, по крайней мере, немного знаком с отсутствием точности с плавающей запятой, но я не знал, что это специфично для архитектуры.Кажется, что работа с пространственным хранилищем SQL включает в себя данные, проходящие через преобразования WKT, подобные этим.Не вижу ли я более подходящей стратегии для работы с этими данными?

Ответы [ 2 ]

0 голосов
/ 21 февраля 2012

В течение пары недель не было никакой активности, поэтому я отвечу тем, что знаю.

Мое лучшее понимание этого заключается в том, что нужно избегать использования хорошо известного текста (WKT). Я не уверен насчет хорошо известного бинарного кода (WKB) в качестве опции.

Чтобы быть уверенным, что вы не потеряете точность / детализацию при использовании SqlGeography в своей базе данных, вы можете использовать класс SqlGeography в своем промежуточном программном обеспечении или приложении. Этот класс можно сериализировать в двоичном формате, чтобы помочь в этом отношении.

Выход из безопасности класса SqlGeography через Well-Known-Text (WKT) - это когда точность начнет падать. Это предпочтительно делать только при показе пользователю или при принудительном взаимодействии с платформами, отличными от .NET (например, при использовании веб-службы).

0 голосов
/ 11 февраля 2012

Я никогда не видел такого поведения раньше ... Я тоже ожидал, что преобразование будет полностью детерминированным при работе с той же версией / ОС. Для чего он стоит, я могу подтвердить, что я получил правильный ожидаемый первый результат POINT (-124.95714099999999 39.326679) под SQL Server 2008 R2 (x64 10.50.2500) и SQL Azure (11.0.1831).

Могу ли я попросить вас проверить, что вы также получаете те же результаты от этих машин, когда вы:

SELECT @PointAsText;

вместо:

PRINT @PointAsText;

Я признаю, что это немного цепляется за соломинку, но я просто пытаюсь предложить что-то, чтобы изолировать, что это определенно значение @PointAsText было округлено, а не какое-то забавное форматирование, которое может применять PRINT ...

...