Axes in Obscore: Velociity axes

[Louys Mireille]

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