SCS2: POS plus RA/DEC/SR

[Francois-Xavier PINEAU]

Dear Markus and DAL,

Here a few (biased) comments on SCS2.

1. Zone/range/interval, boxes, MOCs, and interoperability

Many years ago, before he retired, I asked François Ochsenbein why the 
simple
table access protocols in the IVOA were limited to Cone Search.
Why not also support zones/ranges/intervals (i.e. RAMin, DecMin, RAMax, 
DecMax),
boxes (RA, Dec, Maj, Min, PosAngle) -- today, we could add MOCs --, etc.?
His answer was -- if I remember correctly -- that a cone has the nice 
property
of being simple to convert from one reference system to another one.

Depending on the (table, data centre) couple, the primary position of a 
table
may be expressed in FK4, ICRS, Galactic coordinates, etc.
And indeed:
* a zone/range/interval (delimited by 2 small circles and 2 meridians) 
in one
   coordinate system cannot in general be converted into a corresponding
   zone/range/interval in another system (not even into a polygon).
* a box:
     + without a position angle (as in ADQL 1.0) cannot in general be 
converted
       into a box without a position angle in another coordinate system;
     + with a position angle can be transformed, but the transformation 
is not
       straightforward. The position angle is defined with respect to the
       North Celestial Pole and therefore remains invariant, whereas the
       angle with respect to the system's (0,0,1) axis changes.
* a MOC cannot be converted into a coordinate system different from ICRS
   (its cells boundaries are not great circle arcs).

In the main VizieR database, the  reference system of the primary 
(indexed) position
depends on the table. Likewise, I assume that not all tables at all data
centres are indexed in ICRS.
For a given ICRS cone and a given table, the centre of the cone can simply
be transformed into the coordinate system used by that table before 
performing
the query (and ICRS positions added to the result, with no impact
on the search/retrieve mechanism).
This approach is not possible, or at least is not straightforward,
for zones/ranges/intervals, MOCs, etc.

 From an interoperability point of view, I therefor have concerns in making
zones/ranges and MOCs part of the SCS2 (even optionally), **unless** all
data centres agree to use ICRS as the coordinate system of their indexed 
positions.


2. Scope of a "simple" protocol

I am not against performing queries on zones/ranges, MOCs, polygons, etc.
Quite the contrary. I think these are all useful capabilities.
However, I would prefer them not to be part of the simplest and most
interoperable standard (even if optional).
In particular, I would be reluctant to add them to a protocol whose purpose
is explicitly to provide a "simple cone search" interface.
(If one has to know the exact capabilities of a service, capabilities 
that may vary from
one table to another in a same service,  to determine whether,
e.g., it supports queries by MOCs (and for which tables), I would not 
consider that "simple".).

Why not, e.g., a PAXT for "Position Access eXtension for Tables" that 
would be
more flexible that enforcing ICRS input regions (but necessarily less 
simple/interoperable
than SCS)?


3. Multi-cone

One of the advantages of SCS, from my perspective, is that it provides a
low entry barrier to the VO: it is easy to implement, and it remains
relatively easy to support even with a (reasonably) large number of
simultaneous queries.
 From a performance point of view, provided that the data are positionally
indexed (and clustered!), the cost of a single cone-search query can be 
quite
low -- essentially a few disk accesses.
This is no longer necessarily true for multi-cone queries, particularly if
multi-cone is intended to support cross-matching.
For example, consider 100,000 small cones uniformly distributed over the
full sky, each returning a single row from a large table such as Gaia.
On a regular HDD array with a seek time of about 5 ms, and assuming a single
user with a cold disk cache, this could already amount to roughly 8 minutes
of disk-seek time (it is a rough estimate: disk array buffer cache may help,
but the single user assumption is optimistic).
Modern web-browsers timeout is 5min.
Supporting several such queries simultaneously is therefore quite different
from supporting several independent single-cone searches.
And the xmatch usage of the multi-cone is different from retrieving data in
a  few large cones (e.g. give me al source in a list of XMM FOVs).

Again, I am not against multi-cone queries (i.e., as you describe,  the 
union
of possibly overlapping cones). I just question whether they belong in a 
"simple",
low-entry-barrier protocol.

3.1. Table Upload

The format of the uploaded table is very constrained: it consists of only
three columns (RA, Dec, SR), in this order, and we could even impose the
format (decimal) and units (deg, deg, deg), if its not already the case.
Thus, we do not need any metadata on the input.

Given these constraints, why not use a simple CSV input instead of a 
VOTable?
(Reading a VOTable is, in general, more challenging than writing a VOTable).

4. A basic cross-match protocol?

Finally, since we are considering multi-cone queries, and since these 
queries
will undoubtedly be used to perform cross-matches, perhaps we may also
consider a "basic XMatch" protocol.
Rather than making SCS increasingly complex to accommodate this use case,
perhaps a dedicated, basic cross-match protocol could provide the 
functionality
needed for the common cases while keeping SCS genuinely simple.


5. Against a uniq String IDs in the result

Uniq String ID in the result is mandatory in SCS 1.1:
https://www.ivoa.net/documents/ConeSearch/20200828/WD-ConeSearch-1.1-20200828.html
According to SCS2:
https://ivoa.net/documents/ConeSearch/20260529/WD-SCS2-2.0-20260529.html
it comes from DALI sec. 5.

I have a few concerns about making this a MUST:
* why require an integer/long primary key to be converted to a string,
   when the original datatype is already well defined?
   The BINARY representation is different (its not just about the metadata),
   and we lose potentially useful datatype information.
* what about tables with no simple primary key (e.g.  PK = 2 FKs),
   or with an internal record number that the data provider would prefer 
not to expose)?
   One such example is the identifier of the Tycho2 catalog:
https://vizier.cds.unistra.fr/viz-bin/VizieR?-source=I/259&-to=3
   which is the combination of the TYC1, TYC2 and TYC3 columns.

For these reasons, I would prefer a SHOULD rather than a MUST here.
This would still recommend providing a unique identifier when appropriate.


In conclusion, I tend to think that SCS should remain a low-barrier 
protocol in the VO.
Even when functionalities are optional, they inevitably make the 
standard more complex,
and there is a certain frustration in having functionality defined in 
the standard but not
implementing it.
I understand that updating an existing standard is generally simpler 
than defining new ones.
However, I do think there is room between SCS and TAP for additional, 
more focused standards:
for example, one for single-table positional access, an extension of SCS 
(possibly including
multi-cone searches, provided we limit their use to a "small" number of 
potentially large cones),
and perhaps one for simple cross-matches.


Best Regards.


Le 15/09/2026 à 08:44, Markus Demleitner via dal a écrit :
> Dear DAL folks,
>
> On Mon, Sep 14, 2026 at 04:09:37PM -0700, Patrick Dowler via dal wrote:
>> 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.
> Ok, so we'll replace POS with CIRCLE... and keep RA/DEC/SR as some
> sort of legacy wrapper?  And require CIRCLE, including its repeated
> use?
>
> I think I'll put that into the spec unless there's loud protest just
> about now.
>
> As to Gilles' question:
>
>> multi-cone : why not ? But what does it means ? Do we expect a
>> « union «  Or a « union ALL » (so accept repetition or not).
> I'm pretty sure the rules should remain as they are for the current
> UPLOAD: It's a normal UNION.
>
> To me, that's obvious because of the benefits a proper primary key
> (meta.id;meta.main) gives to any sort of data; but the alternative
> "multiple, possibly overlapping cones" would also only work properly
> if each row said which cone matched it, and we don't have a mechanism
> that does that either.
>
> I give you at on the implementation side, the non-dupe requirement
> was a bit tedious with the join-based strategy I had with UPLOAD.
> Multi-CICLE I'll probably do by OR-ing together the individual
> constraints, and then plain UNION is even more natural.
>
> Thanks,
>
>          Markus
-- 

Francois-Xavier Pineau
Ingénieur de Recherche
Tél : +33 (0)3 68 85 24 14,
francois-xavier.pineau at astro.unistra.fr

Centre de Données astronomiques de Strasbourg (CDS)
11, rue de l'Université - E03

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/dal/attachments/20260916/b4703d85/attachment.htm>