SQLAlchemy is the ultimate database toolkit for Python. GeoAlchemy extends it to provide a OGC SFSQL-style spatial ORM. It has an API that looks a bit like Shapely's and the math is also done by GEOS (at least with PostGIS and SpatialLite backends), but using a SQLAlchemy connection to a database instead of libffi and ctypes. I toyed around with SQLAlchemy and Shapely a while back, but Sanjiv's project looks like something that could become very useful for Python and GIS programmers who work with a spatial RDBMS.

Andrew Turner quoted me yesterday. The missing context of the quote, which I've linked to several times, is Clay Shirky's essay in praise of evolvable systems, in particular this bit:

HTTP and HTML are the Whoopee Cushion and Joy Buzzer of Internet protocols, only comprehensible as elaborate practical jokes. For anyone who has tried to accomplish anything serious on the Web, it's pretty obvious that of the various implementations of a worldwide hypertext protocol, we have the worst one possible.

Except, of course, for all the others.

You must read it if you haven't already. It's every bit as relevant for today's discussion of the "GeoWeb" as it was for the discussion of the web in 1996.

I'm surprised and disappointed that so much of the discussion at the GeoWeb conference seemed to be stuck on "top-down vs bottom-up" or "80 percent vs 20 percent" or "B2B vs B2C". Of these, the first is the closest approximation of a serious discussion about the nature of the "GeoWeb": is it to be an open, evolvable and therefore always incomplete system, one that demands and rewards innovation -- or is it to be a entire, fixed, thoroughly standardized and unsurprising system? The other two debates are bogus. "'Tastes great' vs 'less filling'".

The Map Butcher writes:

The deadline for the CCIP is approaching and I’ve been lurking on the announcement list and was really interested in this great little application which provides sensor data via Sensor Observation Services. I think the reason that I like this site so much is that it paints a really clear picture of sensor web enablement, and it’s an effective presentation of cross agency data.

It is indeed a neat app, but color me unimpressed (still) by "sensor web enablement". You can't truly call this a clear picture of the OGC's SWE because there's actually nothing done by this application that couldn't be done equally as well using (for example) an Atom + GeoRSS syndication architecture with links to structured data slice resources, perhaps even using GET requests to an SOS service, and javascript to display the data. In fact, I think a syndication-based design does it better: you'd also get discovery, permalinks, paging, synchronization, and potential for reuse of the sensor feeds in feed readers and other applications yet to be imagined.

A sensor is just a robo-blogger, right? Let's connect them to the web with blog technology.

Sunday, we spent the entire day out and about in the neighborhood of Saint-Guillaume-le-Désert. It's a well-preserved, captivating (the French say séduisant) medieval village. Touristy, but that's France in the summer. Mainly French tourists, but we heard Spanish, Italian, and English. The centerpiece of the village is the Abbaye de Gellone. Founded in 806 by William de Gellone, a compatriot of Charlesmagne, the Abbey became a popular destination for pilgrims, prosperous, and a home for the arts. There's an excellent multimedia presentation at the Abbey's small museum which describes an ongoing process of laser-scanning the scattered pieces of the Abbey's cloister (many in New York City, Paris, Montpellier) and virtually reassembling the structure and its decorative stone work.

Below is a fun inscription we saw in the museum. I don't read Latin at all. It's quite possible that the text isn't as jolly as the typography.

This photo shows a trail that leaves the village, following a stream into a steep box canyon. Below, there are olives groves, and higher, a research forest. At the the end there is a sequence of narrow waterfalls (dry, now) not unlike what you'd find in the Colorado Plateau, though in limestone instead of sandstone. If I'd had better shoes, I might have tried to scramble up the first one.

Sadly, Google Earth's imagery for the region is low-res only. It's spectacular country. Below Saint-Guillaume-le-Désert are the gorges of L'Hérault, the end of which is spanned by an intact 11th century bridge (shown in images at the end of the French Wikipedia page). Below this bridge, there's an enormous swimming hole and a rocky beach used by hundreds of tourists.

We didn't have our GPS with us, but I have added a few useful points of interest (my first) to OpenStreetMap using Potlach. We'll be returning off-season to do more hiking and fill in some more empty places on the map.

Update (2009-08-10): Here's a photo of the fall:

Made me a bit homesick for the badlands of Utah, it did.

Rtree 0.5.0 and spatialindex 1.4.0 are out. The major new features are:

• Better platform parity
• Efficient bulk indexing
• Arbitrary dimensionality
• Improved performance tuning

See Howard Butler's release note for details. The spatialindex lib is beginning to develop a user community of its own. For them, the major new feature is a C API (also used now by Rtree).

The reasons we're using KML (which some consider a fork of an early version of GML) instead of GML (version 3) for "GeoWeb" applications have almost nothing to do with the actual merits of these formats. It all comes down to imagery, imagery, imagery. If only there was as much semi-free, global, high-res imagery behind GML 3 applications as has been deployed for Google Earth, we'd all be deliriously in love with GML. Stefan Geens and Frank Taylor would be tirelessly blogging about all the awesome possibilities of GML. Google would have indexed half a billion GML documents. I might even write a Python GML library. People aren't doing things with KML that you couldn't do with GML. It's all about the free-ish imagery on the KML platform.

(with apologies to James Carville)

Well, I'll be a monkey's uncle (via Peter Batty):

Clemens gave an excellent and very frank talk on "The gap between SDIs and the GeoWeb". A couple of quotes that I noted were "So far the impact of SDIs on the integration of data as a ubiquitous component of the web seems low" and "There is not evidence that SDIs have increased the market volume of government data by a significant amount". He noted that OGC web services are based largely on an architecture and approach to web services developed around 10 years ago, well before many recent web innovations.

The WxS specifications began coming out 10 years ago, but the OGC's approach certainly predates the web.

At the 2007 FOSS4G conference, Charlie Savage (not, I think, intentionally invoking Ziggy Stardust) gave the OGC's WxS architecture 5 years. It seemed ridiculous then to say even what now appears, coming from Clemens, to be conventional wisdom. What will 3 more years bring?

What do the people pushing "GeoWeb" at Google, a company founded on links, think about geographic data and web architecture? It's not so clear. I've been waiting for a post like this from Mano Marks:

Is that the nature of geographic data? Or have we just not found the true linkability of it? I tend to think it's the former. Geographic data is heirarchical, it is ontological, it is content rich, it is combinable. It is linkable through common ontologies. But geographic data doesn't lend itself to easy linking in the same way. It's the nature of structured data, it must relate to a structure. Ontologies are almost the antithesis of linkablity outside the domain.

I think he's overlooking another form of linking in KML: the combination of "network links" and "regions". In practice, KML applications use this to implement pyramids of increasing resolution for data from a single domain, but one should be able to network link in the same way to KML applications from other domains that best serve a particular view. It might even be feasible to implement an agent that would crawl network links. Some changes to the network link to make it more like other web links would probably help. Linked geographic data [1] could be right here under our noses, in KML, already.

[1] Yes, I know I'm abusing the linked data brand.

This little place is a gem, and its immediate environs the most pleasant spot we've found in Montpellier. According to the Routard, it was cleared to make way for a new church in the early 17th century. When that project was abandoned, the grounds became public.

It appears as a little green patch in OpenStreetMap and from the Googlesat. The Google has a decent street view too, but tonight it looked like this:

Update (2009-08-01): I don't know my way around OSM very well, and just now stumbled onto another representation of Place de la Canourgue at http://api.openstreetmap.org/browse/way/8105279. This one has links to its nodes and connected ways. Are these "browse" URLs as cool as they look like they could be?

I'd sure like to see this:

Herodotos Encoded Space-Text-Imaging Archive

Elton Barker (Oxford) & Leif Isaksen (Southampton)

Digital Classicist/ICS Work in Progress Seminar, Summer 2009

Friday 31st July at 16:30, in room STB3/6, Senate House, Malet Street, London WC1E 7HU

HESTIA (the Herodotus Encoded Space-Text-Imaging Archive) is an interdisciplinary project, involving the collaboration of two classical scholars, a modern political geographer and an IT consultant, that aims to enrich contemporary discussions of space by developing an innovative methodology to the analysis of Herodotus’ History. Combining a variety of different methods, it investigates the ways in which space is represented in Herodotus’ History in terms of places mentioned and geographic features described, and develops visual tools to capture the ‘deep’ topological structures of the text, extending beyond the usual two-dimensional Cartesian maps of the ancient world.