[OSGeo-Standards] RESTful WCS protocol binding

[Rushforth, Peter]

Hi Peter,

> 
> hm, according to our discussion thread I see nothing that 
> would disqualify :) 

> Please let me know the exact definition 
> part which you consider violated, and where I can look up why 
> it's violated. This helps us in improving standards.

I agree! 

REST is defined by four interface constraints: 
 * identification of resources; 
 * manipulation of resources through representations; 
 * self-descriptive messages; and, 
 * hypermedia as the engine of application state <-from what I can tell you're not following this one

but I see you've got potential there, since you are referencing URI templates,
which if communicated in responses can be considered a form of hypertext.

Not far off, but REST is constraint-based (checkboxes), not option-based (radio buttons) :-).

> 
> 
> >
> >> I agree with everything you write below, but I don't think
> >> "east" is a useful relation. Half the world is east of any
> >> given feature, right?
> > If you don't have such a relation, how does the client know how
> > to pan?  (Hint: you can't tell me what the URI looks like).
> 
> because every pixel has a well-defined topological 
> neighborhood (on raster 
> level) or geographic relation (on geo semantic level).

That is true, and it is that shared understanding of "east" which
allows client and server to skip the specification of the URL structure,
and rely on the clients knowledge that a request to the URL marked "east"
will be a spatial extent, when the map is oriented north-up, somewhere
to the right of the current response.



> >
> >> Here are some
> >> other thoughts:
> >> - I don't see how a "next" relation helps with geodata
> > That's easy.  If a FeatureCollection has 1,000,000
> > features in it, do you want to try to parse the whole thing in
> > one request/response? OK, how about another zero?  Maybe you do,
> > but you shouldn't *have to*.  That is what gives GML a bad name,
> > IMHO.  Sorry Ron.
> 
> well in the world of image services this is day2day practice 
> since decades:
> - give me 1 megapixel (1000x1000)
> - give me the NDVI of this
> - give me the max/min of that megapixel
> 
> so, yes, I want that, and even more: "scan 1,000,000 images, 
> give me the ones 
> with less than 30% cloud".
> It's the server's business to do this efficiently for me.

There's no doubt computers are getting faster!  Maybe quantum computers
will allow us even to process XML over the Web ;-).



> 
> >
> >
> >> - I like the idea of using a standard way of gridding up the
> >> world so that our feature collections can be all features in
> >> the grid cell, and you can use a "next" relation within the
> >> grid cell. The grid gives us a standard way of linking across
> >> data sets also.
> > The "world" is also a resource.  Maybe it is *the* resource in geo,
> > and representations of it contain links to sub-resources, all with
> > geospatial (among perhaps other) representations available.
> 
> not sure this level of abstraction is leading immediately to 
> user-oriented 
> implementations :)

The point is that on the Web, as in mathematics and life, the resource
is not the representation.  The Web is architected to enable this model,
and allows us to model 'things of interest' whatever those may be.
For the purposes of discussion in the geospatial realm, maybe we should be starting
with some concrete feature, like the earth, for which we can specify
media type characteristics.

Cheers, and thanks
Peter