Coordinate system conversions

[robertbutora]

We faced a project studying the Galaxy, where the clients were required to operate in GALACTIC coordinates.
The SODA interface mandates ICRS, [WAVE,Barycentric,m]. However we needed GALACTIC, [VELO,LSRK,km/s].
Conversion is needed.
In general, astronomers pointed out that some projects might benefit if data could be accessed via 'few' (2..3)
coordinate systems rather then one fixed.

Would it be possible to standardize coordinate system for (SODA) parameters ?
It would avoid each implementation in need, to come up with its own keywords and coord system encodings.

Sketched example:
Coordinate system could be conveyed by new parameters like POSSYS, BANDSYS, TIMESYS.
Or alternatively be appended as last element of the current parameters (POS, BAND, TIME). For instance

POS=RANGE 10.0 12.0 -1.0 1.0 GALACTIC

Coordinate system names supported by given service-instance could follow conventions (FITS standard or AST lib or other?)
and be enumerated in service descriptor.

Note: include also non-WCS systems like PIXEL-GRID ?

[msdemlei]

On Fri, Mar 22, 2024 at 02:50:37AM -0700, robertbutora wrote: We faced a project studying the Galaxy, where the clients were required to operate in GALACTIC coordinates. The SODA interface mandates ICRS, [WAVE,Barycentric,m]. However we needed GALACTIC, [VELO,LSRK,km/s]. Conversion is needed. In general, astronomers pointed out that some projects might benefit if data could be accessed via 'few' (2..3) coordinate systems rather then one fixed.

Well... someone (either the client or the server) has to do the conversion; experience (e.g. with SSAP, which has such a facility) suggests that adding an *option* to have other frames is a complication that eventually nobody can use. One could *require* support for a set of frames. But does it help? Which client can't do the conversion as well (or better, given it can know the context) as the server? If there really is a use case where a large community and hence a specific subset of services would support a certain kind of cutout, I'd suggest using a different parameter (GALPOS, perhaps?); that way, clients can easily tell whether a SODA service they encounter has this specific capability. Such a parameter could be specified in an IVOA note and migrate into SODA if it proves useful and sufficiently popular.

Coordinate system names supported by given service-instance could follow conventions (FITS standard or AST lib or other?)

Oh, for the concrete form of such strings we have https://www.ivoa.net/rdf/refframe/. But that's not really the challenge.

Note: include also non-WCS systems like PIXEL-GRID ?

For pixel cutouts I'd again suggest separate parameter names. DaCHS has used PIXEL_n (e.g., http://dc.g-vo.org/califa/q3/dl/dlmeta?ID=ivo%3A%2F%2Forg.gavo.dc%2F~%3Fcalifa%2Fdatadr3%2FCOMB%2FUGC12519.COMB.rscube.fits) since before SODA was a thing, and for simple cutouts that's just fine.