Google announced a data API for Maps this morning in San Jose. This is basically a CRUD service for storing geodata in “the cloud” that leverages Atom in lots of ways. That didn’t sound very world-shaking to me at first since there aren’t even any basic spatial query functions, but there are some ways in which this could be a game-changing service — if you trust Google to be your data custodian.

1. you’re freed from figuring out how to store your data
2. web and phone data creation APIs come free
3. base maps come free too

I’ve felt something like this has been needed for a long time. In my past life doing GIS for urban planning a lot of great initiatives got bogged down by the complexities of how and where to store data and who would administer it after the MIT “techies” left. Hopefully this kind of service gets us over that hurdle.

It will be very interesting to see the uptake of this.

One of the most interesting presentations I saw at ETech was on credit risk data. Here’s a summary from: http://en.oreilly.com/et2009/public/schedule/detail/7513

With our latest project, FreeRisk, we aggregate accurate, accredited risk data, enabling users to generate crowd-sourced algorithms to analyze credit risk and allowing anyone to view the results of these algorithms. FreeRisk aggregates both all standardized XBRL data and public-domain financial data, as well as user-generated content incorporating unstructured data released in financial reports like footnotes, critical to accurate risk assessment. This system allows credit evaluators to focus exclusively on creating and applying risk analytics, instead of working through the complex data management tasks traditionally required to solve these problems or relying on black-box credit ratings.

These guys are extremely smart and have spent a lot of time working with XBRL, and yet one of their main conclusions was that XBRL was too complicated and therefore didn’t have a bright future. Thought that was very interesting.

I agree with Tim Bray (via Eric Garrido (via Bill de hÓra)). USB is an awesome standard because it “just works.” Ever debugged a USB stick?

A big step towards making RSS as clean and efficient is to drop the old, crusty RSS flavors and just use Atom. That’s what OGC has been doing more and more, and that’s why this site advertises only an Atom feed, even though it uses Wordpress and could easily advertise more.

I just heard about this new wiki and had to check it out. The first thing that struck me was the number of ads — 3 on every page: one big house ad* below every entry; a vendor ad along the left, and another distracting animated house ad* along the top. The second thing that caught my attention was the lack of any stated policy about the licensing of the content people contribute. As far as I can tell Questex Media Group will own anything you write on this wiki. Both the ads and the information rights are in stark contrast to what you’ll find on Wikipedia. And finally, why does the geo industry need a separate wiki? I’ve been perfectly happy without one. If Questex can’t address these issues, this wiki is dead on arrival.

* Note for those not in the publishing business. A house ad is an advertisement for the organization providing the content. For example, when a TV network shows an ad for an upcoming show on its own network, that’s a house ad.

This morning at the OGC Technical Committee meeting, the Google Earth & Maps team announced an alpha of libkml, an open source (BSD) library for reading/parsing/writing KML 2.2. It’s a C++ library, but includes SWIG bindings for Java, Python, Ruby, Perl and PHP. The hope is that this piece of code will help developers build comprehensive, robust KML support into their applications. But note, this is NOT a mini-Google Earth. You just get KML support – there’s no way to get that streaming earth imagery goodness that you see in GE, although I suppose you can combine this with a map access API (from Google, Virtual Earth, Yahoo!, etc.) to get nice base maps in your app. Enjoy!