dal Digest, Vol 119, Issue 9

Tue Oct 22 14:51:48 CEST 2019

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) -
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 ?

And what about crossmatch? is it expected (recommended? required?) to 
make the change of coordinate in background?
(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 ?

About the ivo_transform function : I am agree with the gavo syntax 
including the equinox (in option).

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

Today,  we computed ICRS column for VizieR tables - but not for all.
The change of coord. syst. in TAPVizieR is based only on the system 
without equinox. .. So, there are ~ 100 tables not treated yet  which 
could be fixed with equinox.

Gilles

On 18/10/2019 12:00, dal-request at ivoa.net wrote:
> Send dal mailing list submissions to
> 	dal at ivoa.net
>
> To subscribe or unsubscribe via the World Wide Web, visit
> 	http://mail.ivoa.net/mailman/listinfo/dal
> or, via email, send a message with subject or body 'help' to
> 	dal-request at ivoa.net
>
> You can reach the person managing the list at
> 	dal-owner at ivoa.net
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of dal digest..."
>
>
> Today's Topics:
>
>     1. Coordinate system in ADQL (gilles landais)
>     2. Re: Coordinate system in ADQL (Markus Demleitner)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Thu, 17 Oct 2019 15:25:50 +0200
> From: gilles landais<gilles.landais at astro.unistra.fr>
> To:dal at ivoa.net
> Subject: Coordinate system in ADQL
> Message-ID:<79fe4511-1097-e316-dcfb-6af521582188 at astro.unistra.fr>
> Content-Type: text/plain; charset="utf-8"; Format="flowed"
>
> Dear IVOA members !
>
> Following the last IVOA meeting and about the new ADQL version.
>
>
> Coordinate System had been deprecated from the ADQL region. This
> capability was may be not very used, and was may be ambiguous. However
> to change the coordinate system was used in VizieR.
>
>
> Moreover, there is not today a pivot coordinate system used for all
> tables in all data-centers. I am agree that coordinate System could be
> an option, but in my opinion, to remove it without any alternatives will
> impoverish ADQL.
>
>
> 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).
>
>
> Regards,
>
> Gilles Landais (CDS)
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:<http://mail.ivoa.net/pipermail/dal/attachments/20191017/0d7a4b6d/attachment-0001.html>
>
> ------------------------------
>
> Message: 2
> Date: Fri, 18 Oct 2019 09:59:35 +0200
> From: Markus Demleitner<msdemlei at ari.uni-heidelberg.de>
> To:dal at ivoa.net
> Subject: Re: Coordinate system in ADQL
> Message-ID: <20191018075935.pxt2hfua5ixv5gg5 at victor>
> Content-Type: text/plain; charset=utf-8
>
> 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
>
>
> ------------------------------
>
> _______________________________________________
> dal mailing list
> dal at ivoa.net
> http://mail.ivoa.net/mailman/listinfo/dal
>
> End of dal Digest, Vol 119, Issue 9
> ***********************************

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/dal/attachments/20191022/ee0c002e/attachment.html>