SIA 2.0 POS parameters

[Walter Landry]

Patrick Dowler <patrick.dowler at nrc-cnrc.gc.ca> wrote:
> 
> 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.

Is this reasoning written down somewhere?  Otherwise it is hard for me
to understand it.

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

Range has different semantics from SIZE in SIA v1.  That is why I
proposed the Box shape.  As I mentioned earlier, Range does not seem
useful.

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

There are plenty of people who look at point sources.  Since SIA v2 is
not confirmed yet, why don't we just add it to the spec now?  I can do
the work for that if you like.

Cheers,
Walter Landry