Marking up HEALPix index columns in VOTable

[Markus Demleitner]

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