Jason and Mateusz have each posted about Python bindings for FDO this morning, and so I took a look into it. I've been intrigued by FDO ever since I heard of it in October of 2005. Python is my bread and butter, and I'm sad to say that the FDO Python bindings are disappointing.

This, in particular:

oProperties.Release()

almost made me cry like the man in the classic anti-littering PSA. Python has garbage collection. Don't abuse your users. They shouldn't have to explicitly free memory allocated for objects.

Thanks to SWIG, the Python bindings are a literal translation of the C++ API, excruciatingly verbose and explicit, and annoyingly un-Pythonic. The developers need to learn about Python patterns and protocols, and implement them. As I mentioned in Jason's blog, factory methods like:

>>> schema = FdoFeatureSchema.Create(sSchemaName, sSchemaName)

need to be changed to the familiar form:

>>> schema = FdoFeatureSchema(sSchemaName, sSchemaName)

That's how it's done in Python. Any other way is needlessly confusing. Implementing Python's mapping protocol would let users write:

>>> sewer_pipe = classes["SewerPipe"]

in the natural Python way instead of:

>>> oClass = oClasses.FindItem("SewerPipe")

Seriously, The Day the Earth Stood Still is one of my favorite films. Let there similarly be peace between proprietary and open source GIS software, a peace maintained eternally by shiny, indestructible, planet-busting robots.

Sure, SOA is an easy target for parody, but Pete Lacey's table is still hilarious. What's the maturity level of your organization?

What is an RSS feed? It's a web resource that summarizes, in a document, changes to other web resources. What is GeoRSS? It's a specification of how to add simple geographic metadata to RSS feeds to complement standard metadata such as titles, descriptions, publication dates, and modification dates. The geographic metadata is there so that we can filter feeds on spatial, as well as textual or temporal, criteria.

GeoRSS metadata also paves the way for a new class of feed aggregator. Instead of displaying feed items as a list ordered by date we can display feed items on a map -- and this is where people begin to take GeoRSS too far. GeoRSS is being confused with a GIS data format, and people are coming to it as a serialization for shapefile-y (meaning no associated web resources) data like GPS tracks and airplane flight paths, with little if any, consideration of what RSS is about.

The GeoRSS community needs to hold the line on simplicity, continue to hew to the Web, and show people who are looking for an XML serialization of GIS data the way to GML.

Cool! I have submission number 007:

Thank you for submitting a presentation abstract for FOSS4G.
You will be notified after the submission closing date regarding
the status of your presentation.  Please direct any correspondence
regarding your submission to xxxxxxxxxxxxx@xxxxxxxxxx.xxx and quote
your submission number in the subject line of your email.

Submission #: 7

Presenter: Sean Gillies
           xxxxxxxx@xxxxx.xxx.xxx
           Ancient World Mapping Center,
           University of North Carolina at Chapel Hill

-- Title --

Pleiades: Building a RESTful, Open Source GIS for the Humanities

You may know me as a gadfly in the blogosphere, but I have a history of delivering serious, sober, nuts-and-bolts presentations and workshops at the predecessors to FOSS4G 2007 -- all the way back to the first in 2003. Should the powers that be accept submission 007, attendees will learn about data modeling (with open source software), development infrastructure (with open source software), and RESTful Web GIS development (with open source software). I'll explain why you should have URLs for everything, how to leverage HTTP caching, and demonstrate Pleiades's open source tools for working with GeoRSS, GML, and KML. And all without whining or rolling my eyes about W*S or OSGeo.

The full abstract is in the Pleiades wiki, here.

While reviewing Pleiades placemarks, I stumbled onto some interesting Panoramio content in the neighborhood of Hephaistion [KML]. The Barrington Atlas indicates a feature named CHIMAERA M. at the site of Hephaistion, a hill about one mile east of the Lycian coastal road.

Unless these photos are a hoax, the ancient, natural vents are still leaking methane, and can be lit by tourists. A ruin, presumably the Hephaistion temple itself, is at the lower right of the second image, not far from the leaking rock outcrop.

The geography of southwestern Turkey is blowing my mind. While you've got Google Earth open, check out Hierapolis, Turkey's Yellowstone.

ArchAtlas is another of Pleiades's neighbors at the corner of GIS and Humanities. It takes an approach different from MAGIS, using KML and WorldWind plugins for browsing their database of sites.

Just so you know: the AWMC logo, which you'll be seeing in our Google Earth bubbles, goes back to 2000, well before Panoramio or OSGeo.

(The image, of course, refers to this.)

I'm one of those who feels that KML needs an update if it's going to become a standard. Keyhole Markup Language has a legacy sound to it. Here are a few possibilities:

Kartography Markup Language. Think Krab. A nod to the old-timers who bemoan what passes for cartography these days, dagnabbit.

Kang and Kodos's Markup Language. I bet I'm not the only one who sometimes feels like an alien presence monitoring an oblivious Earth, ripe for the plucking.

A quick pass through my OED didn't turn up any real winners. Let me know if you have any ideas. Best one wins a free copy of OWSLib.

Update: the winner, from the GeoRSS list, is KML Markup Language.

I'm sorry, but this post is nonsense. There's almost nothing more annoying than deliberate obtuseness about open source and free software.