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!

Let's Call the Whole Thing Off...

You say “potato”, I say “potato”; you say “long/lat”, I say “lat/long”. Long/lat, lat/long, lat/long, long/lat, let’s call the whole thing off!

This thread at the MSDN forums is an interesting read, if you are a complete loser. (Disclosure: I am a complete loser.)

Y/X World

In a nutshell, Microsoft thinks the world looks like this. OK, OK, I’m being unfair, what they think is that it makes sense to use a latitude/longitude (y/x) order for ordinates in the Well-Known Text (WKT) and Well-Known Binary (WKB) that their STAsText() and STAsBinary() methods return, respectively. (Pls. see above re: my complete loserness.)

This is what the SQL Server spatial team had to say to a user wondering at this behavior:

This is the expected behavior, but as you found there is not a standard industry consensus on the ordering of latitude / longitude coordinates in formats such as WKT and WKB. The OGC SFS document does not cover geographic coordinates, only planar data, so it is not clear that the same ordering is necessary. However, the EPSG definition itself for 4326 defines the axis order as latitude / longitude, and that is what we use and what is defined by other formats such as GML / GeoRSS.

Here is a thread from the OpenGeoSpatial mailing list defining this behavior.

The place where I (surprise!) violently disagree with the Microsoft team is the assertion that “there is not a standard industry consensus on the ordering of … coordinates in … WKT and WKB “. There is, in fact, a massive industry consensus on WKT and WKB coordinate order. If the Microsoft team can find a shipping product that deliberately creates WKT or WKB in lat/long order I’ll send them a 5lb box of Roger’s Chocolates.

The comment goes on to muddy the waters by talking about GML, and GeoRSS and the OGC discussions on the topic of axis order, but is totally wrong about the core issue: what is the industry standard order for WKT and WKB. In this case, Microsoft is late to the game, they don’t get to set the de facto standard, because there is already a de facto standard, and it is long/lat.

If Microsoft wants to interoperate easily with the standards-based products already in the marketplace, they will implement the de facto standard for their STAsBinary() and STAsText() functions. If they are paying lip service to actual interoperability (“we implemented the standard but for some reason absolutely everybody else is doing it different! who knew?”) they’ll do something else.

The de jure standard is, as the comment correctly notes, well nigh impossible to divine, because the OGC guidance on the subject has been scattered through so many areas, and because there is no explicit guidance on the topic for WKB and WKT. But the de facto standard, the “standard industry consensus” is clear: long/lat.

Update: To clarify the chocolate challenge, products that produce backwards WKB and WKT to satisfy SQL Server (FME, Manifold) don’t count. This is about the industry standard that pre-existed SQL Server.

Drived Products

The news that a third center-line road data provider is starting up is very interesting. In an interview with Directions they are relatively closed-lipped about why they think they can compete with the big boys, but a good guess can be had by looking at their earlier news releases. This not a road mapping company, this is a computer vision company. Presumably the liberal application of computer vision allows them to combine their GPS and intertial data with road sign readings to build out full navigation-restricted data without a heavy manual data post-processing step.

That still leaves the tricky aspect of actually driving their cars down every street in the country, and I wonder what mapping source they used to ensure they weren’t missing any. The mathematics of driving every road in the country are also daunting: 4 million miles of roads in the USA, at an average speed of 20 miles per hour, for 8 hours a day, implies 25,000 days of driving! Or $2M using $10/hour drivers, plus the capital cost (at least $5M) of the 70+ vehicles needed to do the thing in about a year.

On the other hand, given that Nokia just paid $8B for NavTeq, the cost of entry into this marketplace is incredibly low — $20M maybe? I think I’m in the wrong business, time to hit the road!

Collaring in OAM

Collaring can pre-exist in images that have been masked prior to delivery, or can be generated by the process of re-projection, as the spare pixels in the target system get filled in with “no data” values.

Openaerialmap of Fort Collins

Sean uploaded some data from his home town of Fort Collins, and the OAM process to reproject it into the global OAM scheme (lat/lon?) collared it, which shows up at the edges of the data.

There are some GDAL tricks to make the collars transparent, but if there’s some blank “no data” areas in the source imagery, it is hard to avoid it. OSSIM has some more advanced mosaicking capabilities that might fit the OAM processing needs better than GDAL.

Real Men use Real GIS Software

Allow me to echo Peter Batty’s sentiment about this silly post in All Points Blog on neography and real “GIS”.

Speaking at Korem’s Geodiffusion conference, Pitney Bowes Software president, Mike Hickey, struck a resonant chord when he explained that “the explosion of Neogeography is driving awareness [and] collaborative data consolidation [but it] isn’t GIS.” Hickey explained that while neogeography is focused on “Where” there is no data creation and no spatial analysis, an essentially visually useful concept that has helped “cross the chasm from early adopters to an early majority.”
All Points Blog

As a former vendor himself, I’m sure Peter recognizes the core appeal here is to the emotional hind-brain of all the suckers^H^H^H^H^H^H^Hcustomers who have already dropped coin for MapInfo software. Hickey is reassuring his customers that neography is (like open source software) fundamentally inferior to real “GIS” because it doesn’t cost enough money.

MapInfo makes Real GIS Software™, and you can tell, because it has a Real Big Pricetag. I know Oracle must be a Great Database®, because it costs a cool 1/4 million dollars to deploy on a 20 thousand dollar dual-quad server.

Try to remember folks, it’s not how big your tool is, it’s what you do with it that counts.