The Tyranny of the Round Trip: Work in Sets

So everyone is wondering, as I've been, about RESTful GIS services and deciding that in the end, it's all about letting those precious polygons have their own URLs. Very cool, and I like what I'm seeing in the FeatureServer prototype.

The real trick is touched on here, but I'd love to see some elaboration on the issue. The classic REST discussions talk about lots and lots of people (i.e. the Internet population) dealing in parallel with a handful atomic items (e.g. blog entries, eBay auctions.) But while Internet GIS services might still serve lots and lots of people, they'll also serve thousands or millions of objects. As Paul Ramsey[*] points out it's not fair to hand a WFS client a list of URLs to ten thousand polygons, each of which needs to be retrieved one at a time (open connections and parallel retrieval via HTTP 1.1 notwithstanding).

I think we need a way to define entire sets of resources to work on. Paul suggests tiles, which is eminently sensible. (What are tiles but pieces of a grid-based spatial index, something at the heart of GIS implementations from day one?) FeatureServer and WMS both suggest a query string-based query language (e.g. BBOX=x,y,x,y etc.). But don't we have a few query languages which are already well understood? I'm not sure what it means, but shouldn't we be talking about SQL or XPath in this context?

[*] A cut-paste error in a previous version of this article said Chris Holmes suggested tiles. As a commenter noted, this was actually Paul Ramsey's suggestion. Chris suggests paged chunks — essentially forward-read (paralellizable) cursors.