I was at the Earth Science Information Partners (ESIP) meeting last week, and was a little surprised at how much these folks like KML and GeoRSS. OGC stalwarts generally think of simple encodings like these as just good enough to get the job done, if the job you’re doing is pretty simple. The jobs of ESIP members is not, however, simple.

This group is comprised of NASA researchers and other earth, air and water scientists who regularly deal with multi-terabyte databases of satellite imagery and other GIS data sets, so you’d imagine that they would be quite content with their high-end GIS systems. But while there was certainly plenty of industrial strength GIS going on, a good third of the attendees came to the KML and GeoRSS Birds of a Feather session. This made me realize two things:

1. The work we did in OWS-5 on defining how to output KML from a WFS will be very useful
2. We’d better tell people about it so they don’t duplicate our efforts

So at this point you’re probably saying, “get to the point. How do you output KML from WFS?” The easy way is to just get software that does it. In OWS-5, the open source Geoserver and Galdos Systems’ commercial product Cartelinea implemented this functionality. If you have your data in PostGIS, ArcSDE, Oracle Spatial, or Shapefiles, just set up the Geoserver or Cartelinea to server that data via the WFS API and you get KML support for output automagically.

If you want to know how to code your own support, you’ll need to read the upcoming revision to the “Styled Layer Descriptor profile of the Web Map Service Implementation Specification”, but I’ll give you the 30-second version here.

A WFS outputs only data (usually in GML format). KML, however, is data plus styling rules. So to control the output of KML from a WFS, you specify the data you want with a normal WFS request, but you also specify the styling rules using the Styled Layer Descriptor (SLD) language. We call this combination of data request API and style configuration a Feature Portrayal Service (FPS). It’s pretty much a melding of the WFS and WMS APIs. So if you’re familiar with WMS, WFS, and SLD, implementing FPS is straightforward. Just read that SLD profile of WMS document and let me know how it goes.

I came across this story today, “Yahoo Opens Address Book Interface.” A quote:

Yahoo is opening the interface for its address book for outside use…For example, a programmer starting up a social networking site could use the interface to send invitations to a member’s list of contacts stored at Yahoo. Yahoo users have stored more than 500 million address books, and the service is used by more than 150 million unique users each month. Opening the address book API (application programming interface) is the second major step taken so far in executing the Yahoo Open Strategy that Chief Technology Officer Ari Balogh announced in April 2008. Yahoo Open Strategy is an attempt to link the company more with other Internet activities rather than remain a sealed-off, if sprawling, Internet domain. Through its open strategy, the company envisions outside programmers building Web applications on Yahoo’s site, Yahoo services being incorporated into outside applications, and social connection information within Yahoo being used more widely.

This article is not so interesting from a technology perspective — after all, Web service APIs are pretty common nowadays. What’s fascinating to me is the positioning of this decision from a business perspective, and how Yahoo! hopes to enhance its brand, increase its business, and continue to capture Web presence as it allows competitors and collaborators to access a key information source — its customers’ contact information. I hope they’re successful, and we see more of this kind of interoperability in the future.

This story reminded me that I hope to see more integration between geo-oriented sites. Just about everyone from Google to Microsoft to FortiusOne lets you create geodata and output KML, but as far as I know you can’t mix, match or merge data sets from different sites (except visually, of course).

Technorati Tags: fortiusone, google, kml, microsoft, yahoo

After a little less than a year of great work by the KML SWG, we have a standard! The OGC press release gives some facts and a link to the OGC KML 2.2 Standard, and John Timmer at ars technica has a nice piece on the significance of this step. His article won’t offer anything new for geo industry veterans, but it’s great to see the mainstream IT media “get it” when it comes to our technologies and markets.

This is hopefully a big win for individuals who contribute data to one site, and would like to use it in many others — not to mention the companies whose business model revolves around these altruistic, bottom-up data providers. One small step for OGC, and one big step towards breaking down data silos!

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!

I was over at Harvard yesterday talking to people from the GSD, the Herbarium, the Library, the new Center for Geographic Analysis, and MassGIS. It was great to see some old friends and make some new ones. One topic that came up was why you don’t see OGC standards in widespread usage. I argued that the geospatial Web is where the regular Web was in 1996, when the tech industry thought that HTML was so easy and powerful that everyone would build their own Web sites — not by writing HTML but by using tools like Dreamweaver. As it turns out, that was still way too high a barrier to entry. People didn’t want the hassle of designing a site from scratch. They wanted to post a blog entry or a MySpace page. That’s when the Web saw a real quantum leap in content.

So in my mind, there’s a continuum of tech diffusion, where the first stage is raw HTML/XML/KML/URL coding by alpha techies. The second stage is using software tools that automate that raw coding. And the real diffusion comes when companies offer tools that automate 90% of the content creation busywork, and let users compete that last 10% that is unique to their interests. OGC is just moving into the second stage, and we don’t even know what that last stage will look like.

The discussion reminded some of us of an idea we had late in the 1990s that mapping should be as commonplace as spreadsheets. We were wondering whether that type of revolutionary leap could come from the GIS industry or would come from mainstream Web hackers. So it was very timely to wake up today and see this Wired article today about using Google Spreadsheets to create KML. Is this the way most geographic content creation will happen in the future?