Sexagesimal metadata

[Mark Taylor]

Hi Anita!

I agree that sexagesimal is not fun to play with.  In most cases,
it's present as a kind of additional provenance metadata alongside
numeric fields giving lon and lat in degrees, and those numeric
fields are what users should be querying on.  I think that's the
case for VO-compliant data presentation anyway, so that data providers
relying on sexagesimal formatting are not likely to change practice
based on any VO standardisation activity in this area.
I think I'm right in saying also that VizieR constructs numeric
coordinates (_RAJ2000, _DEJ2000) derived from sexagesimal fields if
they exist, so that you can always use numeric coordinates in VizieR.

In what contexts do you find yourself having to manipulate sexagesimal
in order to talk to data services?

Mark

On Thu, 10 Mar 2022, Anita M S Richards wrote:

> Dear all,
> 
> Apologies for butting in as a lurking user, but if the many service providers can be persuaded to be more consistent in the sexagesimal format required for queries this would save users many hours!
> 
> CDS at least provides examples and documentation.  But there are so many variants out there (including ALMA using 12.12.12.12 for +12:12:12.12 Dec) that it is usually impossible to take a list from one data provider and use it to query another without extensive use of SED or whatever...  If standardisation is not possible is there any chance of developing and providing translation code to service providers so that if I entered e.g. 12h12m12.12s +12d12m12.1s or any likely variant, this would be translated into whatever their service needed?
> 
> 
> many thanks
> Anita
> 
> --------------------------------------------------------------------------------------------------------
> Dr. A.M.S. Richards
> Senior visiting fellow, JBCA, University of Manchester, M13 9PL
> a.m.s.richards at manchester.ac.uk (please do not use old  @jb.man.ac.uk email)
> I work the hours which suit me. I do not expect instant replies, I respect whatever hours you work.
> 
> ________________________________
> From: dal-bounces at ivoa.net <dal-bounces at ivoa.net> on behalf of Mark Taylor <m.b.taylor at bristol.ac.uk>
> Sent: 10 March 2022 17:17
> To: semantics at ivoa.net <semantics at ivoa.net>
> Cc: Gilles Landais <gilles.landais at astro.unistra.fr>; dal at ivoa.net <dal at ivoa.net>
> Subject: Sexagesimal metadata
> 
> Dear Semantics and DAL,
> 
> following the report I gave on VOUnit usage in the VO at the last interop
> (https://wiki.ivoa.net/internal/IVOA/InterOpNov2021Ops/uuc.pdf)
> Gilles Landais at CDS has done a good job of tidying up the units
> reported by VizieR to conform to the VOUnit standard (the results are
> not yet visible in the public VizieR service).
> 
> But one issue that remains is how to flag up sexagesimal quantities,
> which are currently marked up like this:
> 
>    <FIELD name="RAJ2000" ucd="pos.eq.ra;meta.main" ref="J2000"
>           datatype="char" arraysize="12" unit="'h:m:s'">
>    <FIELD name="DEJ2000" ucd="pos.eq.dec;meta.main" ref="J2000"
>           datatype="char" arraysize="13" unit="'d:m:s'">
> 
> The unit, by long VizieR tradition, is quoted as 'h:m:s' or 'd:m:s'
> (including the single quotes), which is probably recognised as an
> ad hoc indication by quite a bit of client code out there.
> However this is not legal VOUnit syntax, and they're not really units
> anyway since the columns they apply to are not numeric, but it's not
> obvious how to indicate sexagesimal content of columns in VOTable metadata.
> You can infer it by noticing ucd="pos.eq.*" and datatype="char",
> but it seems like there ought to be a more explicit way to do this,
> especially considering how common this case is in the tables we deal
> with.
> 
> So: what would be the VO-compliant way for CDS to proceed here?
> (note I'm not claiming that they are going to follow any such advice,
> that's for Gilles to decide).  Do we just leave consumers to make a
> good guess based on UCD and datatype?  Could it be a job for DALI/xtype?
> Something else?
> 
> Mark
> 
> --
> Mark Taylor  Astronomical Programmer  Physics, Bristol University, UK
> m.b.taylor at bristol.ac.uk          http://www.star.bristol.ac.uk/~mbt/
> 

--
Mark Taylor  Astronomical Programmer  Physics, Bristol University, UK
m.b.taylor at bristol.ac.uk          http://www.star.bristol.ac.uk/~mbt/