My announcement of the Shapely 1.2.4 release was the last such regular release announcement on this blog. Every Shapely, Rtree, spatialindex, Geojson, and OWSLib release will now be announced at http://gispython.org/ [feed] in collaboration with other developers. I'll continue to write about especially notable ones here.

The same goes for my work on Pleiades: my news items will appear along with those of other users and administrators at http://pleiades.stoa.org/news/aggregator [feed]. Some portions or summaries of them will be featured here from time to time.

I've just completed the first round of data imports into Pleiades. We've passed the 25,000 milestone and are moving on to improving the spatial indexing and visualization of the places and locations.

I'm experimenting with using Polymaps to see what we've imported, clustering by the grid cells of our map directory sources, and appreciating the simplicity of the Polymaps approach. I can see using it in the small maps that accompany each Pleiades place. A good "web-scale" basemap for the ancient world would be more appropriate than the Flickr tiles, but I'm enjoying the boundary-free geography of the Flickr layer. Like Pleiades and the R-Tree server I'm writing, Polymaps speaks GeoJSON, the little format that could.

Network file systems or web services got you down? Sidestep them with a lightweight and high performance GDAL filesystem implemented on HTTP:

People sometimes talk about “RESTful” services on the web, and I’ll admit that there’s a lot to that that I don’t really understand. I’ll admit that the tiff format is not designed to have HTTP ‘links’ to each pixel — but I think the fact that by fetching a small set of header information, GDAL is then able to find out where the metadata is, and request only that data, saving (in this case) more than a gigabyte of network bandwidth… that’s pretty frickin’ cool.

Part of what makes this work is the Web's built-in support for byte range requests and partial representations. See RFC 2616 section 14.35.1 and HTTPbis part 5:

Since all HTTP entities are represented in HTTP messages as sequences of bytes, the concept of a byte range is meaningful for any HTTP entity.

Make a small byte range request for TIFF metadata so you can map pixel and row (and maybe pyramid depth) to an entity byte range and then request just the right subset of the image.

For what it's worth, there's a W3C Media Fragments Working Group with a mission of making image subsets more addressable.