Cross-machine inconsistency in WKT conversion for SQL spatial types

Question

I am experiencing inconsistent behavior across machines with conversion to Well-Known Text (WKT) of spatial types in SQL server 2008. It looks as if the data is being stored identically, but the conversion back to WKT acts differently depending on the machine!

Here's something I put together to pinpoint the issue:

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;

On various machines I have available, I see two different results:

POINT (-124.95714099999999 39.326679)
0xE6100000010C1EA5129ED0A94340492A53CC413D5FC0
Microsoft SQL Server 2008 R2 (SP1) - 10.50.2500.0 (X64)
    Jun 17 2011 00:54:03
    Copyright (c) Microsoft Corporation
    Developer Edition (64-bit) on Windows NT 6.1 (Build 7601: Service Pack 1)

or

POINT (-124.957141 39.326679)
0xE6100000010C1EA5129ED0A94340492A53CC413D5FC0
Microsoft SQL Server 2008 R2 (RTM) - 10.50.1600.1 (Intel X86)
    Apr 2 2010 15:53:02
    Copyright (c) Microsoft Corporation
    Developer Edition on Windows NT 6.0 (Build 6002: Service Pack 2) (Hypervisor)

Another test case shows that an X64 machine with 2008 R2 (RTM) gives -124.95714099999999. So, definitely indicates x86 vs x64.

I'm at least somewhat familiar with lack of floating point precision, but I was unaware it was architecture specific. It seems as if working with SQL spatial storage involves data going through through WKT conversions like these. Am I failing to see a more appropriate strategy to working with this data?

Answer 1

There's been no activity for a couple weeks so I'll answer with what I know.

My best understanding of this is that use of Well-Known-Text (WKT) just needs to be avoided. I am not sure about Well-Known-Binary (WKB) as an option.

To be certain that you don't lose precision/granularity when using SqlGeography in your database, you can use the SqlGeography class in your middleware or application. The class is binarily serializeable, to help in this regard.

Leaving the safety of SqlGeography class via Well-Known-Text(WKT) is when precision will start to fade. It is preferable to do this only when showing to the user or when forced to communicate with non-.NET platforms (such as using a web service).

Answer 2

I've never seen that behaviour before... I too would have expected the conversion to be completely deterministic when running the same version/OS. For what it's worth, I can confirm that I get the correct expected first result POINT (-124.95714099999999 39.326679) under both SQL Server 2008 R2 (x64 10.50.2500) and SQL Azure (11.0.1831).

Can I ask you to check that you also get the same results from these machines when you:

SELECT @PointAsText;

rather than:

PRINT @PointAsText;

I admit it's clutching at straws a little bit, but I'm just trying to suggest something to isolate that it's definitely the value of @PointAsText has been rounded and not some funny formatting that PRINT could be applying...