Marking up HEALPix index columns in VOTable

[Thomas Boch]

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
>
>