Marking up HEALPix index columns in VOTable

[Marco Molinaro]

Dear all,
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.
I think I'll use the NUNIQ, even if it means probably that I'll need
64-bit integers to store it.

Cheers,
     Marco

2016-08-11 11:13 GMT+02:00 Markus Demleitner <msdemlei at ari.uni-heidelberg.de>:
> Dear Apps,
>
> On Wed, Aug 10, 2016 at 03:07:50PM +0200, Thomas Boch wrote:
>> Thanks Mark for the clarification.
>> In that case, I would go for having a GROUP describing the parameters and
>> involved fields. Something like this:
>>
>> <GROUP utype="stc:AstroCoordSystem">
>>         <PARAM
>>           utype="stc:AstroCoordSystem.SpaceFrame.CoordFlavor"
>>           value="HEALPIX" name="CoordFlavor" />
>>         <PARAM
>>           utype="stc:AstroCoordSystem.SpaceFrame.CoordRefFrame"
>>           value="ICRS" name="CoordRefFrame" />
>>       <PARAM
>>          utype="???:...norder"
>>          value="8" name="HpxNorder" />
>>         <PARAM
>>          utype="???:...ordering"
>>          value="NESTED" name="HpxOrdering />
>>         <FIELDref
>>          utype="???:...HpxIdx"
>>          ref="hpx8" />
>> </GROUP>
>>
>> [note: I'm not quite sure what would be the proper utypes to use to describe
>> the HEALPix norder, ordering and index.]
>
> ...which is exactly the problem with this approach:  We shouldn't
> pretend we're doing this properly when we don't.
>
> Doing it properly would mean embedding healpix itself, ordering, and
> nsides (or order) into a data model; I agree that STC would sound
> like a likely candidate, but I wouldn't argue against having a
> separate, perhaps temporary, sky pixelisation DM, either.
>
> I'm all in favour of *someone* doing this and figuring out how to
> serialise this then in a principled manner.  More attention to these
> things from the wider community would be great in general.  I'm
> *cough* not volunteering, though.
>
> Until there is a workable, generally accepted (which excludes my
> STC-in-VOTable-Note mechanism that I think Thomas is basing is
> propsal on[1]) VOTable-integrated STC data model, I have to say I'd
> much rather just have a quick remedy for an immediate itch.  A remedy
> that's then easly kept or phased out when we finally have a good way
> to represent STC in VOTable because it doesn't collide with the
> actual mechanism used then; whatever this mechanism is, we can, I'd
> say, be pretty sure it'll involve neither UCD nor VALUES.  It will,
> however, fairly certainly involve GROUPs.
>
>> In addition to that, you might also want to tag somehow the field nsrc to
>> denote it is a cumulative count of something. <FIELD ID="nsrc"
>> ucd="src.density" /> might be enough for your example but we need something
>> other if we sum on a given parameter (flux for instance).
>
> Hm -- except that in many cases these are not densities but averages
> (or perhaps other aggregate properites).  I'm not sure whether
> clients actually need a hint as to what might be plottable versus the
> healpix.  At least in the TAP use case, the tables will presumably
> come from a query involving GROUP, so everything in these tables will
> be fully functionally dependent on the healpix anyway and thus make a
> reasonable variable to plot.
>
> Cheers,
>
>          Markus
>
>
> [1] but still thanks a lot for considering it...