[OSGeo-Standards] link relations for features

[Peter Baumann]

On 07/11/2013 09:17 PM, Rushforth, Peter wrote:
>> I
>> don't mind being at the code level for features, because I
>> think we're ready for that. I just thought the coverages
>> discussion still needs to be on a conceptual level.
> Well I was looking at the wiki page regarding wcs 2.0 that Peter
> pointed to earlier, and I could see a number of ways to look
> at that from a REST perspective that aren't too far afield from
> the discussion of features.  Certainly nothing on that page
> currently qualifies the proposed service as RESTful, IMHO.

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


>
>> I like topological relationships:
>> "within", "adjacent", "crosses", etc., but I think we need
>> more than those, but we also need to avoid the slippery slope
>> of moving into the semantic linked data arena.
> The slippery slope to the Fetid Swamps of Unaddressable Names....

nope, not on grids: mathematically extremely well defined.

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


>
>> - I kind of like "near", but don't see how to define it consistently
> It's a good one, I agree.  It should be useful in some situations,
> perhaps a radius search, or equal walking distance search
> etc.

...and many more, in standard remote sensing practice, meteo, aviation, ...you 
name it.

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

cheers,
Peter

>
> A grid cell in a standard tile pyramid can then be a sub-representation
> of the world.  It can have a represnetation as image/png or application/road+xml,
> or for the kook kids among us, application/road+json etc.
>
>
>
>
>
>> On Jul 11, at 2:15 PM, "Rushforth, Peter"
>> <Peter.Rushforth at NRCan-RNCan.gc.ca> wrote:
>>
>>>> I think Peter Rushforth is saying don't worry about it -- let each
>>>> service implementer design their own link structure.
>>> I agree that it needs to be *possible* to retrieve what is referred
>>> to, but I can imagine that how that retrieval is effected will be
>>> different on different servers and server data structures, and the
>>> 'how' will be reflected in the URL structure.  So spelling out a
>>> standard formula for that structure constrains clients to work with
>>> that instead of working with the representation (format).
>> That is the
>>> problem with OGC specs relative to Web architecture.
>>>
>>>> To
>>>> that I say, maybe so, but show me some good strategies and
>> maybe we
>>>> can design some common best practices from there...
>>>
>>> Allan Doyle came up with a zinger way back on geo-web-rest:
>>>
>>> <link rel="east" href="..." type="application/coverage+xml"/>
>>>
>>> I can think of a couple of ways to implement that @href
>> value.  Maybe
>>> spatial folks say "We don't need to be told what east is,
>> we know that
>>> already", but in so saying, you are reversing the contract, you're
>>> telling the server that it has to respect the URL you've coded to.
>>> Let the server tell the client what the URL to the east is,
>> and all of a sudden you've got REST!
>>> Sorry if this takes it back to the "code" level, but that
>> is where the
>>> action is in hypermedia.  At least it's declarative :-).
>>>
>>> Does that make sense?
>>>
>>> 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)