time series with sparse em axes

[Baptiste Cecconi]

As a solar and planetary radio astronomer, I would use "dynamic-spectrum" when searching for such kind of dataset.

Baptiste

> Le 28 mars 2025 à 11:13, Molinaro, Marco via semantics <semantics at ivoa.net> a écrit :
> 
> Thanks Markus, Baptiste, Ada (direct email),
> 
> indeed I should look better into the time series Note.
> 
> The doubt that I still have (that applies also when
> using the dynamic-spectrum as the datatype) is about
> the user experience (at the obscore/epncore discovery
> stage) when they see a spectral axis ranging 237-2695MHz
> but actually getting back what are actually multiple
> 1D, single frequency, time series (time axis is sampled
> uniformly, no troubles there), sparsely distributed over
> the range band.
> 
> I do trust applications to read correctly the FITS bintables
> (or whatever other format we might come up), but I wonder
> if the sparse em would be confusing.
> 
> Since it's not an urgent matter, if we (local group)
> progress on this by the time of June, I might try to
> provide a quick report there.
> 
> Thanks again!
> Cheers
>     Marco
> 
> Il giorno mar 25 mar 2025 alle ore 12:25 Baptiste Cecconi via semantics <semantics at ivoa.net <mailto:semantics at ivoa.net>> ha scritto:
>> I Marco, 
>> 
>> if I understand well, you have 3 dynamic-spectra (each having 6 spectral channels).
>> The http://www.ivoa.net/rdf/product-type#dynamic-spectrum data product should applicable. 
>> 
>> In epncore, this should be no problem to describe the spectral axis. Nothing prevents to have sparse spectral axes in the datasets. 
>> 
>> Cheers
>> Baptiste
>> 
>> 
>>> Le 24 mars 2025 à 09:47, Markus Demleitner via semantics <semantics at ivoa.net <mailto:semantics at ivoa.net>> a écrit :
>>> 
>>> Hi Marco,
>>> 
>>> On Fri, Mar 21, 2025 at 06:26:59PM +0100, Molinaro, Marco via semantics wrote:
>>>> for a "heritage data" project we have a set of observations
>>>> that consist of time series of nearly monochromatic RHCP & LHCP
>>>> radio fluxes of the full disk Sun.
>>>> 
>>>> Unfortunately the files they are stored in (FITS bintables)
>>>> contain:
>>>> - the 6 individual observational frequencies, sparse from 237Mhz to 2.7GHz
>>>> - for each of them 3 time series: LHCP, RHCP and the sum of them (full flux)
>>>> 
>>>> This leads us to describe them, no matter if in obscore or epncore,
>>>> as 6 separate time series records referencing the same FITS dataset,
>>>> because we are unable to describe the sparse "em" axes.
>>> 
>>> Well, as long as the time axis is sampled uniformly, there is nothing
>>> that would keep you from having just one time series with 18 columns,
>>> and I believe clients like SPLAT would do a reasonable job displaying
>>> them.
>>> 
>>> If the time axis is not sampled uniformly over all frequencies, I
>>> think I'd go for per-frequency time series with one column each for
>>> the three observation modes.
>>> 
>>> All that is based on what I think will make this data easy to work
>>> with with generic VO tools, completely independently of the
>>> underlying physics and in particular community practice.  Therefore:
>>> 
>>>> Or maybe Radio, HE, TD IGs have some insight on this.
>>> 
>>> I'd frankly ask Solar System first (and its vice chair already
>>> confesses he can't help here).  I'd say *if* there's some dominant
>>> practice in the community, whatever format that calls for is what I'd
>>> serve up by default; and then I'd attach a datalink that yields
>>> SDM-compliant tables with Ada blocks (:-)
>>> <http://ivoa.net/documents/Notes/LightCurveTimeSeries/index.html>
>>> for interoperability beyond that community.
>>> 
>>> Consider this as not much more than my 2 cents, though.
>>> 
>>>        -- Markus
>>> 
>> 
> 
> 
> 
> -- 
> Marco Molinaro
> INAF - Istituto Nazionale di AstroFisica
> Osservatorio Astronomico di Trieste
> email marco.molinaro at inaf.it <mailto:marco.molinaro at inaf.it>
> tel. [+39] 333 33 20 564 [also Telegram]

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/semantics/attachments/20250328/b99ed8c1/attachment-0001.htm>