Martin Daly:

The OGC Geospatial Search Summit was held here at the Atlanta TC yesterday. It was an invitation only, behind closed doors event - grumble, grumble, moan, moan - so I don’t know any details about what went on.

Inside the "Open" Geospatial Consortium there are yet more inner circles?

I don't follow the django-developers list so I might have missed Kevin Teague's great overview and analysis of Python packaging, dependencies, and builds (via Simon Willison). I've referred to setuptools, easy_install, and zc.buildout a number times, but never explained them quite as thoroughly or as well.

Setuptools is the not-quite-standard replacement for Python's distutils module. It has a big set of features, the one of which that helps me the most is versioning of dependencies. I can specify that zgeo.plone.kml 0.2 requires version 0.1 or higher of zgeo.plone.geographer, which in turn requires version 0.3 or higher of zgeo.geographer, and easy_install of the first one of those packages gets the proper dependencies in a cascade. I'm finding this to be better for my sanity than use of the svn:externals property to pull in tagged revisions as we used to do.

Despite what Teague says (update: I misinterpreted, see clarification in comments), I'm finding zc.buildout to be a big help with managing the C/C++ components in Pleiades. Because the GEOS project is -- how shall I say it? -- cautious about bug fix releases, and version 3.0 absent from Linux distros, I'm using Kai Lautaportti's hexagon.recipe.cmmi buildout recipe to download the GEOS 3.0.0 tarball, patch it, compile, make, and make install into an isolated environment for our web application with no more configuration than this:

[libgeos]
recipe = hexagonit.recipe.cmmi
url = http://geos.refractions.net/downloads/geos-3.0.0.tar.bz2
patch-options = -p1
patches =
  ${buildout:directory}/patches/geos-3.0.0-conditional.patch

Works like a charm.

To avoid polluting the Python package index with software of no use outside Pleiades, I've made our own specialized index. Easy_install of pleiades.policy (my obvious cargo cult of Martin Aspeli's example) pulls in pleiades.kml, and then the appropriate versions of zgeo.plone.kml and zgeo.kml. I'm happy to explain how to make such an index to anybody who's interested.

Do read Teague's post to the django-developers list if you're new to the Python software ecosystem, and if you develop any curiosity about how Zope works, read his excellent article about its component architecture.

Technorati is totally busted for doing this kind of analysis. As I wrote on Gorman's blog, almost all of my blog's "authority" comes from automatic linking in the sidebars of several other blogs, blogs which never ever engage mine in any other way. In sum: Technorati's authority is a worthless measure of my blog's interestingness. Look closely at the authority of other blogs and I'm certain you'll see the same pattern.

Update (2008-09-10): It was all for nothing after all, which is good because the last thing we need is more gatekeepers to the blogosphere.

It's great to see others like Vish continuing to write about REST in geospatial (I continue to stalk the term). With a couple exceptions, he's right on. The principles of REST to which he refers are:

• Give every “thing” an ID

• Link things together

• Use standard methods

• Resources with multiple representations

• Communicate statelessly

Do read and recommend Stefan Tilkov's Brief Introduction to REST, from which the tenets above are taken. It's excellent. Vish focuses on the third of these -- standard methods and their use -- and highlights the risks of unsafe GET. Unfortunately he's crossed up the methods a bit. The actual uses of the different standard methods are:

• DELETE: delete a resource

• GET: get a representation of a resource

• POST: submit data to a resource

• PUT: update the state of a resource

There is little lost by thinking of DELETE, GET, and PUT in CRUD terms. One well known use of POST is in resource factories, creating new placemarks or features in a collection, for example:

# Request
POST /features/new HTTP/1.1
Host: gis.example.com
...

[New entity]

# Response
HTTP/1.1 201 Created
Location: http://gis.example.com/features/1
...

Sometimes people refer to this as POST(a) (as in "append"), but POST is more than CRUD's "Create". It can also be used to process data and return it without necessarily creating any new server-side resources. Call this POST(p) (for "process"). Vish is considering POST(p) as a larger volume GET, but that's not quite right because GET requests should be safe and POST requests should be treated as unsafe. Rather than try to switch between GET and POST requests to a single resource (like /features in the example above) depending on the size of the request data, I'd add a new resource to handle POST(p) requests and make it distinct from the ones that are taking POST(a) and GET requests.

Call it a pet peeve, but it's "resource", not "REST endpoint". It's pretty hard to fully grok REST while clutching to the web services endpoint concept.

Update (2008-09-08): I knew Vish had simply transposed entries in his list, and he's fixed up the methods.

I forgot to mention that there is yet a third "GeoWeb": the web of data that links to GeoNames, U.S. Census, etc. While running yesterday I started to sketch out a talk tentatively titled "GeoWeb: fact or fiction?" or "GeoWeb: I want to believe" that could be fun to deliver next year.

I'm going on a trip next month to help my wife with her meetings at Neobiota, scout for next year's sabbatical, and workshop with the Concordia principals. I'd enjoy meeting up with open source GIS, archaeology, or classics programmers along my route:

• 24-25 September: Prague, CZ

• 27-29 September: Colmar, FR

• 01-08 October: Arles and Montpellier, FR

• 12-15 October: London, UK

In other words: Praha, Argentorate, Argentovaria, Lugdunum, Arelate, and Londinium, with a side trip to Aquae Sulis. Looks like I could even bump into Andrew Turner.

On the one hand we have a "GeoWeb" that is a kind of social network, one linked not by hypertext (as are the FOAF and XFN networks) but by Tobler's Law, in which geographically adjacent web resources are your best friends (or mortal enemies). I'm sympathetic to this one, although I often disagree with the style of its evangelists. On the other hand is the "GeoWeb" of spatial data infrastructures, geographic entity registries, W*S, and other elements of an information architecture that is older than and still largely disconnected from the Web. Is one of these the real "GeoWeb", or are they just two parts of the same elephant? Can anyone describe how such a beast works?

I've tuned up the http://gispython.org page; adding links to similar enterprises, highlighting the email list, and exposing project news items. Note that I'm using the Python Package Index's Topic :: Scientific/Engineering :: GIS as the canonical list of open source geospatial software for Python. I hope the update is helpful.

$ easy_install noaadata

Indeed. If the GoogleSat looked closely, we'd discover that many plants were "magnetically" facing East in the morning and West in the evening. See also Occam's Razor.

Kurt, I have in fact seen mapping integrated with Zotero. Shekhar Krishnan used the GeoNames database to locate items by their place of publication in a demo at THATCamp.