gzipped images in SIAP 1.0 (fwd)

Anita M. S. Richards a.m.s.richards at manchester.ac.uk
Thu May 31 01:56:58 PDT 2007


On Thu, 31 May 2007, Guy Rixon wrote:

> Hi folks,
>
> it seems to me that we are conflating three uses cases:
>
>  1. Service only has compressed images, won't serve anything else, and 
> client needs to be told this.
>
>  2. Images are available uncompressed, but client wants them compressed in 
> delivery to save bandwidth.
>
>  3. Images are available uncompressed, but client wants several images 
> grouped into a zip set for delivery (and
>       possibly compressed in the process).
>
...
> Case 3 is the interesting one. If the SIA is to do it then we need a 
> nice long argument about the details. However, VOSpace is already aiming 
> to do this: it's a planned (optional) feature on VOSpace 1.1 to offer a 
> view of a directory that is a zip of all the files in the directory. 
> We're also planning to allow data staging from an SIA to VOSpace. If we 
> do the latter, then lets use the VOSpace feature to zip the files, 
> rather than duplicating it .

There is a 4th case which I had assumed was essentially non-VO-accessible, 
and that is where the archive contains images (and possibly all sorts of 
other things) in an archive file, e.g. some Spitzer data are gzipped 
tar archives.  Guy's suggestion makes me wonder if VOSpace could possibly 
cope with that although thre would be two other requisits:

a) In order to find the data in the first place, the metadata would have 
to be stored in a database or some other accessible form (I am not sure if 
a fine-grained registry would do).  This buzzes one of the bees in my 
bonnet, that directly interrogating FITS headers is sooo C20; SIAP has to 
grow up and be able to provide a SIAP-like response but based on metadata 
and possibly more complicated processes (at the data provider end).


b) VOSpace needs to be able to decide what the archive format is, what it 
contains and what to do with it - either from metadata or from a listing. 
In particular, it may need to be able to hold files of unrecognised 
type (e.g. log files in WORD!) if these are mixed in with sensible data.

a) is a serious point for now; b) is for VOSpace developers, I think.

thanks

a

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Dr. Anita M. S. Richards, AstroGrid Astronomer
MERLIN/VLBI National Facility, University of Manchester, 
Jodrell Bank Observatory, Macclesfield, Cheshire SK11 9DL, U.K. 
tel +44 (0)1477 572683 (direct); 571321 (switchboard); 571618 (fax).



More information about the dal mailing list