Re: ReW: [WCS.RWG] GetCoverage requests that produce multiple documents.

• To: Steven Keens <keens@xxxxxxxxxxxxxxxx>
• Subject: Re: ReW: [WCS.RWG] GetCoverage requests that produce multiple documents.
• From: Peter Baumann <p.baumann@xxxxxxxxxxxx>
• Date: Fri, 29 Jul 2005 00:04:48 +0200

Hi Steven,

(I add the galeon folks, as related issues have been discussed there too)


Steven Keens wrote:

Peter,

I remember your presentation and found it extremely interesting. I just reviewed the slides you posted onto the portal (http://portal.opengeospatial.org/files/?artifact_id=11181) and I really believe that your proposal is where we need to be headed with the WCS. However, I was wondering how it could solve the problem of being able to return multiple documents/coverages/files from one request to a WCS?

frankly, it doesn't solve the technical issue of multi-responses, it just eases 
to describe them. I found Weisheng Li's pointer to WSRF very interesting, I 
want to look into it further. Aside from that, the tar/zip wrapper approach 
looks best to me.

I'm going to put your examples into my own words. Hopefully, what I write correctly reflects what you have written. If not then please feel free to correct me. I won't take it too hard :-)

same from my side - WCPS concepts deserve a lot of improvements & issues 
clarification, I'm most happy about all input. :)

1) struct { A.band1, B.band1, C.band1 } Produces one coverage with three bands (measures?) from three coverages each containing one band (measure?)

    Coverage A with measure band1
    Coverage B with measure band1
    Coverage B with measure band1

How is this coverage returned to the client? Could I do something like: tiff( struct { A.band1, B.band1, C.band1 }) If so then this still only produces one file.

that's right: one TIFF file with three bands. was just added to contrast it to 
the other case:

2) tiff( A.band1 ); tiff( A.band2 ); tiff( A.band3 ) This one produces three tiff files where each file has one band. Correct? If so then how does the client get those three files. HTTP is limited by the fact that every request must have only one response. To be able to return those three files the server has to package them up somehow. We must also be able to answer questions like which tiff file contains A.band1? These are the problems I'm trying to solve.

you are right again. In the special case of TIFF you can have a multi-image 
file which does the trick. However, we maybe should not rely our concepts on 
particular features of particular data formats.  The file set description you 
mention is given by the sequence in the request: the first file contains band1, 
etc. Hence, the transmission technique must be able to model ordered lists, or 
a naming scheme for the files is introduced (this is an ad hoc thought, feel 
free to fire on it ;-) ): tiff( A.band1 ) as band1.tif; tiff( A.band2 ) as 
band2.tif; tiff( A.band3 ) as band3.tif What I like is the idea that the 
request not just specifies the result contents, but also its structure.

If I understand correctly then example 2 probably best reflects the problem I'm trying to solve. 3) netCDF( abs( tempRed - tempNir ) / ( tempRed + tempNir ) ); Your third example produces two files: a CDL file and a NC file. The same questions as in 2 arises. How are these two files packaged so that the server can send them back to the client.

right, again.

BTW, another case is output mosaicking: "give me coverage C, in blocks of 1000x1000 
pixels, each one in a separate GeoTIFF file".

So let me try to phrase the issue in my words:
We need
- a mechanism to request results consisting of more than one coverage object 
(like mosaicking, not yet talking about CDL/NC in netCDF).
- a mechanism to transport a multi-part result
Maybe it's fruitful to have both issues separated.
For the first, WCPS is intended to contribute. For the second, I see (please 
revise/extend):
alt 1: wrapper (tar/zip)
   pro: straightforward
   con: singleton, not streamlined with other standards facing the same problem
alt 2:  WRFS (?)

   pro: standard
   con: ?

...a few late-night thoughts.

regards,
Peter