SIA 2.0 POS parameters

[Jose Enrique Ruiz]

Hi !
some comments below between the lines..


2014-06-30 19:37 GMT+02:00 Walter Landry <wlandry at caltech.edu>:

> 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.
>
>
Well, my guess is that RANGE is kept in POS param because it provides an
easier syntax, following the same 'slashed' interval notation that the
other input params. I agree most of the queries may be done also with
POLYGON (I do not see right now any spatial coverage that could not be
defined with POLYGON syntax, maybe someone..)



> >> 3) Why isn't there a Point geometry?  I can specify a circle with
> >>    radius zero, but that is awkward and un-intuitive.
> >>
> >
> > I take this a use case for AccessData specs, though right now I can only
> > think on extracting single-pixel spectra from a spectral datacube..
>
> No, this is a use case for SIA.  I want all images that cover a
> source.  Similar arguments apply for all of the other cases you cited
> as applying only to AccessData.
>
>
You're right, maybe because I'm biased by how ROI works with ConeSearch, I
tend to think that the specified/queried ROI always covers the response
image, my fault. This is why I think we need to define how the ROI and the
response image intersect. This param was present in SIAv1, I guess this
will be done in next versions and for the moment assume that the default
behaviour is "overlaps"



> Cheers,
> Walter Landry
>


Cheers !


---
Jose Enrique Ruiz
Instituto Astrofisica Andalucía - CSIC
Glorieta de la Astronomía s/n
18009 Granada, Spain
Tel: +34 958 230 618
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ivoa.net/pipermail/dal/attachments/20140701/bc93b6d2/attachment.html>