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

[François Bonnarel]

HI Markus, all
Le 22/07/2013 09:52, Markus Demleitner a écrit :
> 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?
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.
The cutout service will provide the minimal bounding box enclosing this 
Area. Cutout function is by definition without resampling. It's just 
copying the pixels restricting the output to this box.
    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 case
> 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?
See above this will not happen
>
> Incidentally, this is compounded by the aggregate functions (SUM,
> AVG) you're proposing -- again, these can only be computed after
> resampling the whole mess.
>
We are building a prototype. Cutout doesn't come alone in all case. It 
may be combined with summing or averaging (along the spectral axis). I 
don't see any resampling there at the moment.
> So, why require server-side transformations? Racking my brain, I
> could come up with those:
>
> (1) Let clients use their preferred coordinate system
their starting point can come from another query. Which Coordinate 
system will have this starting point.
> (2) Let servers keep the coordinate system their data comes in
OK, see below
>
> 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.
For cutouts, the only thing which has to be recomputed is the polygon 
vertices and arcs (if it is a polygon). Then you look for the minimal 
bounding box without touching the pixels.

Later we can imagine accessdata services providing some 
regridding/resampling, but that's another story, another functionnality.
> 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.
One use case for doing that (resampling/regridding) at the server side: 
imagine you want to realign small parts of huge cubes along the axes of 
your proprietray data . You will not download the huge cube ti compare 
and resample. let's the server(s) do it for you. But again that's no 
more cutout, that's another functionality.

Best regards
François
>
> 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).
>