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

[Mark Taylor]

On Mon, 22 Jul 2013, Markus Demleitner wrote:

> 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
...
> 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 a client author, and hence someone with a vested interest in
keeping the client's job simple at the expense of effort on
the server ... I still agree with Markus.  It's easy to do on the
client, and hard to do on the server, so the protocol should be
defined in a fixed coordinate system (if it's not a fully variable
one as per Markus's point (2)) such as ICRS, like it is in Cone Search.

With one choice of coordinate system, you know what you've got to do:
transform to/from it.  If there are multiple choices the client code
probably becomes more complex rather than less: work out if your
coordinate system is one of the four favoured ones, if so phrase
the query using the right one of those, otherwise choose one
(at random?) that is and do a coordinate transformation to/from that.
And the server-side code, which is much more complex, now has multiple
different pathways which may harbour different bugs, or quite likely
not all be implemented.

Mark

--
Mark Taylor   Astronomical Programmer   Physics, Bristol University, UK
m.b.taylor at bris.ac.uk +44-117-9288776  http://www.star.bris.ac.uk/~mbt/