Update: More from Peter Batty, John Spinney, and Chris Haller.

While some topics are being hashed out on our Google page, the actual schedule remains to be decided Saturday on-the-fly. My ultimate goal is to help merge all the cool agendas people bring, but I have a few of my own.

Bank on me to mount my RESTful GIS hobby horse and start tuning up my arguments for the FOSS4G conference. I'd also like to help lead discussion about non-traditional data models and storage in the context of my Pleiades site. I know that I'm not the only one with data that doesn't fit in a single feature table. Maybe this could potentially lead into a data management or stewardship (a hot topic recently) session.

I'm looking forward to reducing my ignorance about mobile GIS and location-based services. I missed the Churchill navigation system demo at a recent Front Range Pythoneers meeting, and hope to get one at the GeoSummit. I hear they're making great use of Google Earth at the NSIDC, and I expect that will be a part of at least one big virtual globe session.

I'll see you there. Saturday, 16 June.

Mike Shaver's post about rich internet applications, with the great quote

If someone tells you that their platform is the web, only better, there is a very easy test that you can use:

rippled around last month, and I was reminded of it again when I viewed the Rome Reborn 1.0 flash movie (via The Stoa Consortium). It's slick, no doubt, but you can't really call it a web site. This manifestation is practically unusable. Flash movies should complement -- never replace -- addressable, linkable, bookmarkable, and programmable web sites.

See also Daniel Cohen and Roy Rosenzweig in their book Digital History.

So, there's this meme that you have to be able to enumerate your domain's pain points. For Python and GIS/neogeography these include:

• the standard library's xml.sax and xml.dom. ElementTree and lxml are the way to go.

• unittest. I wrote a pile of unittest modules for MapServer's SWIG bindings, aka mapscript. So many that it'll be a while before I slide out of the top 5 all-time MapServer LOC. The tests never really caught on with other developers. The generic xUnit style didn't help seasoned developers cross over, and doesn't help explain usage to new users. These days, I'm much happier using doctest. It's been hard for new Python programmers to find good advice on the right testing framework, and the consequence for open source Python GIS is that people don't write tests.

• distutils and setuptools. Python's packaging and distribution story is too arcane. Yes, this is intricate stuff, but it needs to be easier. People developing open source GIS for Python rarely bother to figure out the old distutils setup, let alone eggs.

• str and unicode. Python's unicode story is not bad, and will be even better when unicode is always on.

• function names. This is a small itch (caused by exposure to Ruby), but I'd love to be able to use self-descriptive Python APIs like:

  >>> if polygon.simple?      # instead of isSimple()
  >>> polygon.rotate!(angle)  # rotate self, not a copy

• mapscript.py and gdal.py. Many users come to Python via MapServer and GDAL, which is unfortunate because those applications have terrible, un-Pythonic APIs (that ripple through the open source GIS community) and have created the impression that Python is just a binding for C/C++ code.

Shapely is to be an LGPL-licensed replacement for PCL's cartography.geometry package. Like its ancestor, it will provide familiar geometry classes with all the spatial operators of GEOS. When done, cartography.geometry can be rewritten as a lightweight layer over the new code. Additionally, Shapely will have a more Pythonic serialization story, and plug and play with other powerful Python packages using the Numpy array interface. Last, but not least, Shapely will be much easier to build, install and deploy.

Shapely serializes and deserializes using the familiar idiom from the pickle module. Here's a pickle stream example (an actual project doctest):

>>> from shapely.geometry import Point
>>> import pickle
>>> point = Point(0.0, 0.0)
>>> data = pickle.dumps(point)
>>> pp = pickle.loads(data)
>>> pp.equals(point)
True

This isn't about Python after all.

One of the fun side-effects of digging into RESTful GIS architecture is finding common ground with people like Keyur Shah. A hardcore Java programmer employed at ESRI and a open source Python hack should be diametrically opposed. Maybe we still are, just converging on some of the same design principles from different directions.

I've been sketching out an alternative to the OSGeo Tiled Map Service for most of the spring. Not yet another standard, but an example of another, more RESTful way of providing tiles to a mapping client. I'm just going to scrap it now and point you to Chapter 5 of RESTful Web Services by Leonard Richardson and Sam Ruby.

The OSGeo TMS is composed of a general family of algorithms, parameterized by map scale and image coordinate origin, for finding the URL of specific map tile. The basic algorithm is coded within web map client applications, and the clients query a service for an enumeration of all the variants of the algorithm that it implements. The client application selects the optimal variant of the algorithm, and executes it to obtain the URIs of the map imagery it needs. The advantages of TMS over an OGC WMS are that map tile resources can distributed over any number of servers (it scales, trivially), and that clients can leverage the caching mechanisms built into the Web (If-Modified-Since and ETag, also known as conditional GET) to conserve bandwidth and improve performance.

The service outlined by Richardson and Ruby has all the advantages of TMS and one more: there's no requirement on map clients to possess or execute tile-locating algorithms. A request for imagery to such a service would return a document containing:

1. a link to the central map tile

2. links to that tile's neighbors

A map client would simply GET and render the central tile, and then traverse the links to build out a full map mosaic.

This is rather a lot like the RESTful feature services I wrote about in April: simply elegant, but also a hard sell. Mainstream GIS folks recoil in horror at the thought of relying on link traversal to render their maps. I think this is partly based on experience with under-performing OGC WMS instances, partly on discomfort with anything too different than desktop architecture (web-as-filesystem), and on the fact that there are no web-traversing map services in the wild. We're also following Google's lead in this area because its hard to argue with the success of Google Maps. Richardson and Ruby gloss over the fact that Google's map tile service is much more like the OSGeo TMS than their ROA (Resource Oriented Architecture) maps.

Lots of good stuff in the book. I hope the librarians out there appreciate my link to WorldCat instead of Amazon ;)

  <a class="nw-neighbor" ...>...</a>