SCS2: POS plus RA/DEC/SR

[Patrick Dowler]

SODA-1.0 has both POS and type-specific params, eg CIRCLE. We designed
that after SIAv2 and we kept POS as a compromise. It was simpler to
advertise which parameters a SODA service supported (in a datalink
service descriptor).

A circle parameter would have a defined (DALI) xtype and value
serialisation and be required for SCSv2; other such params (POLYGON,
MOC, etc) could be defined now or later and be optional. Then it comes
down to declaring which parameter names are supported (capabilities or
service descriptors) rather than which variants of POS are supported.

it's an option...

--
Patrick Dowler
Canadian Astronomy Data Centre
Victoria, BC, Canada

On Mon, 14 Sept 2026 at 10:27, Landais via dal <dal at ivoa.net> wrote:
>
> Hello all!
>
>
> Upload is heavy to implement and to execute. Upload is a part of TAP, so if you implement a SCS as an interface of an existing TAPservice ; it’s ok, else it becomes more difficult.
> In VizieR, the SCS doesn’t use TAP at all. The VizieR SCS is dedicated for cone and uses a technology more efficient than database (see AT2S poster from FX.Pineau).  I would like to keep this in SCS2.
>
> Multi-cone : why not ? But what does it means ? Do we expect a « union «  Or a « union ALL » (so accept repetition or not).
>
> The main problem I think with POS is the complexity of the geometries which may be more difficult to implement, especially if ADQL regions and STCS syntax are included. If POS is added, they must remain options  (polygon is not conesearch).
> Can we imagine customization (for example, my service accepts CIRCLE AND MOC only)  without it becoming tedious to use? I doubt...
>
> At the same time having a Simple MOC search is interesting :) and SCS2 is a good opportunity !
>
> Regards
>
> Gilles Landais (CDS)
>
> On 9/4/26 11:05, Markus Demleitner via dal wrote:
>
> Dear DAL,
>
> On Fri, Sep 04, 2026 at 09:12:00AM +0100, Mark Taylor via dal wrote:
>
> The current SCS2 draft says (sec 4.1.6):
>
>    "SCS2 services may support a POS parameter as defined by SIAP2
>     (Dowler and Bonnarel et al., 2015), except that for SCS2, this is a
>     non-repeatable parameter."
>
> so the multi-position benefit does not apply here, as the text
> is currently written.
>
> ...which is of course open to debate.  UPLOAD was a surprising pain
> in implementation, and multi-POS would be a relatively cheap
> replacement to the current UPLOAD model for a simple multicone.
>
> Of course, UPLOAD would scale to multi-parameter queries (e.g, mag
> limit 23 in cone A and 19 in cone B), which POS can never do.  But we
> don't have that in the current draft and likely never will.
>
> So, perhaps we should turn things around, make (multi-) POS
> mandatory and scrap UPLOAD entirely?
>
> This would still leave the problem of POLYGON.  Perhaps if we just
> required support for CIRCLE and added an element in the capability
> that lets clients discover other geometry types (<ohhhh!> MOC?) on a
> per-service basis?
>
> I'm starting to like this, actually.  Does anyone else feel halfway
> strongly about it?
>
>         -- Markus
>
>
>
>
>