SCS2: POS plus RA/DEC/SR

[Patrick Dowler]

The main argument for POS (vs 3 separate params) in SIAv2 is that it
is easier to support a list of values just by submitting multiple
POS={value} pairs in the query. Yes, there is the OR semantics but
that's still a lot simpler than specifying and implementing table
upload for multi-position queries in an S-protocol. (It was easier to
specify in TAP because we just had to be clear on how table would be
named for use in ADQL and the rest was up to the user writing the
correct ADQL)

So my 2c is that POS is superior to RA+DEC+SR. And this is version 2.0 ...
--
Patrick Dowler
Canadian Astronomy Data Centre
Victoria, BC, Canada

On Thu, 3 Sept 2026 at 03:02, Markus Demleitner via dal <dal at ivoa.net> wrote:
>
> 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
>