Ed, you forgot an event. Down here, in the grassroots.

Update: of course you can't get any more grassroots than OSM.

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.