How to consume TAP and SIAP for lightcurve survey ?

Markus Demleitner msdemlei at ari.uni-heidelberg.de
Fri Dec 14 00:11:02 PST 2012


Hi Petr,

On Fri, Dec 14, 2012 at 03:31:57AM +0100, Petr Skoda wrote:
> 1) in SIAP there is only input parameter for location and optional
> image generation parameters - I cannot select band and mainly the
> TIME !
> So far all SIAP examples I have found in literature are just showing
> the selection of given field on sky - but not temporal filter or
> spectral filter
> 
> It is written the SIAP (v1.0)  can provide optional parameters
> server-dependent.
> I am sure the time and filter (band) is so important that someone had
> already to solve this problem - can you point me to SIAP service
> implementing his ?
Well, ivo://org.gavo.dc/lswscans/res/positions/siap for example;
in a perfect world, you could look that up in the registry, e.g. by
querying:

select * from rr.intf_param where ucd='vox:image_mjdateobs'

(on the relational registry, available at the endpoint
http://dc.g-vo.org/tap).

Alas, few bother to properly declare this stuff in their registry
records.

You could also try harvesting the services' METADATA responses to
find more, e.g. using this nice shell worm (note that I'm discarding
several URLs in order to make the sed snippet easier):

curl -s -FLANG=ADQL -FREQUEST=doQuery \
  -FQUERY="SELECT access_url FROM rr.capability NATURAL JOIN rr.interface WHERE standard_id='ivo://ivoa.net/std/ssa'"\
  -FFORMAT=text/plain http://dc.g-vo.org/tap/sync \
  | grep "?" | sed -e 's/.*/curl -m20 "&FORMAT=METADATA"/' \
  | sh > allmeta.stuff

Paging through allmeta.stuff isn't always edifying, but there you
go..

> How to filter in Aladin query the bands or time ? I have just seen
This is a much trickier question; as pointed out in the Urbana talk
on SSAP client writing
(http://docs.g-vo.org/talks/2012-urbana-ssapstate.pdf) the main
problem with Metadata responses is that a client cannot know how to
actually write conditions against the parameters declared, since the
type declarations may be lies:  In BAND=23/25, the value most
certainly is *not* a float, contrary to what the datatype on the
PARAM for INPUT:BAND says.

For real-valued parameters, that's a complete showstopper, since
you'll always have to say something like "earlier than".  Is this
done through separate parameters or using some syntax, be it "PQL" as
(recommended) for some of the SSAP parameters, a syntax like
VizieR's, or still something else?

I strongly suspect that's the main reason takeup for evaluating
metadata responses (or input parameters declarations from the
registry) in clients has been, well, how should I say this, moderate.

This would be a good moment to fix it (now that I think of it, such a
fix might have been DALI material, but it's probably too late for
that now).  For the record, I suspect the way to do it would be
"structured names", e.g., dateObs_min, dateObs_max or, if this is
actually seen as necessary, weirdParam_step.  If someone want to hear
my rationale for that, I'd gladly oblige.

Cheers,

           Markus



More information about the dal mailing list