SCS2: POS plus RA/DEC/SR

Markus Demleitner msdemlei at ari.uni-heidelberg.de
Thu Sep 3 12:01:52 CEST 2026


Dear DAL,

In the next installment of me bringing some of Stelios' points from
his (finally migrated) SCS2 bug
<https://github.com/ivoa-std/SCS2/issues/7>[1] is this:

> Supporting both POS and RA/DEC/SR as alternatives adds meaningful
> complexity on both the service and client side, and I'm wondering
> if the benefit justifies it.

> Clients can discover whether POS is supported by fetching
> /capabilities and inspecting the declared parameters, but the
> spec's own appendix says simple clients don't need to fetch
> capabilities at all.
>
> Those clients will probably always use RA/DEC/SR right, and then
> sophisticated clients would probably just be using TAP anyways?

Possibly, yes, provided the table is available via TAP.

> On the service side, supporting both creates an awkward
> discriminated-union input that static schema validation cannot
> express.
> RA/DEC/SR must be typed as optional to allow POS as an alternative,
> and the mutual-exclusivity check requires runtime logic outside the
> framework's validation pipeline:

I'd count that as a minor annoyance, but yes, that is evidence
against supporting POS.

> Either drop POS and keep RA/DEC/SR (simple, familiar), or make POS
> the canonical interface?
> I think either is preferable to requiring implementations to handle
> both indefinitely. Or perhaps worth clarifying the tradeoff in the
> spec?

I've always been rather uncertain about POS; on the one hand, it is
nice to have the same parameter as SIAv2, on the other hand, the
polygon thing (and perhaps MOC later) is a pain to implement without
something like pgsphere in the backend.

I remain neutral and would simply throw out POS given any amount of
opposition if it weren't for voices in Strasbourg that said they have
huge catalogues that they may not want to open up to all the
complexities of TAP (and perhaps don't even keep in an RDB) but for
which they'd like to have more expressive geometry types than just
the cone.

So... opinions?

Thanks,

          Markus



More information about the dal mailing list