[Radioig] Obscore extension for radio: review, implementation

[Markus Demleitner]

Hi Mark,

On Wed, Dec 13, 2023 at 01:17:41PM +0100, Mark Kettenis wrote:
> As we discussed in Tucson, I still fully intent to implement the bits
> of the extension that make sense for VLBI in our TAP service.

Let me know when I can be of help -- and I'll happily release DaCHS
betas with what I have now if you ping me.

> > write the λ-ν conversions manually, but if
> >
> > 	1 = ivo_interval_overlaps(
> > 		em_min, em_max,
> > 		ivo_specconv(1.5, "GHz", "m"),
> > 		ivo_specconv(1, "GHz", "m"))
> >
> > doesn't work for you, let's think again and figure out something that's
> > less verbose.  But let's not define something parallel to em_min and
> > em_max with an even more random unit than m.
>
> That is quite a mouthfull... but it does bother me as well to provide

If that's a concern in practice, we can have a more specific function
for matching radio intervals in obscore tables; but to design these,
saying having a few clearer use cases would be useful.  Perhaps

  1 = ivo_has_radio_interval(1, 1.5, "GHz")

(that has built-in knowledge about em_min and em_max) is justifiable?

> as using "Mhz" but f_resolution as using "kHz").  We do need to retain
> f_resolution though as em_res_power simply varies too much for
> low-frequency observations that span a large fractional bandwidth.
> Radio observations typically have a fixed frequency reolution (and
> therefore varying resolving power) across the band.

For the record, I totally see the f_resolution agenda, but I'd
mildly advocate Hz as its unit.  That's for intellectual economy
("um... was it kilohertz?  ...megahertz?  ...gigahertz?") and
because I feel writing f_resolution<30 isn't so much better than
writing f_resolution<30e3 as to justify memorising SI prefixes.

[Me, I can never remember which VO standard uses bytes as the
unit for file sizes and which uses kilobytes.  Can you?]

> > (8) The columns the DaCHS extension now offers are f_resolution,
> > instrument_ant_diameter, instrument_ant_max_dist,
> > instrument_ant_min_dist, instrument_ant_number, instrument_feed,
[...]
>
> I raised my concerns about the instrument_* columns during the
> InterOp.  Those really are instrument specific and therefore not very
> useful in generic queries one would issue to multiple TAP services.
> It may make more sense to provide this information in an observatory
> specific table (see for example the presentation by Greg Sleap on how
> the MWA presents information like this).

As an outsider, I have to say I find at least some of them not
breathtakingly convincing, either, but since it's an outside view,
that's probably not terribly useful.

But... whoever champions these instrument_X columns: Could you try
and convince me why they're useful for interoperable discovery?
Perhaps we can then already derive an improved, credible-physics use
case from that discussion.

Thanks,

              Markus