Thursday, December 27, 2007

They Called It Off!

Good news from down Redmond way. The SQL Server spatial team has decided to make the coordinate order returned by their STAsText and STAsBinary functions consistent with the existing industry practice: (easting, northing) or (longitude, latitude) or (x, y), depending on how you look at it.

That kind of community responsiveness practically cries out for... a five pound box of chocolates! Note to Isaac and company: don't eat them all in one sitting, no matter how tempting it might be!

7 comments:

Dave Smith said...

Really, the order depends on the context. Usually the order is defined in the EPSG database for the specific CRS in question.

Further, I'd argue there is NOT any overwhelming consensus that it should be Long/Lat versus Lat/Long - I would submit that organizations like OGC, OASIS, IETF, and ISO more often than not use the convention of Lat/Long.

Seems that often folks just skim the surface and arrive at a conclusion, as opposed to digging a bit deeper and actually filling in all the pieces. EPSG:900913 for Spherical Mercator for example. EPSG has probably never even heard of it - and they probably should, if folks are going to start using it.

You say "toe-MAH-toe" and he says "tah-MAY-dah"... But at the end of the day it's still a tomato, no matter how sliced, pureed, et cetera...

Paul Ramsey said...

With respect to axis order in geodetic coordinate systems in general, Dave, you are correct, there is no single practice, and the standards bodies specify different things but in fact tend to do lat/lon more often than not.

With respect to axis order in WKB/WKT in particular, lon/lat is the order used by every piece of existing software that produces and/or consumes WKB/WKT. So what is the smart thing for Microsoft to do?

Even more, their STAsBinary(geometry) function already returns things in lon/lat order. Would it make sense for their STAsBinary(geography) to do the opposite?

I think they made the right decision here.

Dave Smith said...
This comment has been removed by the author.
Dave Smith said...

My point was on the bigger issues of consensus - we see the lack of consensus throughout other arenas in the GIS sector.

I wholly agree they shouldn't be going literally 90° to what everyone else is doing with respect to WKT.

The problem is, there's a lot of "ad hoc" efforts out there (not meaning to single out or pick on the EPSG:900913 example above, it's just one of many similar things going on).

No direct fault of any particular developers, as there are a lot of things being pushed to release concurrently with limited documentation or non-overlapping user base, developing in parallel - essentially many issues which could have adverse longterm impact, which not enough people can look at with respect to the big picture - and the standards bodies out there are certainly not agile enough to keep pace.

Certainly some things were not anticipated by the standards bodies, and rather than waiting, folks go around them - but in other cases, folks (like Microsoft in this instance) may be unwittingly reinventing or misinterpreting the wheel.

Mateusz Loskot said...

Here is another interesting issue from the SQL Server team to discuss:

Read v1.2.0 and get more in line with this spec.

Joshua said...

After many years of repetition, it is very unclear why there should be any ambiguity left. The definition of coordinates is provided entirely by the coordinate reference system (CRS) in which they are used. EPSG geographic CRS definitions clearly and unambiguously put the latitude coordinate before the longitude coordinate. This follows centuries of geodetic practice.

Of course (most) software developers are not geodeticists and wonder why they should have to switch coordinate order between geographic and projected CRS's, at the same time that they happily convert between various computer graphics conventions, e.g. top-left and bottom-left origins.

All this would be no problem, except when developers refer to the clear EPSG standard and at the same time (wink-wink) turn the coordinate order around. The ambiguity comes from citing an authority and then doing the opposite of what is authorized, with no more documentation than "Didn't you know that everyone does it this way".

It appears to be true that the majority of stored geodata and software codes have geographic data in lon-lat order and reference EPSG:4326. All that is needed is consistency. Either pass data in lat-lon when EPSG:4326 is cited, or use a CRS definition which specifies lon-lat order. Better yet, add a simple conversion routine and support both.

The use of CRS just needs to be clear and consistent so we don't continue to drive our North American cars into the Indian Ocean...

Isaac Kunen said...

Wow! I wasn't expecting chocolates.

My thanks to you for the candy---the team has barely begun to dig into this mountain---as well as to everyone who has provided us with feedback so far. We really are trying to produce the best release we can, and this feedback really helps.

Cheers,
-Isaac

About Me

My Photo
Victoria, British Columbia, Canada

Followers

Blog Archive

Labels

bc (33) it (27) postgis (19) icm (11) video (10) enterprise IT (9) sprint (9) open source (8) osgeo (8) cio (6) management (6) enterprise (5) foippa (5) foss4g (5) gis (5) spatial it (5) foi (4) mapserver (4) outsourcing (4) bcesis (3) oracle (3) politics (3) COTS (2) architecture (2) boundless (2) esri (2) idm (2) natural resources (2) ogc (2) open data (2) opengeo (2) openstudent (2) postgresql (2) rant (2) technology (2) vendor (2) web (2) 1.4.0 (1) HR (1) access to information (1) accounting (1) agile (1) aspen (1) benchmark (1) buffer (1) build vs buy (1) business (1) business process (1) cathedral (1) cloud (1) code (1) common sense (1) consulting (1) contracting (1) core review (1) crm (1) custom (1) data warehouse (1) deloitte (1) design (1) digital (1) email (1) essentials (1) evil (1) exadata (1) fcuk (1) fgdb (1) fme (1) foocamp (1) foss4g2007 (1) ftp (1) gds (1) geocortex (1) geometry (1) geoserver (1) google (1) google earth (1) government (1) grass (1) hp (1) iaas (1) icio (1) industry (1) innovation (1) integrated case management (1) introversion (1) iso (1) isss (1) isvalid (1) javascript (1) jts (1) lawyers (1) mapping (1) mcfd (1) microsoft (1) mysql (1) new it (1) nosql (1) opengis (1) openlayers (1) oss (1) paas (1) pirates (1) policy (1) portal (1) proprietary software (1) qgis (1) rdbms (1) recursion (1) regression (1) rfc (1) right to information (1) saas (1) salesforce (1) sardonic (1) seibel (1) sermon (1) siebel (1) snark (1) spatial (1) standards (1) svr (1) tempest (1) texas (1) tired (1) transit (1) twitter (1) udig (1) uk (1) uk gds (1) verbal culture (1) victoria (1) waterfall (1) wfs (1) where (1) with recursive (1) wkb (1)