There are some actual architectural constraints that help these "Cloud" applications make rain, not just drizzle. One of them, and the one that has been almost entirely missing in so-called "GeoWeb" applications to date, is hypertext.

Speaking of Atom, Joe Gregorio has recently made a neat video introduction to AtomPub.

Update (2008-08-04): "It's almost as if the [Web was] designed for this stuff."

We're done: http://pypi.python.org/pypi/geojson/1.0. Matt Russell from Sanoodi did most of the coding while I was editing the spec, and Eric Lemoine from Camptocamp helped us crush bugs.

Geojson provides geometry, feature, and collection classes, and supports pickle-style dump and load of objects that provide the lab's Python geo interface. Here's an example of a round-trip through the GeoJSON format:

>>> import geojson
>>> p = geojson.Point([0.0, 0.0])
>>> p
Point(coordinates=[0.0, 0.0])
>>> data = geojson.dumps(p)
>>> data
'{"type": "Point", "coordinates": [0.0, 0.0]}'
>>> q = geojson.loads(data, object_hook=geojson.GeoJSON.to_instance)
>>> q
Point(coordinates=[0.0, 0.0])

The geometry classes interoperate with Shapely via the geo interface:

>>> from shapely.geometry import asShape
>>> x = asShape(p)
>>> x.wkt
'POINT (0.0000000000000000 0.0000000000000000)'

For more details, please see the project page at http://trac.gispython.org/lab/wiki/GeoJSON. Share and enjoy.

I've read the print manifestation of High Country News for years and am delighted to find out today that the new http://hcn.org site is based on Plone. Congratulations Jon and ONE/Northwest.

I've been living off of them for years, but have finally found a use for Python's weak references in my own code.

In Shapely, coordinate sequences, rings of polygons, and members of multi-part geometries provide proxy access to a GEOS geometry structure "owned" by the parent polygon or multi-part geometry. Through their lives they must carry references to the parent like this:

>>> point.coords.__p__ == point
True

so that an anonymous parent object isn't swept up by the Python garbage collector before a hobuism like:

>>> len(polygon.exterior.centroid.coords)
1

executes completely. The implementation is a bit tricky, but a Shapely user doesn't need to think about it: it just works.

Some sub-geometries are expensive enough to create that I've decided to cache them in the parent. Since the "child" already holds a reference to the parent, making a reference to the child from the parent creates a potentially problematic reference cycle. The example below shows cyclic references that prevent Python's automatic garbage collection from freeing objects. The garbage attribute of the gc object below contains references to objects that aren't freed.

>>> import gc
>>>
>>> class ReferencingThing:
...     ref = None
...
>>> gc.enable()
>>> gc.set_debug(gc.DEBUG_SAVEALL)
>>>
>>> for i in range(2):
...     a = ReferencingThing()
...     b = ReferencingThing()
...     a.ref = b
...     b.ref = a
...
>>> gc.collect()
4
>>> gc.garbage
[{'ref': <__main__.ReferencingThing instance at 0xb7dbec4c>},
 <__main__.ReferencingThing instance at 0xb7dbeb8c>,
 {'ref': <__main__.ReferencingThing instance at 0xb7dbeb8c>},
 <__main__.ReferencingThing instance at 0xb7dbec4c>
 ]

A Shapely user demonstrated to me such a bug that was causing geometries to pile up in his application. A weak reference, which is not enough to keep an object alive, does not so block Python's automatic garbage collection. Here is the non-leaking weakly-referencing version of the code above:

>>> import gc
>>> import weakref
>>>
>>> class WeaklyReferencingThing:
...     _ref = None
...     def reference(self, ob):
...         self._ref = weakref.ref(ob)
...     def dereference(self):
...         return self._ref()
...
>>> gc.enable()
>>> gc.set_debug(gc.DEBUG_SAVEALL)
>>>
>>> for i in range(2):
...     p = WeaklyReferencingThing()
...     q = WeaklyReferencingThing()
...     p.reference(q)
...     q.reference(p)
...
>>> gc.collect()
0
>>> gc.garbage
[]

I've also come across a pattern for weak attributes that provides a nicer syntax.

Before I read Bjørn Sandvik's post about semantic geospatial services, I didn't know there was an effort to build bridges from WS-* to the Semantic Web. More significantly, his post is a useful introduction to semantic web issues to GIS users who are more familiar with the concept of services than the concept of Web resources. The metadata in OGC service capability documents (abstract, keywords, etc) are inadequate for the purpose of machine reasoning, and application of RDF and OWL could certainly make it more clear what a service is about.

There is a different effort already underway to semantically link open datasets called "Linked Data" [wikipedia, http://linkeddata.org] or "Linking Open Data" [W3C]. This service-free, or at least, service-agnostic, approach is the one I find more compelling for Pleiades and Concordia. The diagram below (from Richard Cyganiak) shows how geographic data courtesy of GeoNames is right at the heart of the Linked data project.

This graph of data has grown by leaps and bounds since we pitched Concordia. We didn't initially propose to join the Linked Data project, but I'd really like to see Ancient World datasets link themselves together in this way.

body_html_template

This weekend:

OpenStreetMap.org, the free wiki world map is coming to Denver this weekend 19/20th July for a mapping party:

http://wiki.openstreetmap.org/index.php/Denver

More from Peter Batty.

Standards? We've got them. Formats: Atom, JSON, GML, and KML. Application protocols: HTTP and AtomPub. AtomPub provides a solid foundation for the next generation of WFS-like geo-CRUD things and is at the core of major projects at Google and Microsoft. I'm not sure why ESRI wouldn't follow suit. Reinventing it is fruitless; extending it behind the OGC's walls of secrecy equally so. Better to get involved with the Atom community and IETF to solve some of the issues that remain open for us geospatial folks: batching, simplification of media (specifically geospatial content) resource creation (maybe with AtomPub Multipart), and filtering.

Paul writes:

No matter how much we (me) might bitch about OGC standards, they have a huge advantage over DIY, in that they provide a source of truth. You want an answer to how that works? Check the standard.

Who is advocating DIY? The Web and the "Cloud" are standardizing on AtomPub. If OGC standards trump one-offs, IETF Web standards trump OGC standards: they are developed by expert internet engineers with years of hard-earned experience in design and implementation of application protocols; they get attention from engineers across the entire Web, rather than just from narrow domains like SDI; they are -- particularly in the Atom/AtomPub case -- discussed and revised in open forums. There are no artificial barriers to participation; if you're a serious, experienced, thoughtful person, you're in. If you want to understand why a standard is the way it is, you can dig in the Atom or AtomPub email list archives for clues, or you can email the list for clarification. Quality and transparency: that's the advantage of these standards.