Axes in Obscore: Velociity axes
Jose Enrique Ruiz
jer at iaa.es
Mon May 4 10:56:17 CEST 2015
Hi all
thanks for the effort in adding gas velocity info into obscore.
in case it helps, I would add info relating to the transition line causing
the redshifted line-emission, i.e. some users maybe interested in objects
emitting HI21 cm line while others could be in objects emitting in CO 3mm
transition. While I think this is somehow covered in d_restfreq, and
clients-apps could make a kind of lookup resolution in transition_name <->
d_restfreq, I guess a transition_name column will help.
Cheers
---
Jose Enrique Ruiz
Instituto Astrofisica Andalucía - CSIC
Glorieta de la Astronomía s/n
18009 Granada, Spain
Tel: +34 958 230 618
2015-04-24 17:18 GMT+02:00 Louys Mireille <mireille.louys at unistra.fr>:
> Dear Marco , dear all,
>
> Thanks for highlighting the dopplershift use-cases .
> I have a question :
> could a dataset have both a spectral axis and a doppler axis at the same
> time described in the wcs axes?
> I wonder whether we may have only one of the two , either , the spectral
> values , and then em_* metadata family columns suffice in Obscore, or
> doppler /velocity values , and then em_ucd ='spect.DopplerVeloc' , and
> only extra metadata like:
>
> d_restfreq
> d_refpos
> d_definition
>
> are needed.
>
> Examples with FITS files would help , either for a simple add_on in
> ObsCore , of for a deeper exploration of which WCS keywords are needed.
> Thanks , Mireille.
>
>
> Le 24/04/2015 10:15, Marco Molinaro a écrit :
>
>> Hi Mireille, Hi all,
>>
>> if I get it right, that table comes out of obscore's use case A.3.2.
>> It seems to me that my case takes something also from the A.3.4 (because
>> my
>> users want to see RESTFRQ reported, even if it's not in the FITS header
>> explicitly) and also the cubes we're dealing with span both the 3 axis
>> and
>> 4 axis cases (even if the 4th currently is just degenerate and not
>> considered in the usage of data).
>>
>> Anyway, that said, I think that d_
>> ucd
>> unit
>> definition
>> min
>> max
>> would suffice. I think reference_position will be GEOCENTRIC in my case,
>> but I have to investigate.
>>
>> In some sense the above listed are enough to describe the data for the
>> needs of the community I'm serving, I'm wondering if it's ok also for a
>> generic VO user searching for datasets that include the ones I (will) have
>> in place.
>>
>> As for the units specification Arnold pointed out: my user need it not in
>> search phase (the unit there is fixed by the service interface, which I
>> think will always be the case in VO) but it wants it in the response to
>> ease the work of the client app. So probably my use case does not put
>> requirements on this issue.
>>
>> Cheers,
>> Marco
>>
>> ps - to be honest all my use case works in GLON,GLAT instead of RA,DEC,
>> but
>> that's trivial.
>>
>>
>> 2015-04-23 17:25 GMT+02:00 Louys Mireille <mireille.louys at unistra.fr>:
>>
>> Hi Marco , Hi all ,
>>>
>>> I think your use-case corresponds to the current questions we have about
>>> axes description.
>>>
>>> I proposed together with Doug Tody , some way to describe the velocity
>>> axis, and showed this in Banff.
>>> the slides are here :
>>>
>>> http://wiki.ivoa.net/internal/IVOA/InterOpOct2014DM/obcore-ObsdatasetDM_compatibility.pdf
>>>
>>> Do you think you could reconsider the table I shown , page 5 and check if
>>> columns starting with d_ would help in your case.
>>> There has been several iterations with Doug Tody about this axis
>>> description.
>>> I am eager to know if that would fit your needs or not.
>>>
>>> Cheers , Mireille.
>>>
>>>
>>> Le 23/04/2015 15:50, Marco Molinaro a écrit :
>>>
>>> Hi Markus, hi all,
>>>> if this reply is confusing it's probably me not completely getting the
>>>> points.
>>>> So...if you get lost, discard this reply from your inbox.
>>>>
>>>> 2015-04-23 11:57 GMT+02:00 Markus Demleitner <
>>>> msdemlei at ari.uni-heidelberg.de
>>>>
>>>> :
>>>>> Dear DAL, dear DM,
>>>>>
>>>>> On Thu, Apr 23, 2015 at 09:51:46AM +0200, Marco Molinaro wrote:
>>>>>
>>>>> regarding this topic I have a small use case that comes from a
>>>>>> (currently
>>>>>> custom) set of services whose aim is to allow velocity spectra
>>>>>> analysis
>>>>>>
>>>>>> of
>>>>>
>>>>> galactic FITS cubes.
>>>>>>
>>>>>> That's a perfect use case for obscore+datalink, I'd say.
>>>>>
>>>>> sure, it can also fit a SIAv2 plus AccessData, I think.
>>>>>
>>>> Honestly I'm quite puzzled on the way to go, I'll vote for providing
>>>> both,
>>>> at least on the long term,
>>>> even if currently a related service is already a TAP one, so obscore
>>>> should
>>>> be a direct extension.
>>>>
>>>>
>>>> a - a super-set of FITS cubes from non-homogeneous galactic surveys
>>>> and
>>>>
>>>>> pointed archives in the radio band is deployed to allow velocity
>>>>>> spectra
>>>>>> analysis
>>>>>> b - the first step for the user is to search in this set for available
>>>>>>
>>>>>> data
>>>>>
>>>>> along a line-of-sight, with possible filtering on a cone around it,
>>>>>> or a
>>>>>> box around it, limiting the velocity range, selecting explicitly
>>>>>> one/more
>>>>>> survey(s) by name, species, transition, ...
>>>>>>
>>>>>> It seems to me most of the necessary metadata already is in obscore,
>>>>> no?
>>>>>
>>>>> also this is right.
>>>>>
>>>>
>>>> c - the search output (which includes something along the lines of a
>>>>
>>>>> PublisherDID) is then used to explicitly cut the needed cube(s) to make
>>>>>> data transfer affordable (in the near future merging of adjacent
>>>>>> "same-survey" cubes will be also implemented)
>>>>>>
>>>>>> And here I'd argue that's a Datalink thing. There's just too many
>>>>> sorts of processing one could do on data products to have any
>>>>> hopes of describing them in a single database table, and datalink
>>>>> lets you do exactly what you're asking for with minimal overhead on
>>>>> both the table and the client (it will typically have to request one
>>>>> small file per cutout, of course, but given the transfer volumes
>>>>> we're talking about here on the data side that's neglible).
>>>>>
>>>>> one small file for each cutout call is what current custom service
>>>>> does.
>>>>>
>>>> I'm not saying I will not use Datalink, but I'd like to see whether
>>>> that's
>>>> the only solution.
>>>>
>>>>
>>>> Conversely, just having the pixel sizes of the cube (as in the +6
>>>>
>>>>> columns proposal) won't really help you for your use case either, and
>>>>> even if that information could, you'd still have to have some
>>>>> descriptor of the access service somewhere, and so you'd have to use
>>>>> datalink either way.
>>>>>
>>>>> The need for WCS information in the output of the search comes from
>>>>> the
>>>>>
>>>>>> idea of allowing the client side to build correct cutout queries to
>>>>>> the
>>>>>>
>>>>>> Well, let me do a general plea here: "Keep data discovery and data
>>>>> access separate as much as you can." Datalink is the model to
>>>>> efficiently perform that separation.
>>>>>
>>>>> again, current custom service does so, but uses the same parameters
>>>>> to
>>>>>
>>>> do
>>>> both,
>>>> it's just for logical reasons that the endpoints of the services will be
>>>> detached, otherwise
>>>> simple parameter discrimination between the two would do (in my case).
>>>> You're probably right my use case is already covered from DAL point of
>>>> view, maybe the only
>>>> thing not spoken about a lot is the velocity axis of the cubes.
>>>>
>>>> [cutting...] I think I follow you, but I'm not completely
>>>> convinced...could
>>>> be my use case is not so complex
>>>> in these terms.
>>>>
>>>>
>>>> I give you, though, that there are open issues from a practical
>>>>
>>>>> perspective. Mine are:
>>>>>
>>>>> (1) certain types of queries (e.g., "give me all datasets that have a
>>>>> certain axis type in any position") aren't really too well suited
>>>>> for going through indices.
>>>>>
>>>>> (2) there might be major *discovery* use cases that require additional
>>>>> information on the axes
>>>>>
>>>>> On (1), I've already written something in
>>>>> http://mail.ivoa.net/pipermail/dm/2015-April/005150.html, which I
>>>>> think hasn't been disputed yet.
>>>>>
>>>>> In my case it would be finding datasets having velocity axis
>>>>>
>>>> somewhere (usually it's the 3rd axis, but
>>>> in general it shouldn't change if it's in another position).
>>>> But I yet have to understand what to put to identify the velocity axis.
>>>>
>>>> On (2), I can well imagine they exist, but I'd still hope we can avoid
>>>>
>>>> expanding obscore by 20% to satisfy those. Let's identify them if
>>>>> they're there, shall we?
>>>>>
>>>>> Let me mount the soapbox once more (I'm done in a few lines): Think
>>>>> of our adopters. Based on what I hear from DaCHS' users and even a
>>>>> sizable crowd on this list, I'm convinced that additional fields in
>>>>> DMs are being paid for in terms of takeup (not to mention that people
>>>>> tend to put junk in fields whose purpose they don't understand).
>>>>>
>>>>> For the sake of takeup, please don't add fields without a strong,
>>>>> validated use case that cannot be sanely satisfied in any other way.
>>>>>
>>>>> I find it difficult to reply this soapbox buildup, because I found
>>>>>
>>>> myself
>>>> many
>>>> times in the dilemma of using or not (also some SHOULD) fields due to
>>>> lack
>>>> of description of what was required.
>>>>
>>>> I understand (already said so in my previous mail) your concern on
>>>> widening
>>>> the number of table fields. I agree we should have use cases, to be sure
>>>> we
>>>> don't leave someone out and find ourselves in troubles with new
>>>> revisions
>>>> when
>>>> they require a major one for back-compatibility issues
>>>> (oh, god, breaking back-compatibility!).
>>>>
>>>> I also think we need clear guidelines if we want takeup to increase when
>>>> resources are limited or otherwise spent.
>>>>
>>>> ciao
>>>> Marco
>>>>
>>>>
>>>> --
>>> Mireille Louys , Maître de conférences
>>> Centre de Données ( CDS) Icube & Télécom Physique
>>> Strasbourg, Pôle API
>>> Observatoire de Strasbourg 300, boulevard Sébastien Brant
>>> 11, Rue de l'Université CS 10413
>>> 67000 Strasbourg F - 67412 ILLKIRCH Cedex
>>> http://astro.unistra.fr http://www.telecom-physique.fr
>>> tel : 03 68 85 24 34
>>>
>>>
>
> --
> Mireille Louys , Maître de conférences
> Centre de Données ( CDS) Icube & Télécom Physique
> Strasbourg, Pôle API
> Observatoire de Strasbourg 300, boulevard Sébastien Brant
> 11, Rue de l'Université CS 10413
> 67000 Strasbourg F - 67412 ILLKIRCH Cedex
> http://astro.unistra.fr http://www.telecom-physique.fr
> tel : 03 68 85 24 34
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/dal/attachments/20150504/f8f318ad/attachment.html>
More information about the dal
mailing list