SIA 2.0 POS parameters

[Jose Enrique Ruiz]

Hi Walter, DAL


2014-06-27 22:24 GMT+02:00 Walter Landry <wlandry at caltech.edu>:

> Hello Everyone,
>
> I have been looking at the draft for SIA 2.0 and I have a few comments
> about the POS parameters.
>
> 1) POS uses spaces as semantically important elements as in
>
>      POS=Circle 10 10 1
>
>    This makes it annoying to create URL's because you must URL encode
>    the spaces as '+'.  Otherwise my web server (Apache) will strip out
>    the rest of the parameters.  If we instead used ADQL'ish syntax
>
>      POS=Circle(10,10,1)
>
>    with explicit, visible separators, that is not as prone to being
>    mangled.
>
>
I agree with this point.

Though I personally do not like very much how SIAv2 works with types of ROI
input params (specially x-types for numeric values to deal with ranges and
geometries), I could live with that. Nevertheless, I think we could at
least get rid of the spaces for the POS param in the specs.



> 2) POS has no way to specify the reference frame.  I think that should
>    be part of the spec, with the default being ICRS.  Again, straight
>    from ADQL
>
>      POS=Circle('GALACTIC_CENTER',10,10,1)
>
>    I know that some galactic people here would really like that, and I
>    recall a planetary person asking for it at the last meeting.  It
>    would also mean that I can copy and paste coordinates between ADQL
>    and SIA.
>
>
I vaguely recall this was a point of discussion when defining the specs.
Maybe someone could bring us some more light..



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



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



>
> 4) There should really be a Box geometry that lets you specify a
>    center, width, and height.  Otherwise, clients have to do annoying
>    math to get proper boxes near the poles.  For the queries we serve,
>    getting images covering a box is a very common operation.
>
>
As I said previously, I agree with this point wrt. AccessData specs.



> 5) Winding should be specified for polygons.  Making the interface too
> 'smart'
>    leads to surprising outcomes.
>
>
I also understand this point as a special use case for AcessData.



> Cheers,
> Walter Landry
>




---
Jose Enrique Ruiz
Instituto Astrofisica Andalucía - CSIC
Glorieta de la Astronomía s/n
18009 Granada, Spain
Tel: +34 958 230 618
http://amiga.iaa.es/p/67-jer.htm
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ivoa.net/pipermail/dal/attachments/20140630/cfd158cc/attachment-0001.html>