21 Dec 2007
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.)
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.
17 Dec 2007
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!
07 Dec 2007
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.
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.
05 Dec 2007
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.
29 Oct 2007
If you word things right, even pre-existing concepts can be re-packaged as bright original ideas. Google has filed a patent on an indexing method that is nothing but a specialization of a quad-tree, and a packing of level/row/column information into a 64-bit address space.
The specialization of quad-tree is to always use powers-of-two: cut your parents into four identical children; ensure the children are at a scale exactly half that of the parents. This yields nice behavior in the row/column, you can traverse to the parent row/column of a cell just be dividing the current row/column by two.
The packing of the information into a cell id is not completely clearly explained, because there is some talk of compacting and stop bits, to fit 31 levels, but even without compacting a 64-bit space can hold 29 levels quite easily (5 bits of level information, 29 bits of row address, 29 bits of column address).
I am a bit incredulous at the implied assertion that no one thought of chopping up the map of the world in descending powers-of-two before. The specific claims about the packing method might indeed be “original” but in such a trivial way as to be unimportant.
The whole process of software patenting reminds me of the historical acts of enclosure in England.
They hang the man, and flog the woman,
That steals the goose from off the common;
But let the greater villain loose,
That steals the common from the goose.
– Oliver Goldsmith
