[OSGeo-Standards] RESTful WCS protocol binding

[Peter Baumann]

On 07/12/2013 02:55 PM, Rushforth, Peter wrote:
> 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) :-).


hm, this all I somehow cannot understand, too high level.
To reiterate,
- what exact element in WCS do you have in mind?
- what REST rule does it violate?
- what is the authoritative link to check back and learn?


>
>>
>>>> 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.

I suggest to look into the coverage & WCS specs, all that is clarified there.


>
>
>
>>>> 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

looking forward to seeing the earth specified. In the meantime, I continue with 
my humble work on WCS.

cheers,
Peter


-- 
Dr. Peter Baumann
  - Professor of Computer Science, Jacobs University Bremen
    www.faculty.jacobs-university.de/pbaumann
    mail: p.baumann at jacobs-university.de
    tel: +49-421-200-3178, fax: +49-421-200-493178
  - Executive Director, rasdaman GmbH Bremen (HRB 26793)
    www.rasdaman.com, mail: baumann at rasdaman.com
    tel: 0800-rasdaman, fax: 0800-rasdafax, mobile: +49-173-5837882
"Si forte in alienas manus oberraverit hec peregrina epistola incertis ventis dimissa, sed Deo commendata, precamur ut ei reddatur cui soli destinata, nec preripiat quisquam non sibi parata." (mail disclaimer, AD 1083)