[UCD] Question about representation of HEALPix pixel IDs

[Pierre Fernique]

Hi all,

I cross post this answer to Apps as it is related to VOTable.
I resume the question : *How to recognize/process HEALPix index column 
in a VOTable ?*
Presently two ideas (presented below): one based on UCD specialization, 
another based on DM

I propose a third one (close to what Markus was suggested):
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]).

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

         <RESOURCE>
*          <COOSYS ID="sys1" system="eq_HEALPIX_NUNIQ" />**
*          <TABLE>
              ...
              <FIELD name="npix"  ID="col1" ... *ref="sys1"*/>

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

Cheers
Pierre


Le 19/04/2018 à 15:13, Laurent Michel a écrit :
> Hi Gregory,
>
>
> Using UCDs to retrieve the Healpix frame supposes that the client will 
> pick here and there values from which it could reconstruct that frame.
> 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.
>
> As Markus said, I experimented this model oriented approach in my 
> Tessellation project.
>
>    https://volute.g-vo.org/svn/trunk/projects/dm/Tesselation/
>
> The idea was to extend a little bit STC with an Healpix frame and coords.
> This is a relevant use case for both playing with the VO-DML model 
> extension and fulfilling a real requirement.
>
> Bye
> Laurent
>
>
> Le 19/04/2018 à 09:09, Markus Demleitner a écrit :
>> Hi Gregory,
>>
>> On Tue, Apr 17, 2018 at 11:49:14AM -0700, Gregory Dubois-Felsmann wrote:
>>> I note that there is a type-'Q' entry in the UCD vocabulary
>>> 'pos.healpix' in the Position and Coordinates category.  I assume
>>> that this is intended to describe a data item as an integer ID of a
>>> pixel in the HEALPix system.  Since there are three numbering
>>
>> Yes, that has been the intention, and so far, it doesn't go beyond
>> that.
>>
>>> conventions for such pixels - NESTED and RING (which require the
>>> additional specification of a HEALPix order or the quantity usually
>>> known as 'Nside'), and NUNIQ (which encodes both the order and the
>>> pixel ID) - some additional information is required in order to
>>
>> Do you actually see many RING and NUNIQ healpixes in datasets
>> intended for the wider public and plausibly showing up in VOTables?
>> I personally so far had hoped we might get by with NESTED in the VO.
>>
>>> Is there any existing practice for how to provide additional
>>> semantic metadata that allows the recipient of IVOA-style data to
>>> determine which numbering system a given dataset described with
>>> 'pos.healpix' is actually following?
>>>
>>> Has a further specialization of the UCD vocabulary been considered,
>>> e.g., including something like 'pos.healpix.nuniq'?
>>
>> That would be my preferred way forward if non-nested healpix schemes
>> needed annotation, yes.
>>
>>> of a pixel to query or operate on.  In my specific application I
>>> could just specify 'out of band' that the IDs must be in NUNIQ
>>> form, but I thought I'd try to be a good citizen and make the data
>>> packet generic enough that it could support the other
>>> representations.
>>
>> Much appreciated!
>>
>>> In this regard, I also don't see an MType for the transmission of a
>>> HEALPix ID or list of IDs in SAMP, which is something I'd also like
>>> to support.
>>
>> That one definitely a topic for Apps, and I'd say this should be
>> discussed once we understand what client receiving such a message
>> should expect.
>>
>>> I've seen the discussion in the archives for this list and the Apps
>>> list in August/September 2016.  It didn't seem to run to a
>>> conclusion, and I don't see a followup discussion in the October
>>> 2016 Interop meeting agenda.
>>
>> Yeah -- unfortunately, this wasn't followed up.  As to annotating
>> healpix kind and order, I think if you took it into your hands,
>> prepared a proposal and then just went with it, chances are good it'll
>> be taken up (I suppose it would eventually be standardised in DALI,
>> so the DAL list would be a good place to discuss that).
>>
>> Also note Laurent Michel's effort on having a data model-based
>> annotation of sky pixelisation schemes at
>> https://volute.g-vo.org/svn/trunk/projects/dm/Tesselation/ -- I've
>> not really have a good look at it, and so I'll leave it to Laurent
>> (in cc:) to comment.
>>
>> As to the reference frame (and position) used, I'd be strictly
>> against improvising something.  Until the STC data model and a usable
>> serialisation for it come around, just use COOSYS, probably somewhat
>> like this:
>>
>>    <COOSYS ID="main_system" system="ICRS"/>
>>
>>    <COLUMN name="healpix" ... ref="main_system"/>
>>
>> I don't think any healpix consumers at this point evaluate it, but
>> it's a straightforward extension of current practices, so I'd be
>> surprised if that were to cause any pain.
>>
>>         -- Markus
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/apps/attachments/20180419/2240818e/attachment.html>