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

[Markus Demleitner]

Dear DAL folks,

On Mon, Jul 22, 2013 at 11:54:12PM +0200, François Bonnarel wrote:
> Le 22/07/2013 09:52, Markus Demleitner a écrit :
> >Dear DAL group,
> >Now, *if* you insist on using STC-S:
[in the CUTOUT parameter]

> >What's the use cases for letting the client specify reference systems
> >in its cutout queries?
> The basic use case you are ignoring is that AstroCoordAreas used in
> the cutout = "STC-S string" may come from the response of a previous
> query.

Hm -- what query would that be?  We're talking about services
operated from datalink here.  So, I imagine the typical query flow
will be:

(1) Client sends obscore/adql query to the TAP service

(2) TAP service replies with a table containing the location of matched
data (which, IMHO unfortunately, is in STC-S, true) *and* a datalink URL

(3) Client retrieves the datalink URL from the datalink service

(4) Datalink service sends the retrieval options (what axes are
available, what limits on the axes, and also what alternative
representations, what related data products exist) to the client

(5) Client presents some representation of those retrieval options, in
particular possible cutout limits, to the user

(6) User defines the cutout

(7) Client sends the cutout request to the data service

(8) Data service delivers the requested data

Note that STC-S only turns up in step (2) to define what's already
covered.  That information is long irrelevant by the time the cutout
service is operated in step (7)

You could, of course, argue that you may want to use a result of step
(2) for *one* query to operated a *different* cutout service.

Well, to that I can only say that the client needs to parse the STC-S
string anyway to compare to the datalink description from step (4)
("does this dataset contain data for my region of interest?").  It
seems weird to me to require the client to re-assemble the parsed
data to an STC-S string only to have the server re-parse it.

Please keep in mind that this is not a data discovery query -- steps
(3) to (8) by necessity know quite a bit of each other.  Exploiting
that knowledge is good, and it doesn't seem to make a lot of sense to
me to enable dialogs like:

Thirsty traveller in Bavaria: "What sizes does the beer come in here?"

Landlord: "Well, you can have a Maß or a Halbe"

Thirsty traveller: "Good.  I'd like to have the quantity of beer that
fits into a 3-sphere of diameter 2 attoparsec"

Landlord: "Here's your Maß"

Wouldn't it have been much more useful if the Landlord had said
"There's a litre and half a litre"?  And the traveller "I'll take the
litre"?

>    Suppose you get the footprint of a catalog of galaxies in a
> distant cluster. This is available as an STC-S string. The cutout
> asked for this Area will provide you with a sub-cube (or sub-image)
> including this Area. You can  easilly imagine variants of this sue

Hm, given that it looks like IVOA footprints appear to be gyrating
towards MOC, that seems to me a use case not strong enough to warrant
a significant complication of the protocol.  As I said above: clients
that want to do this kind of thing will have some internal
representation of their region of interest, and since that certainly
will *not* be STC-S we can use whatever makes the protocol maximally
simple and robust.

In another mail, Tim Jenness <tjenness at cornell.edu> wrote:

> Yes but I was under the impression that accurate FK4 to FK5 also needed the
> epoch of the FK4 measurement.

FK4 rotates with respect to FK5 and ICRS, so yes, strictly that's
true; there's additional subtleties involved if you want to be
accurate, and once there's motion involved things become extremely
messy.  This is why I said that *if* we want this kind of thing we
must define exactly what transformation we mean.  I guess the general
feeling was the precision doesn't matter too much, in which case some
Euler angles are probably ok.

And in case anyone wonders: in STC-S "FK4" means "FK4 at equinox
B1950.0" and "FK5" "FK5 at equinox J2000.0"; many of the STC-S strings
floating around also use the aliases "B1950" for FK4 and "J2000" for
FK5.

Finally, there was the mail with id
<51EE0490.4090206 at astro.unistra.fr> by Francois in which he asked
Mark:

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

Since I'm quoted here I'd like to stress that I don't actually say
"should" -- I'm just saying the two choices I see are "single common
system" and "dataset-defined system".  I admit that I have a slight
preference for the dataset-defined system since that would make the
cutout services very simple ("cut out x to y on axis z"), but I'd say
it's hard to make the call before we have a client/server system
actually working; the problem with this plan is that you'd need to
transmit full system metadata in the datalink response.  Maybe that's
necessary anyway, but if not, the single common system becomes much
more attractive again.

Cheers,

       Markus