Marking up HEALPix index columns in VOTable

[Pierre Fernique]

Dear all,

I have to say that I am *very enthousiast about this suggestion to mark 
up HEALPix tessellation index in tables*. This idea can appear 
"anecdotic" but, in reality, it can become a key point for increasing a 
lot our global IVOA interoperability . The potential use cases based on 
this simple column tagging can be really wider than what we can imagine 
by just providing a common spacial system fast and easy to manipulate.  
That's why I am *in favor of the usage of a unique convention, the same 
that we have already chosen for MOC*, that's mean: tessellation 
system=HEALPix, frame=equatorial, ordering=NESTED.

In this convention, there are only 2 parameters to be specified: order 
and pixel number. I'm clearly in favor of *Markus' GROUP proposal* but 
*by using explicit utypes rather than too specialized UCDs*. The utypes 
has been indeed invented for this purpose (avoid to invent dedicated UCD 
for tagging coordinate columns in CS). As we have no longer risk to 
clash with the future VODML serialization, we should not hesitate to use 
them if we need them. I suggest something like these ones:  
"/tessellation.healpix.order/" and "/tessellation.healpix.pixel/" (just 
strings, no related to any background DM - not yet defined in fact). If 
we also add a utype in the GROUP element (for instance 
"/tessellation.healpix/"), we will simplify the parser job.

     <GROUP utype="tessellation.healpix">
       <PARAM datatype="short" name="order_1"
         utype="tessellation.healpix.order" value="3"/>
       <FIELDref ref="hp_1"/>
     </GROUP>
    ...
    <FIELD id="hp_1" datatype="long" name="hp_1" utype="tessellation.healpix.pixel"/>
   

and

      <GROUP utype="tessellation.healpix">
       <FIELDref ref="order_2"/>
       <FIELDref ref="hp_2"/>
     </GROUP>
     ...
     <FIELD id="order_2" datatype="short" name="order"
         utype="tessellation.healpix.order"/>
     <FIELD id="hp_2" datatype="long" name="hp_2" utype="tessellation.healpix.pixel"/>

I apologize to arrive so late in this discussion... vacations...
Cheers
Pierre

P.S. In fact, this topic - in 10 mails -  illustrates very well 10 years 
of IVOA discussions about column semantic tagging : from the basic 
naming convention, through utype, xtype, UCD, GROUP, until the most 
sophisticated VODML serialization.


Le 15/08/2016 à 10:04, 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
>
>   


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/semantics/attachments/20160901/743ca8a1/attachment.html>