SIA 2.0 POS parameters

[Markus Demleitner]

On Mon, Jun 30, 2014 at 11:29:27AM -0700, Walter Landry wrote:
> Patrick Dowler <patrick.dowler at nrc-cnrc.gc.ca> wrote:
> > 
> > TL;DR -- Extensive experience has shown that including the coord
> > system metadata with the values in TAP (ADQL functions and values in
> > the result table using STC-S) was a mistake that needs to be
> > fixed. The first rule of fixing a mistake is to stop doing it!! In
> > previous Interops, we discussed this w.r.t. SIAv2 and agreed that the
> > param values should *not* include coordinate system metadata.
> 
> Is this reasoning written down somewhere?  Otherwise it is hard for me
> to understand it.

Since this is something I've struggled for for quite a while, let me
not-so-briefly chime in:

The main reason is: Interoperability.  There are others, too.

SSAP and TAP/ADQL kind of supported essentially arbitrary frames.
Which was the first problem: What frames are actually supported on a
given service?  We came up with ways to discover that for both SSAP
and TAP, but I'm not aware of widespread take-up.  But even if it is
discoverable, if you want to do multi-server queries, having to
transform for some services and not others is a major pain for the
clients, much worse than just transforming to ICRS once and using
that on every service.

Then there was the issue of how to come up with a common vocabulary
of frames, since even if you can discover names, clients have to have
a way to figure out what they mean.  Sure, there's STClib, but
invariably people started to haggle about syntaxes, and in the end
there was considerable confusion, in particular with ADQL, reaching
into TAP.  Also, given that much simpler features often are not
correctly implemented, I doubt that even a subset of STClib would
gain much reliable support.

If we tried agreeing on what frames RFC-MUST be supported, I suspect
the result would end up being ICRS and GALACTIC.  This happens to be
a simple rotation that clients that need it can really do themselves.
Most things more complex can't really be done reliably on the server
based on just coordinates, as, for instance, FK4 rotates against
ICRS, and thus you need epoch information to do the transformation.
ECLIPTIC is useless when it doesn't come with an equinox (as are FK5
and FK4 unless you start fixing FK4 to B1950 and FK5 to J2000, which
begs the question why you'd bother in the first place).

I'd also claim that for such a feature to be useful, the server would
in many interesting cases have to know at least proper motions and
epochs, possibly, as when reference positions enter the fray, even
distances and radial velocities (although I give you that
foreshortening probably is not terribly important in discovery
protocols).  In planetary sciences, things are even worse.

I could go on about the semantic troubles of frames in ADQL (should
CONTAIN and friends conform the coordinates?) and the fact that
in-database coordinate transforms (or course wrecking all index use)
are required.  And many other snags.

But the upshot is: Coordinate transformations done right are too hard
for the server side, and done lamely are useless at best,
interoperability bombs at worst.  Clients with an idea what what
objects they're actually talking about are really in a much better
position to do these kinds of things.  Of course, in ADQL
explicit well-defined transformation functions can and probably
should be provided in the future.

If you, as a custom feature of your server -- where no expectation is
implied other services work the same way --, want frame information
on input, you're free to define as many parameters as you support
(REF_FRAME, REF_EQUINOX, FOR_EPOCH, PMRA, PMDEC,
INCLUDE_FORESHORTENING, CORRECT_FOR_FK4_POLE_CORRECTION,
ASSUME_NEWCOMB_PRECESSION, ASSUME_SLALIB_VERSION...), and you can
even interoperably annotate them using STC utypes (well, some of
them:-).  But at least provide ICRS, implemented correctly, for
whatever geometries we agree upon.

But then -- if the protocols either restricts itself to cones (which
I'd advise) or if it lets you specify polygons (and I'm still not
entriely convinced even that's something clients will be able to rely
upon), there's really no reason I can really see to do server-side
transforms at all -- cones remain cones after transformations, and
polygons remain polygons (which, incidentally, I'd consider arguments
against supporting BOX or RANGE).

Oh, and of course I should at least mention the Golden Rule: Separate
data and metadata whenever you possibly can; this doesn't say
coordinate metadata shouldn't be part of the protocol, yes, but at
least you shouldn't mix frame and the coordinates themselves into one
alphabet soup.

Cheers,

        Markus