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