Marking up HEALPix index columns in VOTable

[Mark Taylor]

Hi all,

sorry for the belated response, I've just got back from holiday.

On Mon, 15 Aug 2016, Markus Demleitner wrote:

> On Thu, Aug 11, 2016 at 04:03:37PM +0200, Marco Molinaro wrote:
> > if the order is what is needed,
> > considering the MOC standardization to be in place,
> > I vote for a solution that is a part of Rick's suggestion
> > 
> > N -> pos.healpix;meta.number
> > 
> > into a table level PARAM.
> > Maybe mixed to a single addition to UCD words:
> > 
> > meta.order
> > 
> > if we want some more specific detail and a reusable word.
> > (thus going pos.healpix;meta.order)
> > 
> > However I must say that I'm working on a tableset that,
> > if it were to return such field, would have a non-homogeneous
> > order for tessellation. But this case is not covered by the
> > "horrible" solution either.
> 
> If I understand correctly what your problem is, I'd say it'd be
> solved by what I think we need anyway to allow multiple healpix
> columns (and hence potentially multiple orders) per table: some form
> of grouping.

While I can see that it's not impossible in principle to have
multiple columns using HEALPix indices with different orders
in a single table, I'm struggling to think of any physical 
situation where that would be a desirable/meaningful thing to do.

But: yes I think some form of grouping should be able to solve 
Marco's problem.

> I'm still not a great fan of this since it involves referencing, and
> getting referencing right always is a bit tricky -- but if people
> really consider using VALUES as prohibitively ugly (while I'd still
> say healpix ranges and hence orders are a perfectly legitimate use
> case), there's probably no way around it.

Agree on all points.

> Let's at least keep that as simple as we possibly can, then.  I think
> the minimal thing we can say is:
> 
>   A FIELD containing a healpix index is marked up with a
>   ucd="pos.healpix".  It must be referenced from a GROUP that will
>   normally contain a PARAM with pos.healpix;meta.number that contains
>   the healpix order (log_4(nsides)):
> 
>     <GROUP>
>       <PARAM datatype="short" name="order_1"
>         ucd="meta.number;pos.healpix" value="3"/>
>       <FIELDref ref="hp_1"/>
>     </GROUP>
>    ...
>    <FIELD id="hp_1" datatype="long" name="hp_1" ucd="pos.healpix"/>
>   
>   [meta.number is P, so it must be first, and I'd argue that's a good
>   thing, too; I'd advocate having meta.order, too, though].

meta.number's documentation is as follows:

    "Number (of things; e.g. nb of object in an image)"

which, assuming "nb" here means count, really doesn't fit healpix
order (what are the things it's a nb of?  You could argue that it
makes sense for NSIDE, though I really don't want to use NSIDE).
So, using meta.number is already abusing the existing UCD documented
semantics.  Agreed meta.order would work well - but that doesn't
exist in the current UCD list.

>   In case a column contains healpixes of differing orders, the order 
>   can also be stored in a separate column:
> 
>      <GROUP>
>       <FIELDref ref="order_2"/>
>       <FIELDref ref="hp_2"/>
>     </GROUP>
>     ...
>     <FIELD id="order_2" datatype="short" name="order"
>         ucd="meta.number;pos.healpix"/>
>     <FIELD id="hp_2" datatype="long" name="hp_2" ucd="pos.healpix"/>
> 
>   From a consumer point of view, the rule is: If a FIELD has a ucd or
>   pos.healpix, look for a GROUP that contains a FIELDref to that
>   FIELD.  This GROUP must contain either a PARAM with ucd
>   meta.number;pos.healpix or a FIELDref with this ucd.   Obtain the
>   order number from there.  If no such GROUP, FIELDref, or PARAM can
>   be found, ignore the FIELD or raise an error.
> 
> It may not be overly pretty, but it's not overly complex either and
> neither requires prior nor likely complicates later DM work.

Yes do-able, though fiddly and abuses meta.number.
If it's the consensus I'll implement it ...

> And I really can't convince you that simply going for VALUES (which,
> yes, cannot cover the inhomogeneous case) would do the trick for now?

... but I'd still be reasonably happy to use VALUES as an ad-hoc
solution for now if we want to do it properly on a longer timescale
(e.g. meta.order and maybe meta.scheme in a future UCD list,
or follow Francois's argument and define names in STC2).

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/