SIA 2.0 POS parameters

[Markus Demleitner]

Hi Walter,

On Tue, Jul 08, 2014 at 11:04:29AM -0700, Walter Landry wrote:
> Markus Demleitner <msdemlei at ari.uni-heidelberg.de> wrote:
> > 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.

Well, *if* you consider planetary images in scope for SIAv2 (which,
as far as I know, is not in the CSP's requirments), that's an issue.

But even if we chose to support, say, planetary surfaces, it would be
a completely different use case.  There's no sensible transformation
between coordinates on Mars and those on Jupiter.  Hence, you'd
rather have another parameter "Search on object X (with whatever
canonical coordinate system defined there)".  That's totally
different from "I give you coordinates in FK4, and when returning
results, please convert to FK4, too".

As a brief aside: If planetary data actually is considered in scope,
please do consider the results of the EUROPLANET project, in
particular, EPN-TAP.  Not that I understand too much of this.


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

Ah -- as long as data and metadata (the annotation) are well
separated and both are well-defined, whether the metadata is
per-thing or per-column is a question of the underlying data model.
I'm mainly arguing against squeezing data and metadata into one
inseparable...  soup, as that will exactly take away this choice.

> 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'd be the first to say coordinate system metadata must be
communicated and it must happen properly (or halfway so, if you let
me indulge in self-citation of a moment:
http://www.ivoa.net/Documents/Notes/VOTableSTC/ in VOTable; VO-DML
will help a lot with this, in particularly with a cleaned up STC DM).

But of course, in the context of a protocol you're doing yourself a
big favour if the servers don't have to deal with this, for reasons I
laid out in the original mail: It's complex business, tricky, and
hard to get right on the server side in most of the interesting cases.

And it'd not only be servers, it'd be clients, too, as I suppose
you'd say that servers can then return data in custom coordinate
systems, too, and all clients would have to support those and be sure
to figure out what they are.  Not that the should not do that anyway,
but it's certainly not what's going on now...

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

... as it would for people thinking in supergalactic or ecliptic or
whatever else fancies your mind.  This is why we design *protocols*:
These people need a (trivial or complex) client, and it's our
responsibility to make sure they're there, in astropy, in Aladin or
TOPCAT, on the command line, within ds9.  From there, they can work
in whatever coordinate system the prefer, and do all the necessary
coordinate transforms they know to be required for their particular
data.

A protocol, on the other hand, *is* no user interface.  UI aspects
enter ("Can a UI discover all it needs to in order to provide good
user experience?"), but user interface design doesn't.  If you design
the protocol based on the question "Can we make the protocol such
that sed and curl are strictly enough for operation?", you'll get
protocols that suck for both sed/curl *and* actual clients.

Cheers,

       Markus