REST Can't Handle Rasters and Coverages?

That's what Raj Singh seems to be saying here:

For example, most of the REST material I've read treats images as indivisible, binary resources. This won't work in the geo field, where images are in the gigabyte and terabyte range and you've got to design services that provide access to portions of those images. However, aside from imagery I don't see much of a problem with using a resource-oriented approach to information access. In fact, in the sensor web arena I think a REST approach makes a ton of sense.

Raj, you're reading the wrong material. No REST architect accepts that the image "file" is the only possible resource. If I had a global sea-surface temperature coverage resource at /sst/current/, I could easily treat individual pixels as resources of their own: /sst/current/{pixel},{line} is just one possible URL form. I could even interpolate to fractional positions within the coverage, or do lat/long: /sst/current/{latitude},{longitude}. Modes of an empirical orthogonal function decomposition (hot topic when I was in school) could be modeled as resources: /sst/current/eof/{n}. Simple temperature slices are another possible set of algorithmic resources: /sst/current/?tmin=28 would be the warm waters that spawn tropical storms. All of the above are RESTful and no client needs to know whether I have a single file or multiple databases backing the resources. Furthermore, a resource-oriented approach scales better than an endpoint-based protocol like WCS. As the number of resources grows, you simply spread them over more servers like Google has done with its Earth and Maps tiles.

There may be geospatial problems that REST can't tackle, but access to arbitrary regions of a coverage is not one of them.

I'm also a bit disappointed to read this:

After all this [research], I think I know what's going on, but I don't think there's any one clear explanation (despite some nice pieces of the puzzle here [1] and here [2]) available, and there has certainly been little effort to analyze the REST architecture in relation to geographic information systems theory, so that's what I'll try to do now.

Of all the great posts and email threads which break GIS web services down in RESTful terms, he picks that muddled Directions article and another that only quotes one of my emails? This trivializes the geospatial community's conversation about REST, one that has been enlightening and amusing us for about a year now. The fact that there will be three REST related presentations at FOSS4G hints at the maturity of the topic.


Re: REST Can't Handle Rasters and Coverages?

Author: Frank Steggink

Sean, although I appreciate, almost even admire, the work you're doing on REST, I would like to say something. Yes, you don't know me, and yes, you might not like it what I'm going to say, but like you, I'm just using my right to speak freely. It sounds like you're on a crusade again! Can you please tone down the posts? This way it sounds like you're far in the "glass half empty" camp. I, on the other hand, find it very encouraging that Raj is posting on REST. That indicates that not only the OGC members (like Ron Lake, etc.) follow REST with much interest, but even the OGC itself. So, all the nudging you did (and do!) shows off its value! Yes, Raj might have better linked to other posts than the ones he did. Yes, he might not understand REST as much as you do. But guess what, that is true for 99% of the people. Everybody makes mistakes, doesn't understand things the right way immediately. (I'm also struggling with understanding REST, and its implications on the geo web, and it is not that easy.) The reason: we're coming from a different mindset (freely speaking on behalf of Raj as well), and change is always hard. You are one of the guys leading the pack. But all that endless one-sided bickering costs a lot of energy, which can be spent much better. Making nice demo's for instance, writing some good intro's (especially on the geospatial field), thinking how you would implement WFS in a RESTful manner. And above all, use your energy to use the momentum the OGC is showing with regard to REST. I would rather prefer to read and even engage in constructive dialogs and interesting discussions with you, with Raj, with others. So, please get over whatever raises your hackles at the OGC, and go into a more cooperative mo(o)d(e). Spicey food tastes great, but too much just burns your mouth. Frank

Re: REST Can't Handle Rasters and Coverages?

Author: Sean

When our industry leaders speak from authority and get it wrong, I'm going to say so. I try to keep it above the personal level (call me on this if I slip), but I'm not going to sugar-coat it. Sorry. At any rate, it would be a big mistake to tune out REST just because of one shrill voice. I don't think anybody at the OGC will. Now, back on topic.

Re: REST Can't Handle Rasters and Coverages?

Author: Jason Birch

I can't really say that I know Sean either, and I certainly don't always agree with what he posts or his tone - I'm more conciliatory myself. However, I see immense value in a strong critical voice, especially considering how disruptive REST is to traditional GIS. If the voices of folks (like Sean) who have a clear vision of how things like REST and AtomPub can work in our field are ignored, then we are doomed to a set of officially-sanctioned sub-optimal standards. Which will in turn be ignored as mainstream geospatial rolls over top of traditional GIS without even feeling the bump. Jason

Re: REST Can't Handle Rasters and Coverages?

Author: mpg

Perhaps like Raj, I'm still trying to get my head around the idea of specifying arbitrary BBOXes for image requests in REST format: seems utterly uncacheable, and thus against one of the REST goals. That aside, though, I see no problem with using REST for images. Scales/resolutions, reprojections, band slicing, etc, all seem to work perfectly nicely in the whiteboard-level thoughts I've been having. I'd be perfectly happy to see all coverage data presented as a REST-service-of-tiles instead of the montage of monolithic files we deal with today. The backend storage might be file-based or indeed a number of other options (including wavelets), but key point is that the lives of clients just gets easier as you mandate simple tile schemes. -mpg (totally not speaking for my employer...)

Re: REST Can't Handle Rasters and Coverages?

Author: Raj

If a client--such as a Web browser--wanted a 500x500 pixel image, would this require 250,000 URL requests? Or would image requests be more like queries, and look very much like WMS does now, but every pixel would have a canonical URL if you really needed it?

Re: REST Can't Handle Rasters and Coverages?

Author: Sean

I'm just showing off the freedom we have to model coverage resources. The resources that you actually expose should be the ones that make the most sense for your application.