<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">Hi all,<br>
<br>
I cross post this answer to Apps as it is related to VOTable.<br>
I resume the question : <b>How to recognize/process HEALPix index
column in a VOTable ?</b><br>
Presently two ideas (presented below): one based on UCD
specialization, another based on DM<br>
<br>
I propose a third one (close to what Markus was suggested):<br>
As we have reintroduced COOSYS one year ago (VOTable erratum1), I
suggest to just add new words for the vocabulary of"system"
attribut. We have already the notion of "eq_FK5" or "eq_FK4", etc.
It will be totally coherent to have "eq_HEALPIX_NUNIQ" or
"eq_HEALPIX_NESTED8" or "gal_HEALPIX_RING10" (ie.
frame_HEALPIX_NUMBERING[order]). <br>
<br>
It would be a very simple and coherent solution (not a bad thing
for interoperability), immediately usable without any new standard
extension (already compatible with current VOTable REC). <br>
<br>
<font color="#996633"><tt> <RESOURCE></tt><tt><br>
</tt><b><tt> <COOSYS ID="sys1"
system="eq_HEALPIX_NUNIQ" /></tt></b><b><tt><br>
</tt></b><tt> <TABLE></tt><tt><br>
</tt><tt> ...</tt><tt><br>
</tt><tt> <FIELD name="npix" ID="col1" ... <b>ref="sys1"</b>/></tt><tt><br>
</tt></font><br>
And for the future, as for polar coordinate systems, when we will
have a more global DM solution accepted, we could move to the new
solution. Note that we can have several COOSYS lines if required
(for HEALPix column, for RA,DEC in such or such system...).<br>
<br>
Cheers<br>
Pierre<br>
<br>
<br>
Le 19/04/2018 à 15:13, Laurent Michel a écrit :<br>
</div>
<blockquote type="cite"
cite="mid:94f56912-720b-b4b3-c97f-4e361868c20f@astro.unistra.fr">Hi
Gregory,
<br>
<br>
<br>
Using UCDs to retrieve the Healpix frame supposes that the client
will pick here and there values from which it could reconstruct
that frame.
<br>
In a model approach, the healpix frame is defined by the model, so
that the client just has to build a model instance to get that
frame. This second approach is more consistent, a bit more heavy
though, since the way data are tied is not inferred by the client.
<br>
<br>
As Markus said, I experimented this model oriented approach in my
Tessellation project.
<br>
<br>
<a class="moz-txt-link-freetext" href="https://volute.g-vo.org/svn/trunk/projects/dm/Tesselation/">https://volute.g-vo.org/svn/trunk/projects/dm/Tesselation/</a>
<br>
<br>
The idea was to extend a little bit STC with an Healpix frame and
coords.
<br>
This is a relevant use case for both playing with the VO-DML model
extension and fulfilling a real requirement.
<br>
<br>
Bye
<br>
Laurent
<br>
<br>
<br>
Le 19/04/2018 à 09:09, Markus Demleitner a écrit :
<br>
<blockquote type="cite">Hi Gregory,
<br>
<br>
On Tue, Apr 17, 2018 at 11:49:14AM -0700, Gregory
Dubois-Felsmann wrote:
<br>
<blockquote type="cite">I note that there is a type-'Q' entry in
the UCD vocabulary
<br>
'pos.healpix' in the Position and Coordinates category. I
assume
<br>
that this is intended to describe a data item as an integer ID
of a
<br>
pixel in the HEALPix system. Since there are three numbering
<br>
</blockquote>
<br>
Yes, that has been the intention, and so far, it doesn't go
beyond
<br>
that.
<br>
<br>
<blockquote type="cite">conventions for such pixels - NESTED and
RING (which require the
<br>
additional specification of a HEALPix order or the quantity
usually
<br>
known as 'Nside'), and NUNIQ (which encodes both the order and
the
<br>
pixel ID) - some additional information is required in order
to
<br>
</blockquote>
<br>
Do you actually see many RING and NUNIQ healpixes in datasets
<br>
intended for the wider public and plausibly showing up in
VOTables?
<br>
I personally so far had hoped we might get by with NESTED in the
VO.
<br>
<br>
<blockquote type="cite">Is there any existing practice for how
to provide additional
<br>
semantic metadata that allows the recipient of IVOA-style data
to
<br>
determine which numbering system a given dataset described
with
<br>
'pos.healpix' is actually following?
<br>
<br>
Has a further specialization of the UCD vocabulary been
considered,
<br>
e.g., including something like 'pos.healpix.nuniq'?
<br>
</blockquote>
<br>
That would be my preferred way forward if non-nested healpix
schemes
<br>
needed annotation, yes.
<br>
<br>
<blockquote type="cite">of a pixel to query or operate on. In
my specific application I
<br>
could just specify 'out of band' that the IDs must be in NUNIQ
<br>
form, but I thought I'd try to be a good citizen and make the
data
<br>
packet generic enough that it could support the other
<br>
representations.
<br>
</blockquote>
<br>
Much appreciated!
<br>
<br>
<blockquote type="cite">In this regard, I also don't see an
MType for the transmission of a
<br>
HEALPix ID or list of IDs in SAMP, which is something I'd also
like
<br>
to support.
<br>
</blockquote>
<br>
That one definitely a topic for Apps, and I'd say this should be
<br>
discussed once we understand what client receiving such a
message
<br>
should expect.
<br>
<br>
<blockquote type="cite">I've seen the discussion in the archives
for this list and the Apps
<br>
list in August/September 2016. It didn't seem to run to a
<br>
conclusion, and I don't see a followup discussion in the
October
<br>
2016 Interop meeting agenda.
<br>
</blockquote>
<br>
Yeah -- unfortunately, this wasn't followed up. As to
annotating
<br>
healpix kind and order, I think if you took it into your hands,
<br>
prepared a proposal and then just went with it, chances are good
it'll
<br>
be taken up (I suppose it would eventually be standardised in
DALI,
<br>
so the DAL list would be a good place to discuss that).
<br>
<br>
Also note Laurent Michel's effort on having a data model-based
<br>
annotation of sky pixelisation schemes at
<br>
<a class="moz-txt-link-freetext" href="https://volute.g-vo.org/svn/trunk/projects/dm/Tesselation/">https://volute.g-vo.org/svn/trunk/projects/dm/Tesselation/</a> --
I've
<br>
not really have a good look at it, and so I'll leave it to
Laurent
<br>
(in cc:) to comment.
<br>
<br>
As to the reference frame (and position) used, I'd be strictly
<br>
against improvising something. Until the STC data model and a
usable
<br>
serialisation for it come around, just use COOSYS, probably
somewhat
<br>
like this:
<br>
<br>
<COOSYS ID="main_system" system="ICRS"/>
<br>
<br>
<COLUMN name="healpix" ... ref="main_system"/>
<br>
<br>
I don't think any healpix consumers at this point evaluate it,
but
<br>
it's a straightforward extension of current practices, so I'd be
<br>
surprised if that were to cause any pain.
<br>
<br>
-- Markus
<br>
<br>
</blockquote>
<br>
</blockquote>
<p><br>
</p>
</body>
</html>