SIA 2.0 POS parameters

[Walter Landry]

Markus Demleitner <msdemlei at ari.uni-heidelberg.de> wrote:
> 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.

Some datasets (e.g. planetary) can not be transformed to ICRS.  So we
are going to have to handle different coordinate systems anyway.

<snip>

> 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).

This is a minor point, but I do not follow here.  RANGE's have
problems, but a BOX maps directly to a POLYGON.  It may need to be
rotated, but that is no worse than converting the points in a POLYGON.

> 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.

If I understand you correctly, you do not want to allow annotating
each geometric object with a coordinate system.  However, you would
not object to a global switch that says "interpret everything I give
to you as in a particular coordinate system".  Is that a fair
statement?

I would be fine with that.  I would expect that if a user has multiple
coordinate systems in a query, they are not too averse to doing
coordinate transforms.  It is the people who only 'think' in Galactic
who would just flip that switch.  For them, doing transforms could be
quite onerous.

We would still have to grapple with all of the issues you outlined
with respect to discovery, but I think that is inevitable.

Cheers,
Walter Landry