<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix"><br>
Dear all,<br>
<br>
I have to say that I am <b>very enthousiast about this suggestion
to mark up HEALPix tessellation index in tables</b>. 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 <b>in favor of the usage of a unique
convention, the same that we have already chosen for MOC</b>,
that's mean: tessellation system=HEALPix, frame=equatorial,
ordering=NESTED.<br>
<br>
In this convention, there are only 2 parameters to be specified:
order and pixel number. I'm clearly in favor of <b>Markus' GROUP
proposal</b> but <b>by using explicit utypes rather than too
specialized UCDs</b>. 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: "<i>tessellation.healpix.order</i>"
and "<i>tessellation.healpix.pixel</i>" (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 "<i>tessellation.healpix</i>"),
we will simplify the parser job.<br>
<pre wrap=""> <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"/>
</pre>
I apologize to arrive so late in this discussion... vacations...
<br>
Cheers<br>
Pierre<br>
<br>
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.<br>
<br>
<br>
Le 15/08/2016 à 10:04, Markus Demleitner a écrit :<br>
</div>
<blockquote cite="mid:20160815080400.GC8399@victor" type="cite">
<pre wrap="">Hi Apps,
On Thu, Aug 11, 2016 at 04:03:37PM +0200, Marco Molinaro wrote:
</pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">
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
</pre>
</blockquote>
<p><br>
</p>
</body>
</html>