[cube access] minutes from telecon (2013-07-03)

[Markus Demleitner]

Dear DAL group,

As a self-appointed KISS[1] advocate, excuse me for chiming in again on
the issue of the design of cutout service interfaces. On why I think
we shouldn't mash multiple parameters together in one string (STC-S)
in the first place, see the mails of a couple of weeks ago -- I still
stand unconvinced that there's any benefit from doing this and
convinced there's a lot of harm, but I won't repeat any of this here.

Now, *if* you insist on using STC-S:

On Tue, Jul 16, 2013 at 12:15:32PM -0700, Patrick Dowler wrote:
> - agreed the scope was just to use STC-S to define the boundaries of
> an (STC term) AstroCoordArea, not other details about pixels, sample
> sizes, etc

This means that cubes having spectral or temporal axes would take
their input from SpectralInterval or TimeInterval phrases, too?  What
about other axes that current STC-S doesn't talk about (polarization,
weird things in theory services, ...)?

But that's just an aside -- my main point is this:

> - define a reasonable subset of STC-S that everyone can support, for
> prototypes we will be strict and only support that subset; STC-S with
> additional phrases will fail (note: the decision on ignoring vs
> rejecting unexpected STC-S phrases will be reviewed later during WG
> review)
> 
> - restrictions: only allow FK4, FK5, GALACTIC, ICRS

Disclosure: I've never liked the notion of server-side coordinate
transformations.  

What's the use cases for letting the client specify reference systems
in its cutout queries?

For cutouts, allowing this is particularly insiduous, since cutouts
along the coordinate axes are no longer rectagular after a
transformation, so services would have to resample, at least provided
the result is supposed to come in the coordinate system requested
(otherwise: What's the point at all?).  Of course, image formats
usually only support rectangles -- should the unwanted voxels be
NULL?  What else?

Incidentally, this is compounded by the aggregate functions (SUM,
AVG) you're proposing -- again, these can only be computed after
resampling the whole mess.


So, why require server-side transformations? Racking my brain, I
could come up with those:

(1) Let clients use their preferred coordinate system
(2) Let servers keep the coordinate system their data comes in

For (1), I'd maintain that's a weak case -- at least between FK5,
GALACTIC, and ICRS[2], the transformation of the input coordinate(s)
is almost trivial and quick (since it's just a few points),
definitely programmable calculator material.  

Conversely, server-side transformations need to touch all pixels,
resample them, etc.  

As to displaying the stuff, clients that do any kind of advanced
plotting will have to have code for projections, resampling, etc
anyway, and I'm fairly sure they wouldn't want to rely on server-side
resampling in the first place.

Furthermore, the limited choice of the four frames above is probably
insufficient to cover that use case.

As to (2), not requiring services to transform their data to a common
reference system is something I can understand and might even
reluctantly support -- it's messy, and as  a data publisher I'd
rather not have to touch the data coming in from the scientists.
However, the four reference frames above probably won't cover that
use case either, on the contrary *forcing* me to touch the data (and,
honestly: Does anyone expect to get cubes with FK4 positions?)

If we want to cover arbitrary reference frames (and I suspect we must
in the end at least for the output in order to guarantee we can
deliver un-resampled data), we'd have to let the server specify its
coordinate system in as much detail as we see necessary.  That would
indeed be a place of STC, but that would be in the metadata of the
service as well as the returned data, not in the input parameters.


The TL;DR is, I guess: Either agree on one single reference system, or
let the server declare its system properly.


Do I miss something?  Are there other use cases?

Cheers,

           Markus


[1] In case anyone's wondering: http://en.wikipedia.org/wiki/KISS_principle

[2] While I'm at it, let me mention that FK4 to FK5 is not
necessarily trivial, so if we require FK4 support, we must define
what we mean, preferably by giving the Euler angles (that's probably
enough as long as we don't propose to transform derivatives and keep
to equinox B1950).