-
Notifications
You must be signed in to change notification settings - Fork 6
Description
3.6 s_ra/s_dec
Regarding the usage of "the center" in the description: please realize
that s_ra/s_dec are used in combination with s_fov to determine a
region on the sky. So you can't arbitrarily redefine this as
"reference position".
[ Discussed during HEIG meeting 30/10/2025: somehow clarify that s_ra/s_dec are the center for s_fov ]
3.10 o_ucd
Another way to represent data sets with multiple observables would be
to have an ObsCore row for each observable, each with their own o_ucd.
In the same way as some radio archives represent observations that
contain multiple disjoint frequency bands.
4.2 s_ref_energy/em_ref_energy/s_ref_oaa/em_ref_oaa:
The idea of specifying reference values for s_* and em_* parameters
makes sense for other parts of the spectrum as well. But of course
they would be given as a wavelength instead of an energy.
4.4 energy_min/energy_max:
You will still need to provide em_min and em_max to provide
cross-spectrum discoverability. Then the question becomes how you
guarantee consistency of these pairs of columns. The note should
specify the values of h and c used for conversion. And c should
probably be the same as specified in the radio note. Or maybe just
specify the value of hc?
4.8 event_type:
For a non-HEA export it is somewhat baffling to call a quality
indicator "event_type".
5.1.6 Clarification of “flux” in some term definitions:
Can m^2 be typeset properly?
As an aside, in radio we typically use spectral flux density expressed in Jy
(10^-26 W / m^2 / Hz).
6 Proposal of the ivoa.obscore_hea attributes:
-
The energy_min/max rows have unit and type swapped.
-
Types are inconsistent with the types used in ObsCore 1.1: float ->
double, string -> String, int -> integer, TMOC -> String?(note to self, the Radio note doesn't mention types)