<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p> </p>
<p style="line-height: 100%; margin-bottom: 0cm">Hello all!</p>
<p style="line-height: 100%; margin-bottom: 0cm"><br>
</p>
<p style="line-height: 100%; margin-bottom: 0cm">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.<br>
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.</p>
<p style="line-height: 100%; margin-bottom: 0cm">Multi-cone :
why not ? But what does it means ? Do we expect a
« union « Or a « union ALL » (so accept
repetition or not). </p>
<p style="line-height: 100%; margin-bottom: 0cm">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).<br>
Can we imagine customization (for example, my service accepts
CIRCLE AND MOC only) without it becoming tedious to use? I
doubt...</p>
<p style="line-height: 100%; margin-bottom: 0cm">At the same time
having a Simple MOC search is interesting :) and SCS2 is a good
opportunity !</p>
<p>
<style type="text/css">p { line-height: 115%; margin-bottom: 0.25cm; background: transparent }</style></p>
<p>Regards</p>
<p>Gilles Landais (CDS)</p>
<div class="moz-cite-prefix">On 9/4/26 11:05, Markus Demleitner via
dal wrote:<br>
</div>
<blockquote type="cite"
cite="mid:mthzd4etyfsbthhmnrt54fwvh5lcnvnfsppdbc5fktfhy5gytu@wm5loxjgauvs">
<pre wrap="" class="moz-quote-pre">Dear DAL,
On Fri, Sep 04, 2026 at 09:12:00AM +0100, Mark Taylor via dal wrote:
</pre>
<blockquote type="cite">
<pre wrap="" class="moz-quote-pre">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.
</pre>
</blockquote>
<pre wrap="" class="moz-quote-pre">
...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
</pre>
</blockquote>
</body>
</html>