STC-S (with a view to DataLink)

[Markus Demleitner]

Dear DAL list,

On Tue, Jun 25, 2013 at 08:23:30AM +0000, Tim Jenness wrote:
> 
> On Jun 24, 2013, at 11:57 , Markus Demleitner <msdemlei at ari.uni-heidelberg.de> wrote:
> 
> > Well, from the answers, frankly, I've not been able to pull many
> > arguments against what I called "structured parameters", i.e., X_MIN
> > and X_MAX for intervals (and possibly more of this type).
> > 
> 
> Sorry for the stupid questions, but when we talk of min and max RA
> for the poles do we say min == max? Or do we simply take note of a
> dec max of 90? This is much easier with an ra/dec and a radius (and
> presumably how cone search works)

That certainly is not a stupid question, and it points to the issue
that there's various flavours of coordinate systems -- cartesian, but
also weird curvilinear ones; intervals "kinda work" for all of them,
being explicit about them is a *major* effort in analytical geometry.

However, saying "a pair of spherical coordiates obviously has a very
prominent meaning for astronomy and hence deserves special handling"
probably is warranted because of the special behaviour at the poles
and at the stitching line.

If we decide we need this (and I'd consider this fairly likely), I'd,
however, much rather (conceptually) follow the SIAP route and define
a center plus size rather than center plus radius since our formats
very typically will be much more suited to nearly rectangular shapes.

While I'm wasting your time again, may I comment on one other thing
from Mark's mail
<alpine.LRH.2.00.1306241506350.30348 at andromeda.star.bris.ac.uk>:

> That is, I would favour
> 
>   <PARAM name="INPUT:REGION">
>     <DESCRIPTION>
>       Region of query; use STC-S v1.33 as described in
>       http://www.ivoa.net/documents/Notes/STC-S/
>       but it's only for regions on the sky, Convexes are not supported,
>       and for goodness sake don't specify a reference position
>       on one of the outer planets.
>     </DESCRIPTION>
>   </PARAM>
>
>over
>
>   <PARAM name="INPUT:REGION" datatype="char">
>     <PARAM name="param-type" value="STC-S"/>
>     <PARAM name="stc:version" value="1.33"/>
>     <PARAM name="stc:shapes" value="PositionInterval,AllSky,Circle,Ellipse,Bo
>x,Polygon"/>
>     <PARAM name="stc:axes" value="space"/>
>     <PARAM name="stc:refpos" value="GEOCENTER,BARYCENTER,HELIOCENTER,TOPOCENT
>ER,GALACTIC_CENTER,EMBARYCENTER"/>
>     ...
>   </PARAM>

-- and so would I, if the client only operates on a single service
and provides a user interface exactly to it.

If, however, the use case would be "Just get the vicinitiy of the H
alpha line from all matching spectra in my all-VO-search (where the
underlying services support DataLink cutouts, that is)", the client
needs to figure out *how* to communicate "Cutout between 650 and 670
nm" to any of a potentially large set of services -- and that without
bothering the user to figure that out by reading and understanding
natural-language descriptions.

What Mark shows above in his example is exactly my point: It's nigh
impossible to define useful metadata that would allow this kind of
thing for a useful subset of STC-S.  And that's why I'm pleading to
try and avoid using STC-S like that.

Cheers,

         Markus