SCS2: POS plus RA/DEC/SR

[gilles.landais at astro.unistra.fr]

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
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/dal/attachments/20260914/6239762f/attachment.htm>