Reflections on SIA V2 and generic cutout services

[François Bonnarel]

Hi Markus, all
Only one point
Le 08/03/2016 10:08, Markus Demleitner a écrit :
> Hi Tom,
>
>
>>    - The spatial subsetting is not well defined.  E.g., if I'm asking for a
>> spatial subset where I've given  POS=CIRCLE 12 34 0.5 what do I get back?
> Well, services are supposed to take the bounding box within their
> native coordinates.
The current draft says it is in ICRS . It says also that we may plan to 
have variable Coordinate System in next version

SODA 1.0 is very basic. There are strong reasons for that.

Cheers
François
>    But sure, for this and many other reasons
> (they're on my list of gripes), SODA really needs to support RA and
> DEC, plus, once we can properly declare STC metadata in VOTables
> again, limits in the native coordinate system.
>
> RA and DEC, anyway, IMHO are indispensible when there's spatial data
> involved, if only for an immediate (if rough) indication of the
> dataset's spatial footprint.
>
>> Do I get back a list of pixels that are within (or partially within) that
>> circle?  Do I get back a rectangle that encloses that circle? How is such a
>> rectangle defined?  What coordinates, projection?  The last bit is probably
> Phewy, and I thought I was the only one finding POS... in need of a
> lot of words.
>
>> What I could see working is defining a service that is simultaneously a SODA
>> and SIA service.  That would imply that the SODA parameters should have
>> distinct names from the SIA names. Specifically for image cutouts there
>> should be some way that the SODA POS could be inferred from the SIA POS
>> fields.  The actual meaning of the cutout for a given POS field would also
> No, *that* I don't like.  In case of a true mosaicing service, I
> could see a pure datalink/SODA service, but even then I'd advocate
> having a SIA service in front that always just returns one (or
> however many mosaics you have) datalink -- for the simple reason that
> we don't want to multiply the discovery options.  It's bad enough
> that we have ObsTAP and SIAv2 (and SSA) in parallel. We should avoid
> to force clients to look for SODA services on top.
>
> Cheers,
>
>            Markus