SIA 2.0 POS parameters

[Patrick Dowler]

TL;DR -- Extensive experience has shown that including the coord system 
metadata with the values in TAP (ADQL functions and values in the result 
table using STC-S) was a mistake that needs to be fixed. The first rule 
of fixing a mistake is to stop doing it!! In previous Interops, we 
discussed this w.r.t. SIAv2 and agreed that the param values should 
*not* include coordinate system metadata.

PS-I did make a note for myself at ESAC to figure out a way to enable 
use of the SIA spec where the fixed system (ICRS) wss not applicable: 
planetary data specifically since this seemed to be the only issue 
stopping that community from using it. I'll try to figure that out this 
week and post it. In the mean time, assume all values are in a fixed 
system/units/etc.


More comments below on some details:

On 30/06/14 10:37 AM, Walter Landry wrote:
> Jose Enrique Ruiz <jer at iaa.es> wrote:
>> Hi Walter, DAL
>>
>>
>> 2014-06-27 22:24 GMT+02:00 Walter Landry <wlandry at caltech.edu>
>>>     This would also make the Range geometry more useful.  There are not
>>>     that many things that align themselves along lat/lon lines in ICRS.
>>>     Though to be honest, I would be happy enough to get rid of Range.
>>>     Polygons and Box (see below) would cover most of the use cases.
>>>
>>
>> In the case of discovery (SIA 2-0) I understand that the response/output
>> image of a discovery query does not need to be aligned with any geometry.
>> POS is intended to define the spatial dimension of ROI for *discovery*. In
>> the case of AccessData I agree RANGE is not very useful for cutouts, like
>> CIRCLE I think it's better suited for discovery purposes.
>>
>> This reminds me that it would be good to define in the SIA 2-0 specs ,the
>> degree of intersection between ROI and the response image.
>
> I do not understand.  For discovery, it is simple enough to create a
> polygon with the four corners.  The main difference is that the
> corners will be joined by great circles rather than lines of constant
> latitude.  I do not see how that would cause a problem.
>
>>> 3) Why isn't there a Point geometry?  I can specify a circle with
>>>     radius zero, but that is awkward and un-intuitive.

The CSP use cases never mention searching by point. Technically, they 
also don't mention searching by range or polygon either but I wanted to 
include those in the design specifically because (i) polygon is 
inherently a variable-sized construct and it was unacceptable come up 
with a parameter design that could never support it and (ii) range is a 
common expectation and plays the same role as POS and SIZE in SIAv1, so 
we aren't losing a feature.

As for point, when I ask people that study astronomical objects (eg 
galaxies) they always say they want circle (for both discovery and 
cutout!!) and they know how big to make them. I agree that point makes 
sense, but it turns out to not be very useful in practice. However, it 
could be added in a minor revision if we find a compelling reason.



-- 

Patrick Dowler
Canadian Astronomy Data Centre
National Research Council Canada
5071 West Saanich Road
Victoria, BC V9E 2E7

250-363-0044 (office) 250-363-0045 (fax)