Open Source on a GSA Schedule

After much wailing and gnashing of teeth, Refractions secured a GSA schedule today (it’s not on their web site yet, but we just got the “contract is in the mail” notification)! For those not in the know, it’s worth an explanation.


GSA is the US General Services Administration, a catch-all purchasing authority for the US federal government. Government purchasing is difficult, because spending taxpayer’s money requires a good deal more transparency and fairness than needs to be exercised in the private sector. Doing “requests for proposals” is a lot of work, to write and evaluate, and many jurisdictions have routed around RFPs by creating the idea of a “standing order”, a pre-negotiated contract for specific products or services. GSA creates standing orders for the entire federal government, so having a GSA contract allows you to sell to a lot of clients with a lot less paperwork.

So this is a big deal for Refractions, and now opens the door to the question: can we sell enough open source (and other) geospatial services to keep our GSA contract? GSA contracts are a use-it-or-lose-it affair, so we have to hit minimum sales targets or they rip it up.

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.