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

[François Bonnarel]

Hi Mark,
a question for you.
Le 22/07/2013 12:09, Mark Taylor a écrit :
> 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.
I think Markus says the server coordinate  system of the server should 
be the one in which the data have been produced/released
and you say it must be fixed by the protocol ? Did I miss something?
Typical case is that the data could be in GALACTIC instead of ICRS, and 
everybody would like protocols to speak ICRS

Regards
François
> 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/