Vocabulary for scan_mode and tracking_mode

[kettenis]

In discussion during the High Energy in the Virtual Observatory workshop in Paris we noticed that the vocabularies for the scan_mode and tracking_mode parameters are not well defined in the document. Some terms are listed in table 2 but not fully explained. The scan_mode possibilities are shown in figure 1, but worded differently there. For tracking_mode the document references ObsLocTAP, but the vocabulary defined there is different from what's listed in table 2.

[Bonnarel]

For scan_mode I propose to add a normative table with vocabulary values consistent with figure 1. For tracking mode it's a little different.
First : ObsLocTap reads tracking_type. As they are a specification and we are not yet we have to change our term.
Second : For the values , it's not totally stupid that there are some differences. I think our "targeted" and their "sidereal" are the same. Alt azimuth seems to be absent in ObsLocTAP but is useful for SD (and probably also for CTA / High energy). So this needs a specific discussion include HeiG people and ObsLocTAP people to reach an exhaustive consensus on the list of values

[kettenis]

We discussed this a bit in the room on Tuesday (in which CTA experts participated) and our educated guess was that targeted maps to ObsLocTAP Siderial and alt-azimuth maps to ObsLocTAP Fixed-az-el-transit. We currently don't have anything that maps to ObsLocTAP Solar-system-object-tracking, but that certainly is a possibility for radio telescopes. However ObsCore can't really represent observations of solar system objects; that's why we have EPN-TAP. We were not very confident in our guesses what *wobble means, but there is nothing ObsLocTAP that we could map it to.

@vincenzo-galluzzi-INAF can you maybe clarify this?

[msdemlei]

On Thu, May 01, 2025 at 03:10:10AM -0700, kettenis wrote: kettenis left a comment (ivoa-std/ObsCoreExtensionForRadioData#77) We discussed this a bit in the room on Tuesday (in which CTA experts participated) and our educated guess was that **targeted** maps to ObsLocTAP **Siderial** and **alt-azimuth** maps to ObsLocTAP **Fixed-az-el-transit**. We currently don't have

Ah... I'm fairly far out of my depth here, but that two different standards require the same set of concepts would suggest to me they should be using a shared resource to enumerate them. Which means that if there's more than, say, three values and *in particular* if there's a hierarchy we should be creating a vocabulary. If, on the other hand, it's really just a handful of static terms that probably won't change more often than once per technology cycle, I'd say referencing the table from ObsLocTAP (or using StandardsRegExt keys in its resource record) would also work just fine.

[loumir]

Practically , I would prefer to set up first the lists of possible values for scan_mode and tracking_type inside
Obs_radio extension , compliant as much as possible with ObsLocTAP, and HEIG wishes .
It takes time to stabilize vocabularies so this would help to bring Obscore Radio extension to endorsement kicker I guess.

[pdowler]

WD-CAOM-2.5 also has a "tracking mode" that is the conceptually the same, and I envision this would be a vocabulary. It can start small (2-3 terms) and be VEPed as necessary.