Marking up HEALPix index columns in VOTable

[Mark Taylor]

Stephane,

2 coordinates (nside and tile number) suggests that you have different
Nside for each row of the table.  That's possible, but this
variable-tile-size scenario is not what I had in mind
(and in fact it would sidestep the difficulty that I'm talking about
here, since you then would have a place to put the Nside/order value).  
Is that really what you mean, or are you talking about a uniform
tile size over the whole planetary surface?

Mark

On Mon, 8 Aug 2016, Stéphane Erard wrote:

> Dear Mark and all
> 
> I've been wondering about the same thing last spring for possible use on planetary surfaces (~spherical ones at least)
> To me that was clearly a system with 2 coordinates, Nside and tile number (plus possibly ordering nested/ring as a 3rd one - it doesn't hurt in EPNCore since we always have 3 spatial coordinates available). 
> Your baseline solution may be better if there is a simple way to parse it in the tools.
> 
> Regards
> Stéphane
> 
> Le 8 août 2016 à 18:55, Mark Taylor <M.B.Taylor at bristol.ac.uk> a écrit :
> 
> > [I've crossposted this to apps and semantics, but I suggest
> > followups to Apps only]
> > 
> > Dear colleagues,
> > 
> > Gregory Mantelet, Markus Demleitner and I have been having some
> > discussions about exchange of HEALPix maps within the VO.
> > 
> > The type of data we're considering is a table for which one column
> > contains a HEALPix index (an integer which identifies a tile on the sky),
> > and other columns contain quantities relating to to that tile
> > (source density, extinction, mean G magnitude, whatever).
> > The question we're trying to answer is: how does a data producer
> > mark up the healpix-index column in a VOTable so that consumers
> > can recognise it as such?
> > 
> > The following UCD1+ is defined:
> > 
> >    Q  |  pos.healpix      |  Hierarchical Equal Area IsoLatitude Pixelization
> > 
> > So far so good; however, marking up a column like this provides
> > insufficient information to make it useful, because to make sense
> > of a HEALPix index you need to know what Order N of tiling it represents
> > (HEALPix splits the sky into 12*4^N tiles, where N is an integer
> > that for practical purposes falls in the range 0..29).
> > Since UCD words cannot be parameterised (beyond composing them with
> > other UCD words) there doesn't seem to be any way to encode this
> > Order information in the UCD.
> > 
> > Markus's clever idea is to do something like this:
> > 
> >     <FIELD datatype="int" ucd="pos.healpix">
> >       <VALUES type="legal">
> >         <MAX>49151</MAX>
> >       </VALUES>
> >     </FIELD>
> > 
> > Since the legal maximum value for the column is 49151 (=12*(4^6)-1),
> > it's possible to infer that N=6 for this healpix column.  Note that
> > since type="legal" this does not say that the actual contents of
> > the column hit that maximum (i.e. some pixels might be absent, but the
> > declaration would not change).
> > 
> > This is kind of horrible, but at the same time the meaning is fairly
> > unambiguous, and it requires no new standardisation activity.
> > So, we are likely to go ahead with marking up HEALPix columns in
> > this way (Markus's and Gregory's services will emit VOTables like
> > this, and topcat will understand them) unless anybody persuades
> > us different.
> > 
> > We have considered various other options too, but on balance we
> > think they're even worse.  Briefly:
> > 
> >   - Abuse UCDs by trying to parameterise them:
> >        pos.healpix(6)?
> >        pos.healpix;index=6?
> > 
> >   - Introduce new UCD words to (0<=N<=29, so the number of new words
> >     would be quite, but not ridiculously, large):
> >        pos.healpix0, pos.healpix1, ... pos.healpix29?
> >        pos.healpix;arith.0, pos.healpix;arith.1, ... pos.healpix;arith.29
> > 
> >   - Xtype magic:
> >        xtype="healpix(6)"
> >        xtype="tilings:healpix(6)"
> > 
> >   - Some table-level indication of the order:
> >        <TABLE>
> >          <PARAM name="healpix-order" datatype="int" value="6">
> >          <FIELD datatype=int ucd="pos.healpix"/>
> >            ...
> >        </TABLE>
> >      this would work because in practice, it's hard to imagine you
> >      could have multiple columns in a single table with different
> >      healpix orders.  This is somewhat analogous to how the
> >      ad-hoc FITS healpix serialization works.
> >      Note it still needs some convention to identify the healpix-order
> >      PARAM.
> > 
> >   - Some business with GROUP/FIELDref/PARAM elements at table level.
> >     Note this also needs some convention to identify the healpix-order.
> > 
> >   - Reinvent UCD syntax????
> > 
> > 
> > Actually it is even worse than this: there are two alternative
> > conventional schemes for assigning HEALPix indices to a tiling
> > at a given order, known as NESTED and RING, and you need to know
> > which one is intended.  Furthermore, the actual sky position
> > corresponding to a given pixel is dependent on how the tiling is
> > attached to the celestial sphere (e.g. equatorial, ecliptic, galactic).
> > So even if you know N you don't have enough explicit information
> > to make sense of a healpix index.  However, we are currently
> > following MOC in assuming the NESTED scheme, and it's probably
> > reasonable to take the sky system as implicit, so we're ignoring
> > those details for now.
> > 
> > Any bright ideas, wise comments etc welcome.
> > 
> > Mark
> > 
> > --
> > Mark Taylor   Astronomical Programmer   Physics, Bristol University, UK
> > m.b.taylor at bris.ac.uk +44-117-9288776  http://www.star.bris.ac.uk/~mbt/
> 
> 

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