Latitude-Longitude Ordering

Latitude-Longitude Ordering

  • Comments 16

Hi Folks,

If you've been following the spatial forum over at MSDN, you've probably run across this thread.  In short, we've ignited quite a controversy with the coordinate ordering for the well-known text and well-known binary we use for the geography type: we use latitude-longitude; many would prefer longitude-latitude.

While I don't buy into many of the arguments presented, there is one I do very much believe in: usability.  As it would appear that the vast majority of data in WKT and WKB formats use longitude-latitude ordering, we probably ought align to ease the transfer of data in and out of SQL Server.

We'll be trying to make this switch in an upcoming CTP.  There will be no change in the next CTP---that ship has unfortunately sailed---but we hope to make this change before we RTM.  I want to be clear: this is not a done deal, and it's possible our schedule will derail us, but we'll likely make this change.

We do not intend to change our coordinate ordering anywhere else.  GML, both in theory and practice, appears to use a latitude-longitude ordering, so we will continue to do so. 

As always, I welcome comments either here or on the forums.

Happy holidays!

Cheers,
-Isaac

  • PingBack from http://geobabble.wordpress.com/2007/12/18/sql-server-2008-wkt-xy-switching-illustrated/

  • Isaac, that's fabulous, kudos for making the difficult decision to change the behavior on a product already (somewhat) released (hooray for beta releases).

    "What's wrong?"

    "I felt a great disturbance in the Force, as if millions of #ifdefs cried out in terror and were suddenly silenced. I fear something terrible has happened."

  • Isaac,

    Great news! I know the debate raged (and will continue to) but I'm glad that the implementation will be consistent. It's never easy to go back and change such an implementation so I want to commend you for reconsidering it.

  • What's "usable" for some (in this case programmers who don't want to worry about  the details and the implications) can literally kill others. Think of people in vehicles moving at high velocity on or over terrain where some data come from systems with coords in x,y order and other data come from systems with coords in y,x order. Not too far-fetched.

    Standards are what make systems and data usable. Adopting industry standards (and they do exist!) that define unambiguous semantics and prescribe proper usage give you firm ground to argue usability.

    See specs from OGC (http://www.opengeospatial.org/standards/common, http://www.opengeospatial.org/standards/wms, http://portal.opengeospatial.org/files/?artifact_id=6716), GeoRSS (http://georss.org/model), and EPSG (http://www.epsg.org/Geodetic.html) for examples.

  • Hi John,

    This was my initial reaction.  Really, if you look just about anywhere other than how people use WKT and WKB you find latitude-longitude ordering.  I would argue that with any new format we ought use lat-long.

    But, when you look at it, this is really just a formatting issue, and while there is no clear official standard indicating any particular ordering for WKT and WKB, the de facto standard seems, perhaps unfortunately, to be long-lat.

    Cheers,

    -Isaac

  • Isaac: I wouldn't agree. There is a big difference between how we >store< stuff, and how we >display< stuff. Think of dates. They are stored as number of ticks, and it is then up to the developer to decide on a proper input/output format that he will present to the user.

    So as John say, long/lat is usuable for programmers, and guess what... only programmers will be the ones to worry about this, and they are ultimately the ones who control what string representaion of a point will look like on a screen. If we should really go with the analogy if storing data as we present them, why don't we store it in Degree-minutes-seconds with a N/S E/W prefix?

    Honestly I think any kind of internal datastructure should store longitude before latitude. Why? Because it's consistent with how we also store planar coordinates (and yes I do think they can be compared in several ways).

    But kudos for at least changing it for WKT/B.

  • Now that the February CTP (CTP-6) for SQL Server 2008 is available , it's time to let folks know what

  • Could you please elaborate on what it is you are planning to do with regards to latitude / longitude ordering for the CTP following CTP-6?

    I have been through the forum thread you link to and through the CTP-6 post by Ed, and I am still not sure what exactly the change is going to be. Is it that you will switch the WKB and WKT representations for the GEOGRAPHY type to use XY ordering? Is it something else? Or is it all still up in the air?

    Thanks.

  • Hi Folks, I just thought I'd take a few moments clarify the upcoming coordinate order swap for the geography

  • Isaac,  

    this is good news.  In Manifold, I was able to create an SQL loader:

    select "insert into ithparc2 (gid,geometry) values (" & id & ", geography::STGeomFromText('" & cstr(cgeomwkb([Geom (I)])) & "',4326));" from [Parcels]

    this creates thousands of lines of INSERT statements really nicely.  However, converting a Manifold geometry to WKB and then to WKT see the line - CSTR(CGEOMWKB([Geom (I)]) -

    creates the coordinates in reverse order.  

    I'll look forward to the next CTP update.  

  • For those of you who have programs which work with November CTP (CTP-5) and February CTP (CTP-6) and

  • Hi Folks, We have one more upcoming pre-release before we're done with SQL Server 2008, and while I've

  • Hi Folks, As we continue to shut down SQL Server 2008, our first release candidate has been released

  • Hi Folks, This post is motivated by some recent discussion I've seen in the various tubes .&#160; I don't

Page 1 of 2 (16 items) 12