[Dachs-support] Some pars in the //obscore#publishSIAP mixin.

[Markus Demleitner]

Hi Yan,

On Tue, Aug 24, 2021 at 04:50:15PM +0200, Yan Grange wrote:
> I think I fixed it by binding the paramters in in stead of defining them at
> the mixin level!

Yes, that's exactly how it's supposed to be one (modulo some
convenience facilities).  For the benefit of the audience, let me try
to explain how the SIAv1 things are supposed to work together:

(a) To make a SIAP table, you mix in //siap#pgs -- this furnishes the
table with all the columns necessary for correct SIAP responses.

(b) At least in the normal case of local FITSes, in the rowmaker you
use the //siap#computePGS (computes the coverage and various other
fields from a WCS header) and //siap#setMeta (lets you bind the other
parameters) apply-s.  //siap#getBandFromFilter is another nice
convenience that lets you get away with just specifying the filter
and let DaCHS work out the numerics from a built-in filter list;
DaCHS doesn't know your radio bandpasses, though, but this might be a
good opportunity to add them to
http://svn.ari.uni-heidelberg.de/svn/gavo/python/trunk/gavo/resources/data/filters.txt.

(c) The //obscore#publishSIAP mixin doesn't do any mapping *into* the
SIAP table (mixins almost never do, as that's the job of the
rowmakers -- but of course there are exceptions that I'll not bother
you with now).  Instead, it maps the existing columns *onto* the
obscore schema. Less mysteriously put: It adds a fragment to the
obscore VIEW for the current table.

I suppose step (b) is what made things a bit confusing in your case
because without local FITSes, this requires quite a bit more
fiddling.  At least //siap#setMeta, being a nice checklist for what
you ought to put in, should still be useful, perhaps with a dash of
var-s sprinkled in.

Oh, and:

> On 23/08/2021 17:24, Yan Grange wrote:
> > use yet (still gettting the data for those). The bandpass name and
> > pixelflags however seem not to be specifyable. Am I holding it wrong? Is
> > there a way to get rid of the columns alltogether since they only
> > contains N/As anyway (or put their verbosity to a level that makes them
> > mostly hidden)?

In principle, you *can* change verbLevels using the usual trick of
re-defining protocol parameters,

  http://docs.g-vo.org/dachs/howDoI.html#override-metadata-for-a-column-coming-from-a-mixin

However, if you do something like

  <column original="pixflags" verbLevel="30"/>

it's likely you'll break your SIAP response (off the top of my head,
not in this case), because the column will be missing in the default
responses.  So, don't do that.

Instead, to suppress boring columns in browser services (or have
extra magic columns), just define an extra service that has an
outputTable set.  I find I generally don't do that for SIAP services,
though, as most of the time the default response schema halfway works
for me in the browser.  That's definitely not the case for SSAP, and
so I'm generally supplying extra browser services there. An example
for how I'm doing this kind of thing would be

http://svn.ari.uni-heidelberg.de/svn/gavo/hdinputs/flashheros/q.rd


> > I am not sure if this is yet another reason to get our dachs instance up
> > to date, but if that's the answer let me know too :).

While keeping your DaCHS installation current is always a good idea,
in this case there's no need to worry...

         -- Markus