2009 (old posts, page 7)


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.


Re: GeoAlchemy

Author: Sanjiv Singh

Thanks for the post Sean. I must thank Michael Bayer (author of SQLAlchemy) and Mark Ramm (my mentor) for making GeoAlchemy what it is. I hope the project is able to see some community participation and becomes really useful. :)

3 choices

Author: Paolo

Cool, now Python devevelopers have 3 choices to build spatial applications without starting from scratch: Shapely, GeoAlchemy and GeoDjango.

There is even too much choice! ;-)

Re: GeoAlchemy

Author: Sean

The right amount of choice is a matter of taste. Some people like more, some less.


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'".


Re: Evolvability

Author: Terry

"is it to be an open, evolvable and therefore always incomplete system, one that demands and rewards innovation"?

Yes, please.

Data blogging

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.


Re: Data blogging

Author: Sean

Via Matt Ball, I've come across SensorBase (http://sensorbase.org/) from CENS (http://research.cens.ucla.edu/). CENS is thinking about sensor blogging too, at least metaphorically; SensorBase doesn't use a feed architecture that I recognize. Still, it sure is fun to see curl used.


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.


Re: Saint-Guilhem-le-Désert

Author: Clemens Radl

The inscription reads "HIC IACET BLADALDUS PRESBITER QUI OBIIT III ID NOV". This translates to "Here lies the priest Bladaldus who died on November 11". So this was a grave stone.

By the way, Géoportail has some higher-resolution aerial images from this region. See http://is.gd/2aAHK (with an overlay of the excellent IGN map). It's not as easy to navigate as Google Maps, but it offers good images and great maps. On the left hand side you can set the opacity of the map and the image.

Thanks for yet another fascinating sightseeing advice. We are going to spend this year's summer vacation in this area of France, so your reports with photos, descriptions and map links are extremely interesting and valuable.

Re: Saint-Guillaume-le-Désert

Author: Sean

Thanks, Clemens. Now I see that one can get above the dry fall by taking an earlier right branch of the trail :) There are at least 2 afternoons worth of hikes in this valley. And Grotte de Clamouse, which I'm also keen to see, is just down the road. When it's hot, a cave is the only thing that beats a swim in the river.

Here's a tip for visiting in the high season: arrive in the village early. We were extremely lucky to find a parking space in the big lot Sunday at 10:00. Taking the shuttle bus from the big lot at Pont du Diable would be the next best option, I think.

Look me up if you find yourself in Montpellier proper!

Rtree 0.5.0

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).

It's the imagery, stupid

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)


Re: It's the data, stupid

Author: Paul Ramsey

Same thing holds for the GMaps APIs and Google Earth as a piece of software. The truly innovative thing Google did was not the technology it was (just as in their search business) the business model shift: from direct payment for data to free data with indirect payment via advertising. That their software was pretty cool was icing on the cake, but it was all that free(ish) data that won the day.

Re: It's the imagery, stupid

Author: Matt Giger

It's sad how the geospatial community is so beholden to Google, who can yank the "free maps" rug out from under anyone at any time.

Re: It's the imagery, stupid

Author: Ron Lake

I think it was a convergence of multiple factors - the fact of global data (especially images) - the wars in Iraq on CNN - the realization by Google that people wanted to see themselves and tell stories - and a good execution on the side of the Earth Browser and use of KML for control and visualization.

Since GML has a very different intent, I don't think we would be focused on billions of GML files. GML was never intended for visualization nor browser control (as in "look here") - so is not intended for end users. It is more intended for under the hood plumbing - communicating between databases - transporting eospatial transactions and the like. I think GML has expanded in a number of domains from climate science to city modeling to commercial aviation and even into the bed rock (IETF) of the Internet itself. I don't think its play is over by any means - maybe just at the start. GML and KML play complementary roles and if one wants a GeoWeb that is more "web like", understanding on building on that complementarity is even more important.

Author: Ron Lake

Actually I would not agree with this statement. While one could have written KML in GML (and not the other way around) - that would still be an abberration of the intent of GML. GML is intended to capture geospatial content quite apart from HOW it is presented. KML is all about presentation and browser control. KML is not very useful where we are mainly concerned with machine to machine communication. GML is not all that useful in communication with people. True there was a component called default styling and some good innovations around things like "topology styling" this was never central to GML.

Re: It's the imagery, stupid

Author: Matt Priour

In the same vein, I would really like to see Google Maps API (which the others will follow) read GeoJSON data directly. I know it is an almost trivial javascript processing task to translate those into Google Map features, but having native support would greatly boost the "importance" of that format.

As it is now, clients that want to generate dynamic maps in Google Map have a strong preference for KML or GeoRSS. GeoRSS as a format is a mess since one can use any combination of one of the RSS syndication protocols (RSS 1.0, RSS 2.0, Atom) combined with one of the geometric representations formats. At least Google Maps shows a preference for Atom with GML for GeoRSS but any XML based format can be parsed and used.

Re: It's the imagery, stupid

Author: Eric Wolf

Maybe I'm just a paleo at heart - but I find it more startling that almost all of this imagery is in a Mercator projection (Euro-centric, global north land sizes enlarged, global south diminished, Poles fail). Sure, if you're trying to sail from Spain to Florida, it's a damned good projection. But there aren't many other redeeming qualities.

The GeoWeb is constantly imposing de facto standards that those of us labelled paleo cringe over.

Re: It's the imagery, stupid

Author: Ian Painter

More and more people assume that the GeoWeb is something that only lives in the browser, I don't agree with this and Ron has a point. People 'dis' GML for being too complex for the browser, but its not really designed for that. Whilst B2C is clearly all about the browser, B2B isn't going to happen there and GML is more popular than ever for B2B data exchange. Yes KML solves the 80/20 but don't underestimate how important that 20% can be. In my mind to get 100% GeoWeb you need 80% B2C and 20% B2B. That's KML, GML, REST and SOAP living in harmony.

Re: It's the imagery, stupid

Author: Brian Hamlin - darkblue_b

well, it *is* the imagery, and more ! Twenty-five years ago, a mouse was a specialized instrument, and I recall vividly the PC crowd bemoaning "graphics" as a productivity killer.. User interface, accessibility, ease of adoption, utility, ubiquity and transferability of skills and work product all play a part in the adoption of new technology.

At the

5th International Symposium on Digital Earth

(my first) two years ago, I realized that Geo Browsers was something whose time had come, on a number of levels. I have no qualms about representing KML to the old-timers - and I have gotten some suspicious stares here and there.. but listen to this - its not that I fear our future with computers, at this point I fear our future *without* computers. (apologies to Isaac Asimov)

Re: It's the imagery, stupid

Author: Terry Stigers

@Eric Wolf: Thanks. From one caveman to another.

5 years

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?


Re: 5 years

Author: Ron Lake

I think some of you guys are in dream land. Clemens said nothing surprising (including that it came from Clemens) - no one in the OGC would claim that WxS services meet all requirements - NOR that there has been much progress on making meaningful SDI's. At the same time the problems being dealt with are more than map making and map viewing. What the right mix of architectures will be is not clear (in my view) to anyone. I think there are many notions of the Web and all have a place - whether it is the web of hyperlinked documents or the web of access to services (transactional interactions with security) or the web of real time collaboration (a la XMPP). The OGC problem space is very large (maybe this is a problem ..) and includes things from national security to commercial aviation to emergency response to conventional map making and viewing. I am not arguing AT ALL with the importance of user generated data, nor with neo-things - JUST don't think that such a point of view is not discussed within the OGC or ISO or many other places. Be proud of the neo accomplishments yes - but don't believe they are in such a different world. They are NOT!

KML and links

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.

Place de la Canourgue

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?


Re: Place de la Canourgue

Author: ReLuc

This street has been remade during this year, and it's very nice.

Upcoming Digital Classicist Seminar: Herodotus and space

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.