<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p><br>
</p>
<div class="moz-cite-prefix">Le 14/09/2026 à 19:27, Landais via dal
a écrit :<br>
</div>
<blockquote type="cite"
cite="mid:3548bbd5-4de1-4624-932d-cc4d74fa22b6@astro.unistra.fr">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<p> </p>
<p style="line-height: 100%; margin-bottom: 0cm">Hello all!</p>
<p style="line-height: 100%; margin-bottom: 0cm"><br>
</p>
</blockquote>
(...)
<blockquote type="cite"
cite="mid:3548bbd5-4de1-4624-932d-cc4d74fa22b6@astro.unistra.fr">
<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>
</blockquote>
+1<br>
Pierre
<blockquote type="cite"
cite="mid:3548bbd5-4de1-4624-932d-cc4d74fa22b6@astro.unistra.fr">
<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>
</blockquote>
</body>
</html>