WD-AccessData-1.0-20140312

[Douglas Tody]

Good point Petr.  Sometimes image bands have names but are not easily
characterized numerically (hence the more complex approach taken earlier
with SSA).

> but letters and devise the way how to request multiple ranges => BAND=B,V,R

Some folks don't like list-valued parameters (likewise POL=I,Q,U), but
it does seem more natural and convenient for the client doesn't it?

> meters explicitly) - but how the user will know the units of original data?

By a prior queryData and/or getMetadata.  In particular, for most
advanced image access via accessData, one will need to know the image
geometry and WCS, which will be returned with getMetadata (which is not
yet fully defined, and requires more work on the Image data model).

Several people have expressed interest in image sections as in IRAF,
CFITSIO, etc.  This is a pixel space expression such as "[101:105,*]"
(spatial cutout of a 3-cube), "[*,5,*]" (plane 5 of a cube), etc.  In
general, WCS-space and pixel-space operations are equally important and
the client might prefer either.  AccessData is WCS-space initially as we
already have to support this for the discovery query, whereas supporting
pixel-space will require that we first prototype getMetadata and image
section support.  Ultimately we need both as well as WCS-transform and
functions.

 	- Doug


On Thu, 13 Mar 2014, Petr Skoda wrote:

>
> Hi all,
>
> I am trying to follow the discussion about SIAP multicube and all this stuff 
> but so far I did not have time
> to think about the details.   But here on the draft I see already one 
> critical problem: Namely the BAND parameter.
>
> Its nice to define the access in terms of energy and units (in SSA we have 
> meters explicitly) - but how the user will know the units of original data? 
> Will there be something like two-way negotion like in S3 theory protocol ?
>
> But the most complicated is a question - how to extract from "datacube" 
> consisting of stack of multi-photometry images the image in "V" filter.
> In SSA is very convenient the usage of BAND=V. In principal (and it is the 
> way how DaCHS makes it) you can convert the filter name to characterization 
> values of spectral range and localization using some table - but in fact the 
> correct way would be the filter service ....
> But the opposite way is more difficult - and what if the filters overlap?
>
> I would suggest to allow it for Access filter as well - so not only values 
> but letters and devise the way how to request multiple ranges => BAND=B,V,R
>
>
>