dal Digest, Vol 119, Issue 9

[Markus Demleitner]

Dear Gilles,

On Tue, Oct 22, 2019 at 02:51:48PM +0200, gilles landais wrote:
> This UDF list is interesting in the VizieR context. In particular
> the healpix and proper motion functions.  I think that
> ivo_transform is as important than those already listed with ivo
> prefix (may be more) -

That may be, but it's also an order of magnitude trickier, mainly
because we need name reference systems, say how users figure out
which are there, etc.

I'd rather not burden the initial discussion about the basic
mechanism for UDF management with these details that, in the history
of the IVOA, have too often lead to, excuse me, bike shedding.

This is not to say we shouldn't just go ahead an implement the thing.
If we go by the book, you should probably first write a cds_transform
function, but I don't except anyone will go after you if you call it
ivo_transform from the start; I also expect the rough outline of the
function will be stable enough that early adopters won't be confused
later.

> In fact I expected a standard-ADQL function, but I imagine that you have
> already discussed about that -
> 
> Just to clarify ( when coordinate syst. is not in parameter):  I imagine
> that we use the coord. syst. of the table in ADQL region ?

At least the way gavo_transform works, that can't happen: Users
always have to give both reference frames.

Saying "take frame from local metadata" would have an interesting use
case, namely "let people run the same query with an upload in a given
reference system on different services, making sure operands in a
geometric operation are on the same reference system".

I doubt that's something many people will need in the near future,
but it's not unreasonable either.  I'd say we could say "from_sys can
be NULL, in which case the server fills in the reference system of
the source geometry if available and raises an error otherwise".  Or
should we use something else to be more explicit about "server,
please fill in"?

> And what about crossmatch? is it expected (recommended? required?) to make
> the change of coordinate in background?

No.  Definitely not.  This kind of thing is science, and any sort of
magic computers do is bound to fail in the most interesting ways.
Also, when talking with users I found most of them don't like it when
stuff like this happens behind their backs.

> (and how to proceed when coord. syst. is unknown? (e.g. upload)).
> I haven't seen this point in the ADQL document  - may be it could be useful
> ?

I'd say ADQL as such should provide the geometric primitives.  The
rest -- fixing reference systems (gavo_transform), epochs
(gavo_move_pm), reference positions (I've not dared so far; light
travel correction probably needs interesting code in the database
server to be useful) -- should be done explicitly by the scientists
as long as we don't have strong AI.

> In VizieR, we have ~15 different  coordinate systems with different equinox
> (some are very exotics: e.g.: RAB1770, catalogue J/A+A/567/A26)

Cool.  In a way that worries me a bit on the implementation side.

The upshot: I think it's ok if you implement either cds_transform or
immediately ivo_transform, and based on this we can then put it into
the UDF list 1.1.

Can you live with that?

        -- Markus