WD-AccessData-1.0-20140312

[Petr Skoda]

On Fri, 21 Mar 2014, esm wrote:

> Hi Petr,
>
> I fully agree with Bob. Bandpass are more on the side of applications: 
> You can always design a user interface allowing queries by 
> bands/filters,

I am probably extremely blind but I do not see the way how you can query 
by identifiers (bands) that are mapped to interval.
If you claim this show me the method for the client that allows to 
formulate a query for the say V band image.
Your profile service will say somthing like 490/700e-9
The client translates this to BAND call.
It queries the server but as the 490/700 is wider interval and the rule 
claims that even if I have one number all images containing the point are 
returned so by this BAND=490/700e-9 I will get many other bands like 
stromgren y, sloan g etc....

please read again my last analysis.
Simply we need BANDNAME as optional parameter to narrow the posible 
answers.


then go to the Filter Profile Service 
> (http://svo2.cab.inta-csic.es/theory/fps/) to get the lambda_min, 
> lambda_max of a particular filter and then make the SIAP query.
>
> Enrique.
>
> El 21/03/14 03:02, Robert J. Hanisch escribió:
>> I've read all of the email, Petr.  And you are totally missing my 
>> point.
>> And the point that Mark Allen made.
>> 
>> Bandpass names are important, but not for the core SIAP protocol. 
>> They
>> are important for user interfaces.  And that is a totally different 
>> issue
>> that what goes on the wire for a SIAP query.
>> 
>> Bob
>> 
>> On 3/20/14 7:14 PM, "Petr Skoda"<skoda at sunstel.asu.cas.cz>  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 think you did not see the previous discussion - WHY the bandpass 
>>> names
>>> IS important:
>>> 
>>> 1) It is the primary information written in FITS header - the 
>>> provider of
>>> the original data (e.g. camera acquisition system) always uses some
>>> simplified names, lists ....
>>> 
>>> 2) The names of particular filters MAY NOT be mapped precisely to 
>>> the
>>> filter names - it is spcific to every project and there is not 
>>> unique
>>> solution how to map it - but of course the filter profile service
>>> used in VOSA etc. tries to identify the most commonly used.
>>> 
>>> 3) The scientist know MUCH BETTER what kind of filter the 
>>> particular
>>> survey (say resource) uses then the VO data provider can describe 
>>> in
>>> metadata (and if he wants to be precise it requires a lot arguing 
>>> with
>>> the
>>> expert in e.g. photometry - moreover some filters have 
>>> discontinuity
>>> (they
>>> absorb) in certain regions so the only physical identification of 
>>> it is
>>> the plot of transmissivity.
>>> 
>>> 4) It may be even worse - the instruments with many filters may 
>>> such that
>>> are not described well by simple names. it may be e.g. Hbeta filter
>>> centered on some wavelength coresponding to the given redshift of 
>>> this
>>> line. Some documentation of filters mentions only central 
>>> wavelength not
>>> min and max range - Some state central wavelength and FWHM or 
>>> half-width
>>> ...
>>> 
>>> 
>>> So it is almost impossible for the (usually informatician with 
>>> basic
>>> astronomical background) VO data publisher to find the exact 
>>> mapping
>>> required here.
>>> And how will you distinguish two different images the filters of 
>>> which
>>> have the similar wavelegth range or central wavelength - e.g. 
>>> Johnson V
>>> and Stromgren y .....?
>>> 
>>> BTW - the polarisation states are as well completely wrong and they 
>>> should
>>> d not be listed as Q,U,V,I as none of this value is obtained 
>>> separately
>>> and you cannot use it for query - but you may want to extract them 
>>> in
>>> Accessdata - see the presntation of F. Paletou in Heidelberg.
>>> 
>>> But it is more practical to refer to obseravtion with certain 
>>> orientation
>>> of filter (half-wave plate) as e.g. U and to the one without 
>>> polariser as
>>> I....
>>> 
>>>> 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.
>>> He has to implement much more complicated translation to wavelength
>>> ranges
>>> (very artificial and imprecise ) just to satisfy the 
>>> characterization.
>>> But here it may be considered as the rough orientation value and it 
>>> is
>>> legitimate use it in (very rough) discovery query to get at least
>>> something.
>>> But if the scientist need EXACTLY what he wants, there is no way 
>>> how to
>>> do
>>> it in a unique way.
>>> 
>>> 
>
>
> -- 
> Enrique Solano Márquez
> Spanish Virtual Observatory
> Centro de Astrobiología (INTA-CSIC)
> Campus Villafranca.
> P.O. Box 78
> 28691 Villanueva de la Cañada
> Madrid, Spain
>

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