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 (?)
alt 3: multipart MIME, see RFC 2112 at
http://www.mhonarc.org/~ehood/MIME/rfc2112.txt
pro: standard
con: ?
...a few late-night thoughts.
regards,
Peter