SODA, remaining gripe collection

[Markus Demleitner]

Hi James, Hi DAL,

On Fri, Apr 08, 2016 at 08:48:04AM +0000, James.Dempsey at csiro.au wrote:
> > (3) RA and DEC
> > 
> > The stylesheet really needs to know where it is looking in order
> > to generate a UI.  The easiest way to achieve that is by adding
> > RA and DEC parameters.  True, this is a bit tricky at the
> > stitching line (easily solved by allowing RA<0) and at the pole,
> > which is ugly, but unavoidable with POS, too, since RA and DEC is
> > essentially just a rationalisation of POS' RANGE.
> 
> This approach would certainly work for many cases but in cases
> where we have an image that covers either of the celestial poles I
> don't think it could accurately describe the extent. 
> 
> The simple outer bounds approach also has problems as images away
> from the celestial equator will not be square when projected into
> the equatorial coordinates. See
> https://confluence.csiro.au/display/~dem040/Equatorial+Coordinates
> for an example of the effect. That simply means that for larger
> images you could specify a cutout which is within the listed bounds
> but does not intersect with the image. 

While I'm not worried about occasional empty responses -- they can
happen for so many reasons, in particular with "odd" coverages (WPFC
or CALIFA are nice examples), the poles are certainly sore spots;
that's not only true for RA/DEC but for anything that directly uses
spherical coordinates.

The only solution I can think of -- and it's conceptually also
employed by FITS WCS -- is to go through the tangential plane.  This
would be more straightfoward if intervals were specified as center
and extent, as I had proposed back in Madrid when I had tried to sell
the atomic parameters.

Since we've now decided to go with (homogeneous) intervals, we have
to be a tiny bit more subtle.  Essentially, for RA and DEC we'd have
to say:

  RA and DEC (and potentially coordinates in other spherical
  coordinate systems) are given in the tangential plane with the
  center of the imaged area as the tangent point (in effect, they are
  given before FITS WCS's RA--TAN and DEC-TAN projection).

[a non-normative appendix showing the (simple) computation for a
normal FITS header might help avoid implementation errors]

Admittedly, my service doesn't do that right now, because the back
end re-uses some naive code, but indeed the implementation becomes (ok,
I've not actually done it yet, so there's a shard of conjecture in
this) a good deal easier at least for almost all optical images,
which are already in TAN projection -- you're saving the projection,
and you can directly use CDn_n and do your computation in 2D
cartesian.  The slight downside is that the ranges given might
confuse astronomers seeing the raw values (including DECs outside
[-90..90]).  Which I claim is acceptable; most astronomers actually
speaking protocols should be familar with the gnomonic projection.

And of course almost any other scheme, including our CIRCLE, if we
somehow transmitted the image location using appropriate parameter
metadata for CIRCLE, in effect uses the tangential plane, too.

Oh, there's another downside I should mention, and that is that
cutouts larger than half the sky won't work.  But for one I'd say
that's beyond SODA's reasonable field of applicability, and SIAP2's
POLYGON (currently) has the same limitation.


> > But anyway: Perhaps we should defer the whole multiple param thing until the
> > next version?  I see some urgency for enumerated params, but perhaps even
> > that can still wait.
> > 
> 
> We???ve found the multiple parameters extremely useful for
> scripting. Working within the UWS standard we provide a set of
> parameters endpoints which allow the parameters to be built up and
> then evaluated as a set at runtime. The client can then specify a
> set of IDs and a set of cutout criteria and get any cutouts which
> satisfy the criteria. I???ll share some of those scripts next week.
> All of our cutouts are currently provided by async services only as
> we may need to pull the files in from tape if they haven???t been
> used in a while. 

So, pulling from tape is another use case for async which, at the
same time, might not necessarily mean people would want to implement
multiply-valued parameters (or perhaps not all of them).  Which in my
view is rather an argument against the mandatory multiplicities.

That we'll have to have *some* way to eventually specify parameter
multiplicities I have no doubt about.  I strongly believe something
like PDL in VO-DML will nicely fit this *and* solve quite a few other
problems I see -- it's just that it's not there yet.  So, the picture
for me remains that there are three ways out:

(1) Defer, and for the time being not provide machine readable
declarations and instead rely on the user's common sense (in the case
of enumerated parameters) or human interpretation of parameter
descriptions ("This parameter can be repeated").  Since you mention
scripting: This is presumably something that's not happening ad-hoc,
so the users can be assumed to have, perhaps, read some
natural-language text and perhaps don't need the information
machine-readably right now.  So, I'd suggest that your use case might be
covered without SODA 1.0 saying anything about multiplicities.

(2) Hack -- we could invent an ad-hoc way to mark up multiplicities,
perhaps via a GROUP referencing the repeatable parameters.  Such a
GROUP-based hack would technically be fairly similar to what the
clean solution with VO-DML would look like, so once we fix things
clients wouldn't have to be completely re-written and, in effect,
just employ another way of identifying the said GROUPs.  I'd not like
that because it once more relieves the pressure to build a proper,
VOTable-embeddable PDL, and we simply need something like this for
many reasons.  But if we absolutely have to have multiplicities in
1.0, this would be my choice.

(3) Prescribe -- say in the spec which parameters can be repeated and
which cannot.  I don't like that not only because there may be good
reasons for async without wanting to admit multiple cutouts (say),
but also because it won't help for "custom" parameters, and in the
evolution of SODA, the discussion about multipliticies will ensue
every time a new parameter comes in.

And that's how I come to prefer (1).

Cheers,

       Markus