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

Tue Jul 23 03:06:45 PDT 2013

Hello Markus,
Hello Dal Folks
On 23/07/2013 09:01, Markus Demleitner wrote:
> 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:
That's a nice use case. I Just have  a little objection
> (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,
Datalink service in itself will not provide this "per se" but a 
Discovery service (Obstap + ImageDM extensions or SIA2 whatever you call 
it or may interrogate it)
>   and also what alternative
> representations, what related data products exist) to the client
Yes Datalink is for this
>
> (5) Client presents some representation of those retrieval options, in
> particular possible cutout limits, to the user
Yes
> (6) User defines the cutout
Yes
> (7) Client sends the cutout request to the data service
OK
> (8) Data service delivers the requested data
OK
> 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.
Exactly this. The STC-S may have any kind of origin, including queries 
to spectral or catalogue services.
> 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.
It is generally admitted that services can admit queries for data they 
don't contain. they just answer with a "NODATA for these constraint" 
VOTABLE in that case. Otherwise it would be nearly impossible to query 
these services using client scripts in asynchronous mode for massive 
multiple queries.
But in the case of interactive clients of course it can provide the 
functionality you describe.
> 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"?
:-) . That's fun!
>>     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.
Good point. But description of all kind of  AstroAreas in MOC is far 
from being complete and would require changing a protocol like ObstAP to 
be used universally. We could also try to define an STC-S version of 
MOCS to reconcile :HEALPIX is just another projection (purely personal 
opinion)
>   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"),
Yes, For a cutout service that's the only solution.
For A resampling/regridding service it's another story but that's not in 
the scope of the current discussed prototype and will presumably come later.

Cheers
François
>   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
>