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.

It’s gorgeous, it’s versatile, it’s intuitive — it’s more Mac than a Mac. But it will not run just any outside code. Outsiders can’t just send the next VisiCalc to iPhone owners directly. Instead, proposed new software must go through the centralized iPhone Apps store. Apple takes a cut of each piece of software sold and reserves the right to kill any app it doesn’t like.

This from a great story on Marketplace, my absolute favorite news program in the world. In “Apple’s tech goes suburban,” Jonathan Zittrain argues that only allowing applications for the iPhone to be distributed through the “iPhone Apps store” is bad for small developers, and consequently bad for innovation. I agree, but this isn’t surprising given Apple’s track record, nor is it new.

Service providers like Verizon have been playing this game forever, restricting phones’ hardware and software capabilities and making customers go through the phone company for the privilege of putting applications on a device they already own. That’s why there’s a Nokia S60-based device in my pocket, and that’s why I’ve had software that let’s me take location-tagged pictures for over a year now–unlike iPhone users who will get their hands on this “cutting edge” feature in a few weeks. Sure the software was beta quality and a little clunky, but it worked for me, and I bet apps like these helped refine the products from bigger companies that came later to market.

I’m not a big fan of having a lot of software on my phone, but I do like diversity. And I know from past experiences in a small startup, and as a graduate student in a research lab, that trying to innovate on mobile platforms is a huge pain. Lot’s of great ideas have died on the chalkboard due to the hassles the mobile industry puts us through to get software on devices, and that just can’t be good for business.

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

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!

Needless to say, I was shocked and amazed when I saw this statement on Microsoft’s new Interoperability Principles this weekend. To summarize, they are committing to make open and public the protocols and APIs for their major products, including Vista, Exchange, SQL Server, and Office. And, wait for this, access to those documents will be free. Is your mind blown yet? How about reading on and seeing that they plan to embrace non-Microsoft standards, and “increase interoperability with open source solutions”? I’m going to take all this at face value and say, “Bravo Microsoft!” I hope it all plays out according to this plan. The IT world will be a much better place if it does.