WD-AccessData-1.0-20140312

[Petr Skoda]

>
> On 19/03/14 06:43 AM, Petr Skoda wrote:
>> So I would add the chapter to both docs stating the BANDNAME is a list of
>> symbolic names (strings) of various filter names (including names of
>> common X-ray channels) and give example of query with BAND=U,B,V or
>> BAND=u,g,r,i,z
>
> I will add the "query by named band" to the use case section of the SIA 
> draft, and I can add a BANDNAME section to the query parameters; the 
> parameter name has to be different from the one that takes numeric values so 
> that it can be described with the right datatype.

Perfect ! Many thanks on behalf of optical centric community ;-)

>
> We cannot feasibly define the list of possible values, so services will need 
> to advertise sane values using some mechanism. As per handling of multiple 
> values specified in DALI, BANDNAME would be multivalued, which means
>
> BANDNAME=u
> BANDNAME=g
> BANDNAME=r
>
> would be the correct way to query for multiple values in one request. So, 
> look for this in the ext WD.
>

IMHO - the typical scientific query will either use the 
BAND=3000e-10/9000e-10    to get anything interesting in optical (well it 
covers as well the usage of typical well known detector - the CCD - other 
"chips" are more exotic and require special treatment in photometry)

or will be BANDNAME=z (or V...)
to get exactly THIS filter for deeper investigation (and then will follow 
Accessdata cutting, or datalink browsing up to the catalogs)
Depends if you are searching ANY photometry of exotic supernova or PRECISE 
GIVEN BAND photometry of known object to compare with catalogue ...

So the single-valued BANDNAME is not so restrictive.



> The service descriptor resource as defined in DataLink can certainly 
> enumerate the sensible values for the BANDNAME parameter for a specific 
> service. We will have to think about where/how a client gets that resource if 
> they want to use an SIA query capability they know the URL for. IIRC, 
> SimpleDALRegExt allows one to describe this as well... TBD.


When I am using our OSPS survey which is still not registered, so I know 
only accref of service, the BADNAME (we call it bandpassID ) is output in 
metadata tables including the map of  spectral ranges (goes from 
static table ) banpassHI and bandpassLO


> Caveat: it may be that some other objection/issue during the RFC/TCG period 
> means we delay including this parameter in 2.0; we are really focussed on the 
> datacube use cases but keeping support/semantics usable for images as well.

> ---
>
> As for AccessData, I understand that some data file formats could place 
> different bands in different fits extensions (eg) and name them, and the 
> "right thing to do" would be to enable a caller to extract that named band 
> from the data file.

> However, there are a lot of fiddly details here and the 
> various kinds of operations one can request and what kind of file have to be 
> thought through. I would prefer to leave this out of the spec for 1.0 and 
> have people just try to implement it and describe the parameter/values using 
> the DataLink service descriptor.

OK - I agree - using datalink it is probably enough for several filters.

> "downstream" from some other request, there is usually ample opportunity to 
> advertise such custom parameters. If we can agree via prototypes using custom 
> params, we can always standardise name and semantics in an updated version of 
> AccessData.  Markus might chime in that we may realise we don't need to 
> really do that last step at all; time will tell.

Well - my guess the Accessdata will probably be focused on ALMA data cube 
as I cannot now imagine other instrument (but I am not experienced in 
radio)  that is producing datacubes consistent with datacube propaganda 
(i.e all axes are densely sampled and and by flattening it every direction 
we get some well-known data product (light curve, spectrum image, ....)

In fact - if the standing highest priority of CSP on datacubes is 
degrading all the transformations, post-processing etc to simple 
cube-cutout (in current versionof SIAP2,accessdata...) - were there 
presented REAL formats of such datacubes (practical examples) - from what 
instruments ?

I have reviewed recently all the presentations from Heidelberg special 
session and its feedback as well as latest CoSADIE Tech Forum in Trieste
and so far I do not see any real datacube - all of examples given (e.g. in
JVO Vissage) were rather "sparse" cubes in energy range and BTW identified 
by the Channel ID ! or some kind of "propaganda" showing different kind of 
products created by reduction pipeline ...but not from real data cube ...

So I agree it is not a need for BANDNAME in Acessdata (but it would be 
nicely symmmeric ;-) with SIAP2

*************************************************************************
*  Petr Skoda                         Phone : +420-323-649201, ext. 361 *
*  Stellar Department                         +420-323-620361           *
*  Astronomical Institute AS CR       Fax   : +420-323-620250           *
*  251 65 Ondrejov                    e-mail: skoda at sunstel.asu.cas.cz  *
*  Czech Republic                                                       *
*************************************************************************
















>
>
>
> -- 
>
> Patrick Dowler
> Canadian Astronomy Data Centre
> National Research Council Canada
> 5071 West Saanich Road
> Victoria, BC V9E 2E7
>
> 250-363-0044 (office) 250-363-0045 (fax)
>

*************************************************************************
*  Petr Skoda                         Tel   : (323) 649201, l. 361      *
*  Stelarni oddeleni                          (323) 620361              *
*  Astronomicky ustav AVCR, v.v.i     Fax   : (323) 620250              *
*  251 65 Ondrejov                    e-mail: skoda at sunstel.asu.cas.cz  *
*  Ceska republika                                                      *
*************************************************************************