Coordinate system in ADQL

[Markus Demleitner]

Hi Gilles,

On Thu, Oct 17, 2019 at 03:25:50PM +0200, gilles landais wrote:
> If coordinate system in option is rejected, we could also add a function
> such as the function proposed by Markus in Gavo to make possible the change
> of coordinate System:
> 
> gavo_transform(from_sys TEXT, to_sys TEXT, geo GEOMETRY) -> GEOMETRY
> 
> 
> So, I ask IVOA people to consider this capability as a ADQL standard (as a
> function - may be optional).

The current proposal is to have a list of common UDFs in a separate
list rather than in the ADQL spec itself, and I guess the ADQL
editor(s) will be grateful if we try to keep it this way.  

A proposal for that separate list is in
http://ivoa.net/documents/udf-catalogue/, and I guess it should go to
RFC after the next TCG.

Which means this is the perfect moment to add a proposal -- if VizieR
and DaCHS agree on this, I'd say that's a good base for making this
and "agreed" UDF and call it ivo_transform.

As usual, the devil is in the details, namely what people can put
into the system strings.  And how they can figure out what systems a
given service supports -- I suppose VizieR will want to support
legacy equatorial systems at various equinoxes, for instance, which
DaCHS at least so far doesn't.

So, here's a proposal for what the UDF catalog might say:

  ivo_transform(from_sys TEXT, to_sys TEXT, geo GEOMETRY) -> GEOMETRY

  The function transforms ADQL geometries between various reference
  systems. geo can be a POINT, a CIRCLE, or a POLYGON, and the function
  will return a geometry of the same type.  From_sys and to_sys must
  be literal strings (i.e., they cannot be computed through
  expressions or be taken from database columns). 
  
  Note that the epoch is not changed by this function (i.e., no
  proper motions are applied). 
  
  Where services support reference frames from the IVOA vocabulary
  of reference frames (http://www.ivoa.net/rdf/refframe), terms
  from that list should be used in from_sys and to_sys.  The
  description of the TAPRegExt feature declaring support for
  ivo_transform should enumerate the frames supported by a service.
  Using an unknown frame should be an error, and the accompanying
  error message should again enumerate the strings understood by a
  service.

Pointing to the refframe vocabulary certainly isn't good enough for
frames that need an equinox.  We could leave that to the services,
but then it's probably better if we can give some sensible
guidelines.  I could see either

  Referencence frames requiring an equinox append it after a single
  blank.  Use B to indicate a Besselian, J to indicate a Julian
  epoch, e.g., "FK4 B1950" or "FK5 J1975.0"

(which would provide maximum flexibility) or

  For legacy reference frames, it is recommended to just use the
  equinox with B indicating a Besselian, J to indicating a Julian
  epoch.  

This latter thing would help with, for instance I/122/bd a.k.a.
Bonner Durchmusterung -- though, of course, you could name its
(popular, in its day) frame in the first scheme by saying EQUATORIAL
B1855.0 just as well.

Out of curiosity: Gilles, do you have any idea on how many different
frames there are in VizieR?

           -- Markus