WD-AccessData-1.0-20140312

[esm]

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