<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Dear Markus and DAL,</p>
<p>Here a few (biased) comments on SCS2.<br>
<br>
1. Zone/range/interval, boxes, MOCs, and interoperability<br>
<br>
Many years ago, before he retired, I asked François Ochsenbein why
the simple<br>
table access protocols in the IVOA were limited to Cone Search.<br>
Why not also support zones/ranges/intervals (i.e. RAMin, DecMin,
RAMax, DecMax),<br>
boxes (RA, Dec, Maj, Min, PosAngle) -- today, we could add MOCs
--, etc.?<br>
His answer was -- if I remember correctly -- that a cone has the
nice property<br>
of being simple to convert from one reference system to another
one.<br>
<br>
Depending on the (table, data centre) couple, the primary position
of a table<br>
may be expressed in FK4, ICRS, Galactic coordinates, etc.<br>
And indeed:<br>
* a zone/range/interval (delimited by 2 small circles and 2
meridians) in one <br>
coordinate system cannot in general be converted into a
corresponding<br>
zone/range/interval in another system (not even into a polygon).<br>
* a box:<br>
+ without a position angle (as in ADQL 1.0) cannot in general
be converted<br>
into a box without a position angle in another coordinate
system;<br>
+ with a position angle can be transformed, but the
transformation is not<br>
straightforward. The position angle is defined with respect
to the<br>
North Celestial Pole and therefore remains invariant,
whereas the <br>
angle with respect to the system's (0,0,1) axis changes.<br>
* a MOC cannot be converted into a coordinate system different
from ICRS<br>
(its cells boundaries are not great circle arcs).<br>
<br>
In the main VizieR database, the reference system of the primary
(indexed) position <br>
depends on the table. Likewise, I assume that not all tables at
all data<br>
centres are indexed in ICRS.<br>
For a given ICRS cone and a given table, the centre of the cone
can simply <br>
be transformed into the coordinate system used by that table
before performing<br>
the query (and ICRS positions added to the result, with no impact<br>
on the search/retrieve mechanism).<br>
This approach is not possible, or at least is not straightforward,<br>
for zones/ranges/intervals, MOCs, etc.<br>
<br>
From an interoperability point of view, I therefor have concerns
in making<br>
zones/ranges and MOCs part of the SCS2 (even optionally),
**unless** all <br>
data centres agree to use ICRS as the coordinate system of their
indexed positions.<br>
<br>
<br>
2. Scope of a "simple" protocol<br>
<br>
I am not against performing queries on zones/ranges, MOCs,
polygons, etc.<br>
Quite the contrary. I think these are all useful capabilities.<br>
However, I would prefer them not to be part of the simplest and
most<br>
interoperable standard (even if optional).<br>
In particular, I would be reluctant to add them to a protocol
whose purpose<br>
is explicitly to provide a "simple cone search" interface.<br>
(If one has to know the exact capabilities of a service,
capabilities that may vary from<br>
one table to another in a same service, to determine whether,<br>
e.g., it supports queries by MOCs (and for which tables), I would
not consider that "simple".). <br>
<br>
Why not, e.g., a PAXT for "Position Access eXtension for Tables"
that would be <br>
more flexible that enforcing ICRS input regions (but necessarily
less simple/interoperable<br>
than SCS)?<br>
<br>
<br>
3. Multi-cone<br>
<br>
One of the advantages of SCS, from my perspective, is that it
provides a<br>
low entry barrier to the VO: it is easy to implement, and it
remains<br>
relatively easy to support even with a (reasonably) large number
of<br>
simultaneous queries.<br>
From a performance point of view, provided that the data are
positionally<br>
indexed (and clustered!), the cost of a single cone-search query
can be quite<br>
low -- essentially a few disk accesses.<br>
This is no longer necessarily true for multi-cone queries,
particularly if<br>
multi-cone is intended to support cross-matching.<br>
For example, consider 100,000 small cones uniformly distributed
over the<br>
full sky, each returning a single row from a large table such as
Gaia.<br>
On a regular HDD array with a seek time of about 5 ms, and
assuming a single<br>
user with a cold disk cache, this could already amount to roughly
8 minutes<br>
of disk-seek time (it is a rough estimate: disk array buffer cache
may help,<br>
but the single user assumption is optimistic).<br>
Modern web-browsers timeout is 5min.<br>
Supporting several such queries simultaneously is therefore quite
different<br>
from supporting several independent single-cone searches.<br>
And the xmatch usage of the multi-cone is different from
retrieving data in<br>
a few large cones (e.g. give me al source in a list of XMM FOVs).<br>
<br>
Again, I am not against multi-cone queries (i.e., as you
describe, the union<br>
of possibly overlapping cones). I just question whether they
belong in a "simple",<br>
low-entry-barrier protocol.<br>
<br>
3.1. Table Upload<br>
<br>
The format of the uploaded table is very constrained: it consists
of only<br>
three columns (RA, Dec, SR), in this order, and we could even
impose the<br>
format (decimal) and units (deg, deg, deg), if its not already the
case.<br>
Thus, we do not need any metadata on the input.<br>
<br>
Given these constraints, why not use a simple CSV input instead of
a VOTable?<br>
(Reading a VOTable is, in general, more challenging than writing a
VOTable).<br>
<br>
4. A basic cross-match protocol?<br>
<br>
Finally, since we are considering multi-cone queries, and since
these queries<br>
will undoubtedly be used to perform cross-matches, perhaps we may
also<br>
consider a "basic XMatch" protocol.<br>
Rather than making SCS increasingly complex to accommodate this
use case,<br>
perhaps a dedicated, basic cross-match protocol could provide the
functionality<br>
needed for the common cases while keeping SCS genuinely simple.<br>
<br>
<br>
5. Against a uniq String IDs in the result <br>
<br>
Uniq String ID in the result is mandatory in SCS 1.1: <br>
<a class="moz-txt-link-freetext"
href="https://www.ivoa.net/documents/ConeSearch/20200828/WD-ConeSearch-1.1-20200828.html">https://www.ivoa.net/documents/ConeSearch/20200828/WD-ConeSearch-1.1-20200828.html</a><br>
According to SCS2:<br>
<a class="moz-txt-link-freetext"
href="https://ivoa.net/documents/ConeSearch/20260529/WD-SCS2-2.0-20260529.html">https://ivoa.net/documents/ConeSearch/20260529/WD-SCS2-2.0-20260529.html</a><br>
it comes from DALI sec. 5.<br>
<br>
I have a few concerns about making this a MUST:<br>
* why require an integer/long primary key to be converted to a
string, <br>
when the original datatype is already well defined?<br>
The BINARY representation is different (its not just about the
metadata),<br>
and we lose potentially useful datatype information.<br>
* what about tables with no simple primary key (e.g. PK = 2
FKs), <br>
or with an internal record number that the data provider would
prefer not to expose)?<br>
One such example is the identifier of the Tycho2 catalog:<br>
<a class="moz-txt-link-freetext" href="https://vizier.cds.unistra.fr/viz-bin/VizieR?-source=I/259&-to=3">https://vizier.cds.unistra.fr/viz-bin/VizieR?-source=I/259&-to=3</a><br>
which is the combination of the TYC1, TYC2 and TYC3 columns.<br>
<br>
For these reasons, I would prefer a SHOULD rather than a MUST
here.<br>
This would still recommend providing a unique identifier when
appropriate.<br>
<br>
<br>
</p>
<p
class="x1yc453h x1hpqcdg x1ekroe6 xutxfr x1fie51u xgyxj25 xkyrhof x1elgs31 x1fv8qjw x1tbvfm1 xb72syl x1iew0xx x1c2l018 x14l7nz5 xuw7688 x1pjt2rx x160d6zm xrxpjvj"
dir="ltr">In conclusion, I tend to think that SCS should remain a
low-barrier protocol in the VO.<br>
Even when functionalities are optional, they inevitably make the
standard more complex,<br>
and there is a certain frustration in having functionality defined
in the standard but not <br>
implementing it.<br>
I understand that updating an existing standard is generally
simpler than defining new ones.<br>
However, I do think there is room between SCS and TAP for
additional, more focused standards:<br>
for example, one for single-table positional access, an extension
of SCS (possibly including<br>
multi-cone searches, provided we limit their use to a "small"
number of potentially large cones),<br>
and perhaps one for simple cross-matches.</p>
<p><br>
</p>
<p>Best Regards.</p>
<p><br>
</p>
<div class="moz-cite-prefix">Le 15/09/2026 à 08:44, Markus
Demleitner via dal a écrit :<br>
</div>
<blockquote type="cite"
cite="mid:53gvtgp4bwo6jkt5wjcgz2amiltdzvmuw475qff4bwmgz54euz@3segnizw7nvj">
<pre wrap="" class="moz-quote-pre">Dear DAL folks,
On Mon, Sep 14, 2026 at 04:09:37PM -0700, Patrick Dowler via dal wrote:
</pre>
<blockquote type="cite">
<pre wrap="" class="moz-quote-pre">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.
</pre>
</blockquote>
<pre wrap="" class="moz-quote-pre">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:
</pre>
<blockquote type="cite">
<pre wrap="" class="moz-quote-pre">multi-cone : why not ? But what does it means ? Do we expect a
« union « Or a « union ALL » (so accept repetition or not).
</pre>
</blockquote>
<pre wrap="" class="moz-quote-pre">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
</pre>
</blockquote>
<div class="moz-signature">-- <br>
<p
style="font-family: Arial, sans-serif; color: black; font-size: 14px;"><span
style="font-weight: bold">Francois-Xavier Pineau</span><br>
Ingénieur de Recherche<br>
Tél : +33 (0)3 68 85 24 14,<br>
<a href="mailto:francois-xavier.pineau@astro.unistra.fr"
title="Contacter francois-xavier.pineau@astro.unistra.fr"
class="moz-txt-link-freetext">francois-xavier.pineau@astro.unistra.fr</a><br>
<br>
Centre de Données astronomiques de Strasbourg (CDS)<br>
11, rue de l'Université - E03<br>
<br>
<br>
</p>
</div>
</body>
</html>