WD-AccessData-1.0-20140312

[Patrick Dowler]

Fair enough. This is why I said I "can" add the parameter and added the 
caveat that objections or complications would most likely delay the 
inclusion of this to a later version. We do not want to delay or be 
sidetracked from the core use cases.

At some point, we will have to draw a line and postpone some things. 
However, the discussion is useful because I think we did conclude that 
it is a different parameter with different datatype (another hot-button 
issue) which means we *do* know that treatment of numeric BAND and 
enumerated BANDNAME are independent and the latter could be added later 
without effecting BAND. That is good to have determined now.

Pat

On 20/03/14 03:20 PM, Robert J. Hanisch wrote:
> 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                                                      *
>> *************************************************************************
>
> .
>

-- 

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)