Call for proposals for SIAP Version 2

[John Good]

Roy -

> >  Galactic coordinates are pretty important and adding support
> > for these to POS is a reasonable thing to consider.
>
> The more complicated is the specification of conesearch/SIA, the smaller the
> number of implementations! It is the NVO that should build the middleware --
> so that users get a rich set of services, but the entrance cost for
> publishers is low low low.
>
> One way to do the galactic coordinates is to specify SIA in terms of a
> single coordinate system (as it is now), and have a middleware service to
> make the coordinate conversion, which in turn calls the elementary service.

This is dead wrong.   Coordinate syntax parsing, coordinate transforms,
and polygonal constraints (which includes the "cone search" as a single-
constraint subset) are all straightforward and should be an integral part
of any server-side search engine (image or catalog).  NVO should be
promulgating knowlege on how to do this (and portable code snippets,
where appropriate), not characterizing it as a complex issue that needs
third-party middleware.



> > The broader question
> > is do we want to generalize the query region specification,
>
> Similarly, we could have an elementary service specification that uses only
> disks or rectangles, and have middleware to deal with complex regions
> through multiple calls to the elementary service.
>
> Just as programmers in the 1960's learned to combine subroutines as
> components, so the Holy Grail of Web Services is to combine services as
> components. (Your comments welcome).

I admit to a bias here.  I have yet to see a need for anything more complicated
that a convex polygon on the sky as a region definition (i.e. no annuli or other

regions with holes).  With that constraint, I maintain that the following are
all
equivalent (in that a single location-filtering library can handle them all):

   o  Convex polygon in any coordinate system.  This is just
       a set of planes cutting the sphere.  Usually great circle
       planes but just as easily small circles (e.g. latitude lines)

   o  Point-radius "cone" searches (since this is just a single plane)

   o  Box on the sky (if you assume great circles connecting the
       the corners of the box, this is both a four sided polygon
       as above (you just parameterize it differently) and is exactly
       the same as the coverage of a Gnomonic projection (TAN)
       image of the same size.

For many real-world images, connecting corners by great circles is close
enough for coverage checking, so I would maintain that a FITS header
(translated to a box) can also be used as a region definition.



> >  ASU for example specifies a more general syntax, .
>
> Let us ask a specific question then: is is possible to convert an arbitrary
> conesearch service to an ASU service through appropriate middleware?

No.  The cone search service has two major shortcomings and this
inability to deal with regions is one of them.  The other is the lack of
(optional) relational constraints.

Many sites have the ability to apply relational constraints within their
underlying DBMS engine.  For those that don't, a simple filter (preferably
based on SQL "where" clause syntax) applied to their initial output
records (either on the fly in their code or as a post-processing step)
would produce the same result.



> > > A key requirement for this to work is that the service provider be able
> > > to communicate to the client which query elements it can accept. This
> > > will be part of the metadata service request (FORMAT=METADATA).
>
> There is a very general type of conversation that I think we should include
> as part of our service specification. Once we can implement this in a
> general way, it covers a lot of ground.
>
> Waiter: What type of toast?
> Customer: What do you have?
> Waiter: White, wheat, rye, ....
> Customer: Wheat
>
> Note that lines 2 and 3 can be omitted if the customer already knows the
> list of options.

Agreed, and this is exactly the way one should handle the relational
constraint issue above.

- John