[UCD] Question about representation of HEALPix pixel IDs

[Markus Demleitner]

Hi Gregory,

On Tue, Apr 17, 2018 at 11:49:14AM -0700, Gregory Dubois-Felsmann wrote:
> I note that there is a type-'Q' entry in the UCD vocabulary
> 'pos.healpix' in the Position and Coordinates category.  I assume
> that this is intended to describe a data item as an integer ID of a
> pixel in the HEALPix system.  Since there are three numbering

Yes, that has been the intention, and so far, it doesn't go beyond
that.

> conventions for such pixels - NESTED and RING (which require the
> additional specification of a HEALPix order or the quantity usually
> known as 'Nside'), and NUNIQ (which encodes both the order and the
> pixel ID) - some additional information is required in order to

Do you actually see many RING and NUNIQ healpixes in datasets
intended for the wider public and plausibly showing up in VOTables?
I personally so far had hoped we might get by with NESTED in the VO.

> Is there any existing practice for how to provide additional
> semantic metadata that allows the recipient of IVOA-style data to
> determine which numbering system a given dataset described with
> 'pos.healpix' is actually following?
> 
> Has a further specialization of the UCD vocabulary been considered,
> e.g., including something like 'pos.healpix.nuniq'?  

That would be my preferred way forward if non-nested healpix schemes
needed annotation, yes.

> of a pixel to query or operate on.  In my specific application I
> could just specify 'out of band' that the IDs must be in NUNIQ
> form, but I thought I'd try to be a good citizen and make the data
> packet generic enough that it could support the other
> representations.

Much appreciated!

> In this regard, I also don't see an MType for the transmission of a
> HEALPix ID or list of IDs in SAMP, which is something I'd also like
> to support.

That one definitely a topic for Apps, and I'd say this should be
discussed once we understand what client receiving such a message
should expect.

> I've seen the discussion in the archives for this list and the Apps
> list in August/September 2016.  It didn't seem to run to a
> conclusion, and I don't see a followup discussion in the October
> 2016 Interop meeting agenda.

Yeah -- unfortunately, this wasn't followed up.  As to annotating
healpix kind and order, I think if you took it into your hands,
prepared a proposal and then just went with it, chances are good it'll
be taken up (I suppose it would eventually be standardised in DALI,
so the DAL list would be a good place to discuss that).

Also note Laurent Michel's effort on having a data model-based
annotation of sky pixelisation schemes at
https://volute.g-vo.org/svn/trunk/projects/dm/Tesselation/ -- I've
not really have a good look at it, and so I'll leave it to Laurent
(in cc:) to comment.

As to the reference frame (and position) used, I'd be strictly
against improvising something.  Until the STC data model and a usable
serialisation for it come around, just use COOSYS, probably somewhat
like this:

  <COOSYS ID="main_system" system="ICRS"/>

  <COLUMN name="healpix" ... ref="main_system"/>

I don't think any healpix consumers at this point evaluate it, but
it's a straightforward extension of current practices, so I'd be
surprised if that were to cause any pain.

       -- Markus