WD-AccessData-1.0-20140312

Thu Mar 20 15:20:46 PDT 2014

I just have to add my 2-cents worth and say that I think this is wrong.
The protocol should be as simple as possible, and adding bandpass names is
not.

I don't think the protocol itself needs to be terribly user friendly.
Rarely will end-users write SIAP queries by hand.

If you want a user interface or toolkit that layers bandpass-based queries
on top of the basic protocol, that is fine.  User sees bandpass name = V,
protocol sees a wavelength range.  But everything you add onto the
protocol is another feature the data provider has to implement.

Bob

On 3/20/14 4:59 PM, "Petr Skoda" <skoda at sunstel.asu.cas.cz> wrote:

>>
>> 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                                                      *
>*************************************************************************