2010 (old posts, page 8)

Related blogs and feeds

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.

Visualizing Pleiades imports

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.

GDAL Web driver

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.


Re: GDAL Web driver

Author: Christopher Schmidt

Hey, I recognize some of that text.

I'm not really sure how your second quote addresses my actual "I don't understand" section (which is terribly worded, bad on me for writing under the influence of sudafed). The HTTP spec surely describes byte ranges as meaningful, but does that mean that accessing things via byte ranges is RESTful?

Re: GDAL Web driver

Author: Sean

I should edit my post to make it clear that the second quote isn't meant to be a rebuttal or counterpoint to your first one. Partial representations aren't part of "textbook" REST, but aren't inconsistent with it.