Marking up HEALPix index columns in VOTable

[François Bonnarel]

Hi all,
   - I also prefer a solution with GROUPS and PARAMS to describe the 
HEALPIX metadata. It seems to be more flexible and reusable for other 
use cases than the only "single column with the HEALPIX index in a 
single HEALPIX nside, scheme and RefFrame)

   - the right place to define the piece of HEALPIX metadata should be 
the stc datamodel. It is true that STC2 draft allready has the HEALPIX 
option in the CoordFlavor enumeration. UCD combination should not be 
used for accurate attribute definition but more to rapidly identfy 
anything related to healpix (ucd=pos.healpix). If we are not able to 
stableize the stc utype now (Markus argument), then let just define 
"names" for that in the standard. This is a solution which has been used 
for ObsCORE. Obscore Table names uniquely identify the model attribute 
(and ivoa role) of the content of the colomn.

Cheers
François

Le 17/08/2016 15:18, Laurent Michel a écrit :
> Hi,
>
> I agree with Thomas.
> Encoding nside is in a fields MAX_VALUE can be used for an had-hoc 
> implementation but not at a standard level. I would add to the 
> Thomas's arguments the lack of consistency. What  about if the value 
> does does not match Value =12*(4^N)-1?
> Using PARAMs is clearly a safer way to identify the healpix tessellation.
> Does it worth to take into account the case where multiple Healpix 
> columns must be described? We can consider that just one Healpix 
> column, the MAIN one, has to be described by the three PARAMs. We can 
> introduce a "pos.main.healpix" UCD in a similar way to the position 
> columns to make sure to address the right column.
>
> Laurent
>
>
>
> Le 17/08/2016 09:11, Thomas Boch a écrit :
>> Hi Markus,
>>
>> I don't like the VALUES solution because it's semantically poor and 
>> not really explicit. My preference goes to the GROUPing
>> because it's self-contained and descriptive.
>>
>> Thomas
>>
>> Le 08/15/2016 10:04 AM, Markus Demleitner a écrit :
>>> Hi Apps,
>>>
>>> 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.
>>>
>>> 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.
>>>
>>> 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].
>>>    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.
>>>
>>> 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?
>>>
>>>           -- Markus
>>>
>