SIA 2.0 POS parameters

Tue Jul 1 07:04:44 PDT 2014

There is no question in my mind that ICRS and GALACTIC are the basic
spatial frames that ought to be available.
However, as to the server's and the client's role, there is a difference
between data discovery metadata and data-accompanying metadata.

I don't think there is any excuse for a service not to keep coordinates
in its database both in ICRS and in GALACTIC. This is a simple matter,
both for catalogs and for image (any dimensionality) or single location
(spectra, light curves) based data. That means that any service ought
to be able to reply to a query in either frame whether it has data available
that satisfy the query and what those datasets are; and BOX or RANGE
queries do not cause any problems.

When it comes to using the data, I think the onus is on the client.
What I mean is that if the service holds, say, images oriented E-W/N-S
(i.e., in ICRS) and the query came in GALACTIC, it is perfectly acceptable
for the service to provide that image as-is, without having to rotate it to
align with Galactic coordinates; that is up to the client.

Cheers,

  - Arnold

-------------------------------------------------------------------------------------------------------------
Arnold H. Rots                                          Chandra X-ray
Science Center
Smithsonian Astrophysical Observatory                   tel:  +1 617 496
7701
60 Garden Street, MS 67                                      fax:  +1 617
495 7356
Cambridge, MA 02138
arots at cfa.harvard.edu
USA
http://hea-www.harvard.edu/~arots/
--------------------------------------------------------------------------------------------------------------

On Tue, Jul 1, 2014 at 5:49 AM, 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.
>
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ivoa.net/pipermail/dal/attachments/20140701/9ccf1582/attachment-0001.html>