The big Testbed of the year is hot out of the oven at http://www.opengeospatial.org/standards/requests/60. I’ll be running the “Feature and Decision Fusion” thread, which I’m very excited about as it gets me back into some of my favorite topics: geo-statistical analysis, online thematic mapping, and decision support. Bon appetit!
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:
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.
In the OGC Mass Market Geo Working Group meeting yesterday, I presented the preliminary findings of the group brainstorming about the future of KML in the OWS-5 testbed. Most of what was discussed isn’t ready for prime time, so I’ll wait to talk about for a few months, but one critical point that everyone should understand is that KML is, always has been, and will continue to be about mapping/geospatial visualization. Don’t use KML as a data storage or archival format. That’s what GML is for. Yes, KML has some geographic coordinates in there, but KML’s ability to act like a GIS format–attaching other data properties to the geography, typing them, and putting metadata on it all–is weak.
The right way to think about the geographic information “workflow” is to have a spatial database that serves up data to the Web via the Web Feature Service (WFS) API in some flavor of GML. Soon, OGC will specify how that WFS should serve up KML using the existing WFS API plus some extra information to describe the transformation–probably using SLD. The authoritative data will still reside in the spatial database. The KML will just represent one cartographic view of the data at a particular point in time.
