loumir
commented
10 months ago For the use of 'map' like in line : raster map total power | x,y, degenerate in: freq | map | (e) | raster map
if we would introduce map as data product_type , this would imply another flavor of 2D image stored as a list of coordinates .
I would rather propose to use data product_type="image" and specialize it using dataproduct_subtype=map
this is a way to prevent the vocabulary to diverge too much and keep a reasonable number of options for data providers to publish their data data products .
Bonnarel
From Alessandra Zanichelli, Vincenzo Galluzzi and Marco Molinaro
We report some considerations mainly focused on single dish data with respect to the draft documents: IVOA Obscore Extension for Radio data Version 1.0 (IVOA Note 2023-02-13). These considerations are intended for further discussion within the IVOA Radio Interest Group.
dataproduct_type and sky_scan_mode
We are proposing a new schema that, while trying to better follow IVOA ObsCore prescriptions, still poses some open questions to be discussed.
Current values for dataproduct_type are taken from the preliminary document Data Product Type vocabulary. Note that the current definition of spectrum in the Data Product Type vocabulary should be extended to include raw counts (not only flux or magnitudes). For instance: “A scalar observable given as a function of a spectral coordinate”.
We assume that multi-feed/multi-beam capabilities can be exploited in case of imaging observations (raster map, otf map). For non-imaging observing modes (ON, ON-OFF, otf cross scan, skydip) single feed capabilities are typically used (in the case of a multi feed receiver, data are recorded from a single/central feed).
In the following table the proposed new values for dataproduct_type and sky_scan_mode are marked in yellow. Note: for dataproduct_type we are using the new definition of “measurements” from the Data Product Type vocabulary (preliminary): https://www.ivoa.net/rdf/product-type/2021-11-18/product-type.html as “Generic tabular data not fitting any of the other terms. Because of its lack of specificity, this term should generally be avoided, and new, more precise terms should be introduced instead.”. The definition of “measurements” in ObsCore-1.1 (REC): https://ivoa.net/documents/ObsCore/20170509/index.html as “A list of derived measurements gathered in a particular original dataset of one of the previous sort after some analysis processing, like a source list, or more generally a list of ‘results’ attached to such datasets” would not be appropriate and would imply the definition of a further value for dataproduct_type. We are also supporting the use of the value “spatial profile” for dataproduct_type (currenlty under discussion). Both “measurements” and “spatial_profile” are written in square brackets to account for their preliminary status/meaning.
We note that sky_scan_mode applies to all radio data, not only single-dish ones. Also, sky_scan_mode cannot describe the frequency switching mode. We propose to change from sky_scan_mode to a more general scan_mode. Alternatively, in order to consider the space and frequency domains separately we propose to keep sky_scan_mode and to add a further term frequency_scan_mode (equal to 'fixed' or 'switching' depending on the cases).
mode
axes
dataproduct_type
note
sky_scan_mode
ON total power
degenerate in: x, y, freq
[measurements]
(a)
on-source (g)
ON spectral
freq, degenerate in: x, y
spectrum
on-source (g)
ON-OFF total power
x,y, degenerate in: freq
[measurements]
(b)
on-off
ON-OFF spectral
x,y,freq
cube
(c)
on-off
frequency switching
freq, degenerate in: x and y
spectrum
(d)
on-source (g)
on-the-fly cross scan total power
x,y, degenerate in: freq
[spatial profile]
on-the-fly cross scan
on-the-fly cross scan spectral
x,y,freq
cube
(c)
on-the-fly crosscan
raster map total power
x,y, degenerate in: freq
map
(e)
raster map
raster map spectral
x,y,freq
cube
(c)
raster map
otf map total power
x,y, degenerate in: freq
map
(e)
on the fly map
otf map spectral
x,y,freq
cube
(c)
on the fly map
skydip total power
x, y, degenerate in: freq
[spatial profile]
skydip
skydip spectral
x,y,freq
[spatial profile]
(f)
skydip
(a) in this case “measurements” seems to be the most appropriate value for dataproduct_type. (b) ON-OFF total power: two points are measured, no spectral info. One of the two measurements (OFF) may have very little scientific content if used by itself. (c) sparse cube. Only the cross in a cross scan (or the ON and OFF positions in an ON-OFF) is sampled. An otf spectropolarimetric map taken with a peculiar scanning strategy (for instance a spiral pattern) may result in a sparse cube. A spectral skydip may be considered a sparse cube, but see note (f) (d) frequency switching has dataproduct_type=spectrum. The resulting spectrum may contain gap(s) if the frequency switching encompasses non-overlapping bandwidths. (e) In the case of total power raster or otf map we propose to introduce a new value dataproduct_type=map. In fact the frequency axis is degenerated so that `”cube'' is not appropriate and at the same time this is not an “image” as it is intended in the VO dataproduct_type Document. A single dish total power radio map cannot be considered an “image” dataproduct because data are typically written in table(s), each row containing spatial coordinates, timestamp and raw intensity (raw counts). Further processing is required to obtain a proper 2D image. Also, in the more general case data are not acquired on a regular 2D grid (for instance, if one uses a spiral scanning pattern). Map should be the parent term for “image”. (f) in principle, a spectral skydip could be considered as a collection of spectra (e.g a sparse cube). However, the relevant information (atmospheric opacity) is contained in the spatial profile derived from the observation, thus the choice of dataproduct_type=spatial profile also for spectral skydip. (g) sky_scan_mode value “on-source” should be added for ON and frequency switching observations. The following figure illustrates the main single dish observing mode.  Note that INAF has no Phased Array Feed receivers onboard the radio telescopes so we are not taking into account cases specific to beamforming techniques. Thus, more values could be needed. Do we have any PAF expertsexpert in the RadioIG?