[OSGeo-Standards] Was: "file" formats. Is: GeoWeb

[Baumann, Peter]

- well, a coverage is a collection (set) of features, with some particular constraints (gridding, same feature ("pixel") type). This set and its components reflect phenomena, they are "real", a "resource"
- a tile is an artifact resulting from performance optimization. It is not reflecting anything relevant in reality, so it is not a "resource". And on coverages specifically, tiling for clients will fail miserably.
- REST and http discussion is good on the link / graph level of the Web, but has no advantage for discussing coverage handling and its internals. Wrong paradigm.
- even more so when it comes to service functionality. This is all to high level - let's get concrete: we need paradigms to express subsetting, NDVI computation, climate anomaly detection, etc. 
- <advertisement>With the WCS 2 suite we have a rich, flexible toolkit for describing, querying, analyzing coverages independently from their encoding format, and independent from KVP, SOAP, REST.</advertisement> ...Anything you are missing in WCS? Please let me know, I'm sure there is more that can be done on it.

   Peter

--
Dr. Peter Baumann- Professor of Computer Science, Jacobs University Bremen
  http://www.faculty.jacobs-university.de/pbaumann
  mail: p.baumann at jacobs-university.detel: +49-421-200-3178, fax: +49-421-200-493178
- Executive Director, rasdaman GmbH Bremen (HRB 26793)http://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)




________________________________________
From: Raj Singh [rsingh at opengeospatial.org]
Sent: Thursday, July 11, 2013 8:28 PM
To: Rushforth, Peter
Cc: Baumann, Peter; standards at lists.osgeo.org
Subject: Re: [OSGeo-Standards] Was: "file" formats.  Is: GeoWeb

On Jul 11, at 2:15 PM, "Rushforth, Peter" <Peter.Rushforth at NRCan-RNCan.gc.ca> wrote:

>> I think the
>> biggest problem I have with designing RESTful resources
>> around coverage data is the fact that most coverages
>> represent natural phenomena that vary continuously across the
>> earth's surface (or atmosphere, or sub-surface). This means
>> that the actual cell values are only approximations of what
>> is expected to be observed in nature.
>
> Can a coverage be tiled?  Can you reproduce a coverage data structure by
> re-assembling tiles?

This is exactly the problem. I think coverage loses meaning when it's tiled. It's like graphing a wavelength equation, then snipping out a part of the graph, then trying to recreate the original equation with only that part of the graph. There will probably be many equations that fit the graph. I suppose you could avoid this problem with coverages by maintaining, e.g., something like a "link=source" to the original coverage in the tile data. But I also don't have the professional background in the sciences that use coverages to know if this would be useful.

>> This is why I have a
>> hard time calling anything a resource other than the full coverage.
>
> But, a FeatureCollection is also a Feature, right?  A collection
> can have in principle an unlimited number of features.   A representation
> is just that: a representation of the resource.  Not the whole thing, necessarily.
> Not the beginning of it, nor the end of it necessarily.  If one
> can figure out how to provide access to a part of a resource,
> and potentially link to other parts of it e.g. link at rel="next".

No problem with anything you say here. Actually I emphatically agree the only problem is figuring out those pesky link relations!