SCS2: CIRCLE [was: POS] plus RA/DEC/SR

Markus Demleitner msdemlei at ari.uni-heidelberg.de
Tue Sep 22 10:48:48 CEST 2026


Dear DAL folks, again,

Sorry for replying to my own mail, but I'd like to point you to
Mark's github comment in the present matter:

On Fri, Sep 18, 2026 at 03:56:26PM +0200, Markus Demleitner wrote:
> As I had said, I like Pat's idea, and thus I've made
> <https://github.com/ivoa-std/SCS2/pull/9>.  This
>
> * Drops POS and introduces CIRCLE
> * Makes CIRCLE support mandatory (less optional=more happiness)

In <https://github.com/ivoa-std/SCS2/pull/9#issuecomment-5763502172>,
Mark now observes:

  However it's not clear from this PR as currently written how CONE
  is supposed to interact with the old-style parameters RA,DEC,SR.
  Section 4.3 suggests that *either* CONE(s) *or* RA,DEC,SR must be
  present in a query?

  ... which sounds like an unnecessary complication.  Why not get rid
  of RA,DEC,SR altogether and just require one or more CONE
  specifications?  It's more of a break with the familiar
  ConeSearch-1 syntax, but if SCS2 is avowedly
  non-backward-compatible that doesn't sound like a problem.

Which of course is true.  Without any historical baggage I'm sure
we'd just have CIRCLE and no RA, DEC, and SR.

For now, it (the baggage and the paramater set) is there.  If nobody
jumps in to its rescue, however, I feel an increasing urge to drop
the split position specification for simplicity.

How chagrined would by be by the demise of RA, DEC, and SR?

       -- Markus

[who will say that the split parameters have the advantage that you
can attach metadata to the parameter declarations: ranges, a median,
etc, or a maximal and perhaps minimal search radius (minimal search
radius as a measure of positional uncertainty even?).  But at least
for coverage we don't need that with-column metadata: that
information is already in the global resource metadata]



More information about the dal mailing list