From M.B.Taylor at bristol.ac.uk  Mon Aug  8 18:55:31 2016
From: M.B.Taylor at bristol.ac.uk (Mark Taylor)
Date: Mon, 8 Aug 2016 17:55:31 +0100 (BST)
Subject: Marking up HEALPix index columns in VOTable
Message-ID: <alpine.LRH.2.20.1608081750110.29860@andromeda.star.bris.ac.uk>

[I've crossposted this to apps and semantics, but I suggest
followups to Apps only]

Dear colleagues,

Gregory Mantelet, Markus Demleitner and I have been having some
discussions about exchange of HEALPix maps within the VO.

The type of data we're considering is a table for which one column
contains a HEALPix index (an integer which identifies a tile on the sky),
and other columns contain quantities relating to to that tile
(source density, extinction, mean G magnitude, whatever).
The question we're trying to answer is: how does a data producer
mark up the healpix-index column in a VOTable so that consumers
can recognise it as such?

The following UCD1+ is defined:

    Q  |  pos.healpix      |  Hierarchical Equal Area IsoLatitude Pixelization

So far so good; however, marking up a column like this provides
insufficient information to make it useful, because to make sense
of a HEALPix index you need to know what Order N of tiling it represents
(HEALPix splits the sky into 12*4^N tiles, where N is an integer
that for practical purposes falls in the range 0..29).
Since UCD words cannot be parameterised (beyond composing them with
other UCD words) there doesn't seem to be any way to encode this
Order information in the UCD.

Markus's clever idea is to do something like this:

     <FIELD datatype="int" ucd="pos.healpix">
       <VALUES type="legal">
         <MAX>49151</MAX>
       </VALUES>
     </FIELD>

Since the legal maximum value for the column is 49151 (=12*(4^6)-1),
it's possible to infer that N=6 for this healpix column.  Note that
since type="legal" this does not say that the actual contents of
the column hit that maximum (i.e. some pixels might be absent, but the
declaration would not change).

This is kind of horrible, but at the same time the meaning is fairly
unambiguous, and it requires no new standardisation activity.
So, we are likely to go ahead with marking up HEALPix columns in
this way (Markus's and Gregory's services will emit VOTables like
this, and topcat will understand them) unless anybody persuades
us different.

We have considered various other options too, but on balance we
think they're even worse.  Briefly:

   - Abuse UCDs by trying to parameterise them:
        pos.healpix(6)?
        pos.healpix;index=6?

   - Introduce new UCD words to (0<=N<=29, so the number of new words
     would be quite, but not ridiculously, large):
        pos.healpix0, pos.healpix1, ... pos.healpix29?
        pos.healpix;arith.0, pos.healpix;arith.1, ... pos.healpix;arith.29

   - Xtype magic:
        xtype="healpix(6)"
        xtype="tilings:healpix(6)"

   - Some table-level indication of the order:
        <TABLE>
          <PARAM name="healpix-order" datatype="int" value="6">
          <FIELD datatype=int ucd="pos.healpix"/>
            ...
        </TABLE>
      this would work because in practice, it's hard to imagine you
      could have multiple columns in a single table with different
      healpix orders.  This is somewhat analogous to how the
      ad-hoc FITS healpix serialization works.
      Note it still needs some convention to identify the healpix-order
      PARAM.

   - Some business with GROUP/FIELDref/PARAM elements at table level.
     Note this also needs some convention to identify the healpix-order.

   - Reinvent UCD syntax????


Actually it is even worse than this: there are two alternative
conventional schemes for assigning HEALPix indices to a tiling
at a given order, known as NESTED and RING, and you need to know
which one is intended.  Furthermore, the actual sky position
corresponding to a given pixel is dependent on how the tiling is
attached to the celestial sphere (e.g. equatorial, ecliptic, galactic).
So even if you know N you don't have enough explicit information
to make sense of a healpix index.  However, we are currently
following MOC in assuming the NESTED scheme, and it's probably
reasonable to take the sky system as implicit, so we're ignoring
those details for now.

Any bright ideas, wise comments etc welcome.

Mark

--
Mark Taylor   Astronomical Programmer   Physics, Bristol University, UK
m.b.taylor at bris.ac.uk +44-117-9288776  http://www.star.bris.ac.uk/~mbt/

From thomas.boch at astro.unistra.fr  Mon Aug  8 19:43:49 2016
From: thomas.boch at astro.unistra.fr (Thomas Boch)
Date: Mon, 8 Aug 2016 19:43:49 +0200
Subject: Marking up HEALPix index columns in VOTable
In-Reply-To: <alpine.LRH.2.20.1608081750110.29860@andromeda.star.bris.ac.uk>
References: <alpine.LRH.2.20.1608081750110.29860@andromeda.star.bris.ac.uk>
Message-ID: <92d36f6c-b814-a3a5-2d6e-8b965db04a23@astro.unistra.fr>

Hi Mark,

what's the motivation to have HEALPix maps in VOTable ?
Not to say I'm against the idea, but I'd like to understand better the 
use case first. If had to output HEALPix maps, I'll go with the FITS 
serialization as binary tables (and associated keywords ORDERING, 
COORDSYS, NSIDE) which can be produced/is understood by the HEALPix 
library and the tools using it.

Cheers,
Thomas

Le 08/08/2016 ? 18:55, Mark Taylor a ?crit :
> [I've crossposted this to apps and semantics, but I suggest
> followups to Apps only]
>
> Dear colleagues,
>
> Gregory Mantelet, Markus Demleitner and I have been having some
> discussions about exchange of HEALPix maps within the VO.
>
> The type of data we're considering is a table for which one column
> contains a HEALPix index (an integer which identifies a tile on the sky),
> and other columns contain quantities relating to to that tile
> (source density, extinction, mean G magnitude, whatever).
> The question we're trying to answer is: how does a data producer
> mark up the healpix-index column in a VOTable so that consumers
> can recognise it as such?
>
> The following UCD1+ is defined:
>
>      Q  |  pos.healpix      |  Hierarchical Equal Area IsoLatitude Pixelization
>
> So far so good; however, marking up a column like this provides
> insufficient information to make it useful, because to make sense
> of a HEALPix index you need to know what Order N of tiling it represents
> (HEALPix splits the sky into 12*4^N tiles, where N is an integer
> that for practical purposes falls in the range 0..29).
> Since UCD words cannot be parameterised (beyond composing them with
> other UCD words) there doesn't seem to be any way to encode this
> Order information in the UCD.
>
> Markus's clever idea is to do something like this:
>
>       <FIELD datatype="int" ucd="pos.healpix">
>         <VALUES type="legal">
>           <MAX>49151</MAX>
>         </VALUES>
>       </FIELD>
>
> Since the legal maximum value for the column is 49151 (=12*(4^6)-1),
> it's possible to infer that N=6 for this healpix column.  Note that
> since type="legal" this does not say that the actual contents of
> the column hit that maximum (i.e. some pixels might be absent, but the
> declaration would not change).
>
> This is kind of horrible, but at the same time the meaning is fairly
> unambiguous, and it requires no new standardisation activity.
> So, we are likely to go ahead with marking up HEALPix columns in
> this way (Markus's and Gregory's services will emit VOTables like
> this, and topcat will understand them) unless anybody persuades
> us different.
>
> We have considered various other options too, but on balance we
> think they're even worse.  Briefly:
>
>     - Abuse UCDs by trying to parameterise them:
>          pos.healpix(6)?
>          pos.healpix;index=6?
>
>     - Introduce new UCD words to (0<=N<=29, so the number of new words
>       would be quite, but not ridiculously, large):
>          pos.healpix0, pos.healpix1, ... pos.healpix29?
>          pos.healpix;arith.0, pos.healpix;arith.1, ... pos.healpix;arith.29
>
>     - Xtype magic:
>          xtype="healpix(6)"
>          xtype="tilings:healpix(6)"
>
>     - Some table-level indication of the order:
>          <TABLE>
>            <PARAM name="healpix-order" datatype="int" value="6">
>            <FIELD datatype=int ucd="pos.healpix"/>
>              ...
>          </TABLE>
>        this would work because in practice, it's hard to imagine you
>        could have multiple columns in a single table with different
>        healpix orders.  This is somewhat analogous to how the
>        ad-hoc FITS healpix serialization works.
>        Note it still needs some convention to identify the healpix-order
>        PARAM.
>
>     - Some business with GROUP/FIELDref/PARAM elements at table level.
>       Note this also needs some convention to identify the healpix-order.
>
>     - Reinvent UCD syntax????
>
>
> Actually it is even worse than this: there are two alternative
> conventional schemes for assigning HEALPix indices to a tiling
> at a given order, known as NESTED and RING, and you need to know
> which one is intended.  Furthermore, the actual sky position
> corresponding to a given pixel is dependent on how the tiling is
> attached to the celestial sphere (e.g. equatorial, ecliptic, galactic).
> So even if you know N you don't have enough explicit information
> to make sense of a healpix index.  However, we are currently
> following MOC in assuming the NESTED scheme, and it's probably
> reasonable to take the sky system as implicit, so we're ignoring
> those details for now.
>
> Any bright ideas, wise comments etc welcome.
>
> Mark
>
> --
> Mark Taylor   Astronomical Programmer   Physics, Bristol University, UK
> m.b.taylor at bris.ac.uk +44-117-9288776  http://www.star.bris.ac.uk/~mbt/

From M.B.Taylor at bristol.ac.uk  Mon Aug  8 22:49:58 2016
From: M.B.Taylor at bristol.ac.uk (Mark Taylor)
Date: Mon, 8 Aug 2016 21:49:58 +0100 (BST)
Subject: Marking up HEALPix index columns in VOTable
In-Reply-To: <92d36f6c-b814-a3a5-2d6e-8b965db04a23@astro.unistra.fr>
References: <alpine.LRH.2.20.1608081750110.29860@andromeda.star.bris.ac.uk>
	<92d36f6c-b814-a3a5-2d6e-8b965db04a23@astro.unistra.fr>
Message-ID: <alpine.LRH.2.20.1608082056530.4035@localhost>

Thomas,

the primary case we're thinking about here is the results of TAP queries.
For instance, consider the following ADQL, which uses a custom
User-Defined Function implemented by Markus's TAP service:

    SELECT ivo_healpix_index(raj2000, dej2000, 8) AS hpx8, COUNT(*) as nsrc
    FROM wise.main
    GROUP BY hpx8
    ORDER BY hpx8

This generates a histogram binned by healpix index, or to put it
another way an all-sky density map.  Since it's TAP, the result
is a table, typically transferred in VOTable format.  The question is,
how does the TAP service mark up the column resulting from
the ivo_healpix_index UDF so that clients know what they're getting
and can treat them accordingly, e.g. when attempting to make a
healpix map plot?

More generally, I'm adding various bits of healpix-related
functionality to topcat/stilts (density map construction and
visualisation).  This kind of data set really does have the
form of a table, so it seems like you should be able to serialize
it with appropriate metadata in VOTable form.  I admit it also
makes sense to think of some such datasets as image-like in
some circumstances too.

Mark

On Mon, 8 Aug 2016, Thomas Boch wrote:

> Hi Mark,
> 
> what's the motivation to have HEALPix maps in VOTable ?
> Not to say I'm against the idea, but I'd like to understand better the use
> case first. If had to output HEALPix maps, I'll go with the FITS serialization
> as binary tables (and associated keywords ORDERING, COORDSYS, NSIDE) which can
> be produced/is understood by the HEALPix library and the tools using it.
> 
> Cheers,
> Thomas
> 
> Le 08/08/2016 ? 18:55, Mark Taylor a ?crit :
> > [I've crossposted this to apps and semantics, but I suggest
> > followups to Apps only]
> > 
> > Dear colleagues,
> > 
> > Gregory Mantelet, Markus Demleitner and I have been having some
> > discussions about exchange of HEALPix maps within the VO.
> > 
> > The type of data we're considering is a table for which one column
> > contains a HEALPix index (an integer which identifies a tile on the sky),
> > and other columns contain quantities relating to to that tile
> > (source density, extinction, mean G magnitude, whatever).
> > The question we're trying to answer is: how does a data producer
> > mark up the healpix-index column in a VOTable so that consumers
> > can recognise it as such?
> > 
> > The following UCD1+ is defined:
> > 
> >      Q  |  pos.healpix      |  Hierarchical Equal Area IsoLatitude
> > Pixelization
> > 
> > So far so good; however, marking up a column like this provides
> > insufficient information to make it useful, because to make sense
> > of a HEALPix index you need to know what Order N of tiling it represents
> > (HEALPix splits the sky into 12*4^N tiles, where N is an integer
> > that for practical purposes falls in the range 0..29).
> > Since UCD words cannot be parameterised (beyond composing them with
> > other UCD words) there doesn't seem to be any way to encode this
> > Order information in the UCD.
> > 
> > Markus's clever idea is to do something like this:
> > 
> >       <FIELD datatype="int" ucd="pos.healpix">
> >         <VALUES type="legal">
> >           <MAX>49151</MAX>
> >         </VALUES>
> >       </FIELD>
> > 
> > Since the legal maximum value for the column is 49151 (=12*(4^6)-1),
> > it's possible to infer that N=6 for this healpix column.  Note that
> > since type="legal" this does not say that the actual contents of
> > the column hit that maximum (i.e. some pixels might be absent, but the
> > declaration would not change).
> > 
> > This is kind of horrible, but at the same time the meaning is fairly
> > unambiguous, and it requires no new standardisation activity.
> > So, we are likely to go ahead with marking up HEALPix columns in
> > this way (Markus's and Gregory's services will emit VOTables like
> > this, and topcat will understand them) unless anybody persuades
> > us different.
> > 
> > We have considered various other options too, but on balance we
> > think they're even worse.  Briefly:
> > 
> >     - Abuse UCDs by trying to parameterise them:
> >          pos.healpix(6)?
> >          pos.healpix;index=6?
> > 
> >     - Introduce new UCD words to (0<=N<=29, so the number of new words
> >       would be quite, but not ridiculously, large):
> >          pos.healpix0, pos.healpix1, ... pos.healpix29?
> >          pos.healpix;arith.0, pos.healpix;arith.1, ... pos.healpix;arith.29
> > 
> >     - Xtype magic:
> >          xtype="healpix(6)"
> >          xtype="tilings:healpix(6)"
> > 
> >     - Some table-level indication of the order:
> >          <TABLE>
> >            <PARAM name="healpix-order" datatype="int" value="6">
> >            <FIELD datatype=int ucd="pos.healpix"/>
> >              ...
> >          </TABLE>
> >        this would work because in practice, it's hard to imagine you
> >        could have multiple columns in a single table with different
> >        healpix orders.  This is somewhat analogous to how the
> >        ad-hoc FITS healpix serialization works.
> >        Note it still needs some convention to identify the healpix-order
> >        PARAM.
> > 
> >     - Some business with GROUP/FIELDref/PARAM elements at table level.
> >       Note this also needs some convention to identify the healpix-order.
> > 
> >     - Reinvent UCD syntax????
> > 
> > 
> > Actually it is even worse than this: there are two alternative
> > conventional schemes for assigning HEALPix indices to a tiling
> > at a given order, known as NESTED and RING, and you need to know
> > which one is intended.  Furthermore, the actual sky position
> > corresponding to a given pixel is dependent on how the tiling is
> > attached to the celestial sphere (e.g. equatorial, ecliptic, galactic).
> > So even if you know N you don't have enough explicit information
> > to make sense of a healpix index.  However, we are currently
> > following MOC in assuming the NESTED scheme, and it's probably
> > reasonable to take the sky system as implicit, so we're ignoring
> > those details for now.
> > 
> > Any bright ideas, wise comments etc welcome.
> > 
> > Mark
> > 
> > --
> > Mark Taylor   Astronomical Programmer   Physics, Bristol University, UK
> > m.b.taylor at bris.ac.uk +44-117-9288776  http://www.star.bris.ac.uk/~mbt/
> 

--
Mark Taylor   Astronomical Programmer   Physics, Bristol University, UK
m.b.taylor at bris.ac.uk +44-117-9288776  http://www.star.bris.ac.uk/~mbt/

From M.B.Taylor at bristol.ac.uk  Mon Aug  8 22:54:53 2016
From: M.B.Taylor at bristol.ac.uk (Mark Taylor)
Date: Mon, 8 Aug 2016 21:54:53 +0100 (BST)
Subject: Marking up HEALPix index columns in VOTable
In-Reply-To: <277E2FEB-E7E2-409F-9A04-9830522B8FA0@obspm.fr>
References: <alpine.LRH.2.20.1608081750110.29860@andromeda.star.bris.ac.uk>
	<277E2FEB-E7E2-409F-9A04-9830522B8FA0@obspm.fr>
Message-ID: <alpine.LRH.2.20.1608082150490.4035@localhost>

Stephane,

2 coordinates (nside and tile number) suggests that you have different
Nside for each row of the table.  That's possible, but this
variable-tile-size scenario is not what I had in mind
(and in fact it would sidestep the difficulty that I'm talking about
here, since you then would have a place to put the Nside/order value).  
Is that really what you mean, or are you talking about a uniform
tile size over the whole planetary surface?

Mark

On Mon, 8 Aug 2016, St?phane Erard wrote:

> Dear Mark and all
> 
> I've been wondering about the same thing last spring for possible use on planetary surfaces (~spherical ones at least)
> To me that was clearly a system with 2 coordinates, Nside and tile number (plus possibly ordering nested/ring as a 3rd one - it doesn't hurt in EPNCore since we always have 3 spatial coordinates available). 
> Your baseline solution may be better if there is a simple way to parse it in the tools.
> 
> Regards
> St?phane
> 
> Le 8 ao?t 2016 ? 18:55, Mark Taylor <M.B.Taylor at bristol.ac.uk> a ?crit :
> 
> > [I've crossposted this to apps and semantics, but I suggest
> > followups to Apps only]
> > 
> > Dear colleagues,
> > 
> > Gregory Mantelet, Markus Demleitner and I have been having some
> > discussions about exchange of HEALPix maps within the VO.
> > 
> > The type of data we're considering is a table for which one column
> > contains a HEALPix index (an integer which identifies a tile on the sky),
> > and other columns contain quantities relating to to that tile
> > (source density, extinction, mean G magnitude, whatever).
> > The question we're trying to answer is: how does a data producer
> > mark up the healpix-index column in a VOTable so that consumers
> > can recognise it as such?
> > 
> > The following UCD1+ is defined:
> > 
> >    Q  |  pos.healpix      |  Hierarchical Equal Area IsoLatitude Pixelization
> > 
> > So far so good; however, marking up a column like this provides
> > insufficient information to make it useful, because to make sense
> > of a HEALPix index you need to know what Order N of tiling it represents
> > (HEALPix splits the sky into 12*4^N tiles, where N is an integer
> > that for practical purposes falls in the range 0..29).
> > Since UCD words cannot be parameterised (beyond composing them with
> > other UCD words) there doesn't seem to be any way to encode this
> > Order information in the UCD.
> > 
> > Markus's clever idea is to do something like this:
> > 
> >     <FIELD datatype="int" ucd="pos.healpix">
> >       <VALUES type="legal">
> >         <MAX>49151</MAX>
> >       </VALUES>
> >     </FIELD>
> > 
> > Since the legal maximum value for the column is 49151 (=12*(4^6)-1),
> > it's possible to infer that N=6 for this healpix column.  Note that
> > since type="legal" this does not say that the actual contents of
> > the column hit that maximum (i.e. some pixels might be absent, but the
> > declaration would not change).
> > 
> > This is kind of horrible, but at the same time the meaning is fairly
> > unambiguous, and it requires no new standardisation activity.
> > So, we are likely to go ahead with marking up HEALPix columns in
> > this way (Markus's and Gregory's services will emit VOTables like
> > this, and topcat will understand them) unless anybody persuades
> > us different.
> > 
> > We have considered various other options too, but on balance we
> > think they're even worse.  Briefly:
> > 
> >   - Abuse UCDs by trying to parameterise them:
> >        pos.healpix(6)?
> >        pos.healpix;index=6?
> > 
> >   - Introduce new UCD words to (0<=N<=29, so the number of new words
> >     would be quite, but not ridiculously, large):
> >        pos.healpix0, pos.healpix1, ... pos.healpix29?
> >        pos.healpix;arith.0, pos.healpix;arith.1, ... pos.healpix;arith.29
> > 
> >   - Xtype magic:
> >        xtype="healpix(6)"
> >        xtype="tilings:healpix(6)"
> > 
> >   - Some table-level indication of the order:
> >        <TABLE>
> >          <PARAM name="healpix-order" datatype="int" value="6">
> >          <FIELD datatype=int ucd="pos.healpix"/>
> >            ...
> >        </TABLE>
> >      this would work because in practice, it's hard to imagine you
> >      could have multiple columns in a single table with different
> >      healpix orders.  This is somewhat analogous to how the
> >      ad-hoc FITS healpix serialization works.
> >      Note it still needs some convention to identify the healpix-order
> >      PARAM.
> > 
> >   - Some business with GROUP/FIELDref/PARAM elements at table level.
> >     Note this also needs some convention to identify the healpix-order.
> > 
> >   - Reinvent UCD syntax????
> > 
> > 
> > Actually it is even worse than this: there are two alternative
> > conventional schemes for assigning HEALPix indices to a tiling
> > at a given order, known as NESTED and RING, and you need to know
> > which one is intended.  Furthermore, the actual sky position
> > corresponding to a given pixel is dependent on how the tiling is
> > attached to the celestial sphere (e.g. equatorial, ecliptic, galactic).
> > So even if you know N you don't have enough explicit information
> > to make sense of a healpix index.  However, we are currently
> > following MOC in assuming the NESTED scheme, and it's probably
> > reasonable to take the sky system as implicit, so we're ignoring
> > those details for now.
> > 
> > Any bright ideas, wise comments etc welcome.
> > 
> > Mark
> > 
> > --
> > Mark Taylor   Astronomical Programmer   Physics, Bristol University, UK
> > m.b.taylor at bris.ac.uk +44-117-9288776  http://www.star.bris.ac.uk/~mbt/
> 
> 

--
Mark Taylor   Astronomical Programmer   Physics, Bristol University, UK
m.b.taylor at bris.ac.uk +44-117-9288776  http://www.star.bris.ac.uk/~mbt/

From hessman at astro.physik.uni-goettingen.de  Tue Aug  9 07:36:39 2016
From: hessman at astro.physik.uni-goettingen.de (Frederic V. Hessman)
Date: Tue, 9 Aug 2016 07:36:39 +0200
Subject: Marking up HEALPix index columns in VOTable
In-Reply-To: <alpine.LRH.2.20.1608081750110.29860@andromeda.star.bris.ac.uk>
References: <alpine.LRH.2.20.1608081750110.29860@andromeda.star.bris.ac.uk>
Message-ID: <A211F888-4106-4028-92EC-4D1031B4495A@astro.physik.uni-goettingen.de>

Mark,

> On 8 Aug 2016, at 18:55, Mark Taylor <m.b.taylor at bristol.ac.uk> wrote:
> 
> Gregory Mantelet, Markus Demleitner and I have been having some
> discussions about exchange of HEALPix maps within the VO.
> ...
> So far so good; however, marking up a column like this provides
> insufficient information to make it useful, because to make sense
> of a HEALPix index you need to know what Order N of tiling it represents
> (HEALPix splits the sky into 12*4^N tiles, where N is an integer
> that for practical purposes falls in the range 0..29).
> Since UCD words cannot be parameterised (beyond composing them with
> other UCD words) there doesn't seem to be any way to encode this
> Order information in the UCD.
> 
> Markus's clever idea is to do something like this:
> 
>     <FIELD datatype="int" ucd="pos.healpix">
>       <VALUES type="legal">
>         <MAX>49151</MAX>
>       </VALUES>
>     </FIELD>
> 
> Since the legal maximum value for the column is 49151 (=12*(4^6)-1),
> it's possible to infer that N=6 for this healpix column.  Note that
> since type="legal" this does not say that the actual contents of
> the column hit that maximum (i.e. some pixels might be absent, but the
> declaration would not change).
> 
> This is kind of horrible, but at the same time the meaning is fairly
> unambiguous, and it requires no new standardisation activity.
> So, we are likely to go ahead with marking up HEALPix columns in
> this way (Markus's and Gregory's services will emit VOTables like
> this, and topcat will understand them) unless anybody persuades
> us different.

Clever but beyond horrible.  Why can?t you simply

>   - Some business with GROUP/FIELDref/PARAM elements at table level.
>     Note this also needs some convention to identify the healpix-order.

Yes, but the number of metadata elements needed is very small, say

	?pos.healpix.order"	=	pos.healpix;meta.number	=	N

	?pos.healpix.tiling"	=	pos.healpix;pos.wcs.ctype	=	?NESTED? or ?RING"

The first works because the map needs some other number other than the number of tiles and the only other HEALPIX number is N.

I used pos.ctype in the 2nd in a slightly different manner from what we?re used to, but this UCD should be freed from its FITS fetters, since the meaning should be clear - the tiling scheme expresses a world coordinate system ?type?.

Rick


From thomas.boch at astro.unistra.fr  Wed Aug 10 15:07:50 2016
From: thomas.boch at astro.unistra.fr (Thomas Boch)
Date: Wed, 10 Aug 2016 15:07:50 +0200
Subject: Marking up HEALPix index columns in VOTable
In-Reply-To: <alpine.LRH.2.20.1608082056530.4035@localhost>
References: <alpine.LRH.2.20.1608081750110.29860@andromeda.star.bris.ac.uk>
	<92d36f6c-b814-a3a5-2d6e-8b965db04a23@astro.unistra.fr>
	<alpine.LRH.2.20.1608082056530.4035@localhost>
Message-ID: <57AB2726.6010208@astro.unistra.fr>

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

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

--
Thomas

Le 08/08/2016 10:49 PM, Mark Taylor a ?crit :
> Thomas,
>
> the primary case we're thinking about here is the results of TAP queries.
> For instance, consider the following ADQL, which uses a custom
> User-Defined Function implemented by Markus's TAP service:
>
>      SELECT ivo_healpix_index(raj2000, dej2000, 8) AS hpx8, COUNT(*) as nsrc
>      FROM wise.main
>      GROUP BY hpx8
>      ORDER BY hpx8
>
> This generates a histogram binned by healpix index, or to put it
> another way an all-sky density map.  Since it's TAP, the result
> is a table, typically transferred in VOTable format.  The question is,
> how does the TAP service mark up the column resulting from
> the ivo_healpix_index UDF so that clients know what they're getting
> and can treat them accordingly, e.g. when attempting to make a
> healpix map plot?
>
> More generally, I'm adding various bits of healpix-related
> functionality to topcat/stilts (density map construction and
> visualisation).  This kind of data set really does have the
> form of a table, so it seems like you should be able to serialize
> it with appropriate metadata in VOTable form.  I admit it also
> makes sense to think of some such datasets as image-like in
> some circumstances too.
>
> Mark
>
> On Mon, 8 Aug 2016, Thomas Boch wrote:
>
>> Hi Mark,
>>
>> what's the motivation to have HEALPix maps in VOTable ?
>> Not to say I'm against the idea, but I'd like to understand better the use
>> case first. If had to output HEALPix maps, I'll go with the FITS serialization
>> as binary tables (and associated keywords ORDERING, COORDSYS, NSIDE) which can
>> be produced/is understood by the HEALPix library and the tools using it.
>>
>> Cheers,
>> Thomas
>>
>> Le 08/08/2016 ? 18:55, Mark Taylor a ?crit :
>>> [I've crossposted this to apps and semantics, but I suggest
>>> followups to Apps only]
>>>
>>> Dear colleagues,
>>>
>>> Gregory Mantelet, Markus Demleitner and I have been having some
>>> discussions about exchange of HEALPix maps within the VO.
>>>
>>> The type of data we're considering is a table for which one column
>>> contains a HEALPix index (an integer which identifies a tile on the sky),
>>> and other columns contain quantities relating to to that tile
>>> (source density, extinction, mean G magnitude, whatever).
>>> The question we're trying to answer is: how does a data producer
>>> mark up the healpix-index column in a VOTable so that consumers
>>> can recognise it as such?
>>>
>>> The following UCD1+ is defined:
>>>
>>>       Q  |  pos.healpix      |  Hierarchical Equal Area IsoLatitude
>>> Pixelization
>>>
>>> So far so good; however, marking up a column like this provides
>>> insufficient information to make it useful, because to make sense
>>> of a HEALPix index you need to know what Order N of tiling it represents
>>> (HEALPix splits the sky into 12*4^N tiles, where N is an integer
>>> that for practical purposes falls in the range 0..29).
>>> Since UCD words cannot be parameterised (beyond composing them with
>>> other UCD words) there doesn't seem to be any way to encode this
>>> Order information in the UCD.
>>>
>>> Markus's clever idea is to do something like this:
>>>
>>>        <FIELD datatype="int" ucd="pos.healpix">
>>>          <VALUES type="legal">
>>>            <MAX>49151</MAX>
>>>          </VALUES>
>>>        </FIELD>
>>>
>>> Since the legal maximum value for the column is 49151 (=12*(4^6)-1),
>>> it's possible to infer that N=6 for this healpix column.  Note that
>>> since type="legal" this does not say that the actual contents of
>>> the column hit that maximum (i.e. some pixels might be absent, but the
>>> declaration would not change).
>>>
>>> This is kind of horrible, but at the same time the meaning is fairly
>>> unambiguous, and it requires no new standardisation activity.
>>> So, we are likely to go ahead with marking up HEALPix columns in
>>> this way (Markus's and Gregory's services will emit VOTables like
>>> this, and topcat will understand them) unless anybody persuades
>>> us different.
>>>
>>> We have considered various other options too, but on balance we
>>> think they're even worse.  Briefly:
>>>
>>>      - Abuse UCDs by trying to parameterise them:
>>>           pos.healpix(6)?
>>>           pos.healpix;index=6?
>>>
>>>      - Introduce new UCD words to (0<=N<=29, so the number of new words
>>>        would be quite, but not ridiculously, large):
>>>           pos.healpix0, pos.healpix1, ... pos.healpix29?
>>>           pos.healpix;arith.0, pos.healpix;arith.1, ... pos.healpix;arith.29
>>>
>>>      - Xtype magic:
>>>           xtype="healpix(6)"
>>>           xtype="tilings:healpix(6)"
>>>
>>>      - Some table-level indication of the order:
>>>           <TABLE>
>>>             <PARAM name="healpix-order" datatype="int" value="6">
>>>             <FIELD datatype=int ucd="pos.healpix"/>
>>>               ...
>>>           </TABLE>
>>>         this would work because in practice, it's hard to imagine you
>>>         could have multiple columns in a single table with different
>>>         healpix orders.  This is somewhat analogous to how the
>>>         ad-hoc FITS healpix serialization works.
>>>         Note it still needs some convention to identify the healpix-order
>>>         PARAM.
>>>
>>>      - Some business with GROUP/FIELDref/PARAM elements at table level.
>>>        Note this also needs some convention to identify the healpix-order.
>>>
>>>      - Reinvent UCD syntax????
>>>
>>>
>>> Actually it is even worse than this: there are two alternative
>>> conventional schemes for assigning HEALPix indices to a tiling
>>> at a given order, known as NESTED and RING, and you need to know
>>> which one is intended.  Furthermore, the actual sky position
>>> corresponding to a given pixel is dependent on how the tiling is
>>> attached to the celestial sphere (e.g. equatorial, ecliptic, galactic).
>>> So even if you know N you don't have enough explicit information
>>> to make sense of a healpix index.  However, we are currently
>>> following MOC in assuming the NESTED scheme, and it's probably
>>> reasonable to take the sky system as implicit, so we're ignoring
>>> those details for now.
>>>
>>> Any bright ideas, wise comments etc welcome.
>>>
>>> Mark
>>>
>>> --
>>> Mark Taylor   Astronomical Programmer   Physics, Bristol University, UK
>>> m.b.taylor at bris.ac.uk +44-117-9288776  http://www.star.bris.ac.uk/~mbt/
> --
> Mark Taylor   Astronomical Programmer   Physics, Bristol University, UK
> m.b.taylor at bris.ac.uk +44-117-9288776  http://www.star.bris.ac.uk/~mbt/

From msdemlei at ari.uni-heidelberg.de  Thu Aug 11 11:13:45 2016
From: msdemlei at ari.uni-heidelberg.de (Markus Demleitner)
Date: Thu, 11 Aug 2016 11:13:45 +0200
Subject: Marking up HEALPix index columns in VOTable
In-Reply-To: <57AB2726.6010208@astro.unistra.fr>
References: <alpine.LRH.2.20.1608081750110.29860@andromeda.star.bris.ac.uk>
	<92d36f6c-b814-a3a5-2d6e-8b965db04a23@astro.unistra.fr>
	<alpine.LRH.2.20.1608082056530.4035@localhost>
	<57AB2726.6010208@astro.unistra.fr>
Message-ID: <20160811091345.GA2286@victor>

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

From molinaro at oats.inaf.it  Thu Aug 11 16:03:37 2016
From: molinaro at oats.inaf.it (Marco Molinaro)
Date: Thu, 11 Aug 2016 16:03:37 +0200
Subject: Marking up HEALPix index columns in VOTable
In-Reply-To: <20160811091345.GA2286@victor>
References: <alpine.LRH.2.20.1608081750110.29860@andromeda.star.bris.ac.uk>
	<92d36f6c-b814-a3a5-2d6e-8b965db04a23@astro.unistra.fr>
	<alpine.LRH.2.20.1608082056530.4035@localhost>
	<57AB2726.6010208@astro.unistra.fr> <20160811091345.GA2286@victor>
Message-ID: <CABiOC77POHvnOgM64W=m8snY8oX+6YmtC09frMyMKHdNFRmz=Q@mail.gmail.com>

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

From msdemlei at ari.uni-heidelberg.de  Mon Aug 15 10:04:00 2016
From: msdemlei at ari.uni-heidelberg.de (Markus Demleitner)
Date: Mon, 15 Aug 2016 10:04:00 +0200
Subject: Marking up HEALPix index columns in VOTable
In-Reply-To: <CABiOC77POHvnOgM64W=m8snY8oX+6YmtC09frMyMKHdNFRmz=Q@mail.gmail.com>
References: <alpine.LRH.2.20.1608081750110.29860@andromeda.star.bris.ac.uk>
	<92d36f6c-b814-a3a5-2d6e-8b965db04a23@astro.unistra.fr>
	<alpine.LRH.2.20.1608082056530.4035@localhost>
	<57AB2726.6010208@astro.unistra.fr> <20160811091345.GA2286@victor>
	<CABiOC77POHvnOgM64W=m8snY8oX+6YmtC09frMyMKHdNFRmz=Q@mail.gmail.com>
Message-ID: <20160815080400.GC8399@victor>

Hi Apps,

On Thu, Aug 11, 2016 at 04:03:37PM +0200, Marco Molinaro wrote:
> 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.

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

 

From molinaro at oats.inaf.it  Tue Aug 16 10:35:30 2016
From: molinaro at oats.inaf.it (Marco Molinaro)
Date: Tue, 16 Aug 2016 10:35:30 +0200
Subject: Marking up HEALPix index columns in VOTable
In-Reply-To: <20160815080400.GC8399@victor>
References: <alpine.LRH.2.20.1608081750110.29860@andromeda.star.bris.ac.uk>
	<92d36f6c-b814-a3a5-2d6e-8b965db04a23@astro.unistra.fr>
	<alpine.LRH.2.20.1608082056530.4035@localhost>
	<57AB2726.6010208@astro.unistra.fr> <20160811091345.GA2286@victor>
	<CABiOC77POHvnOgM64W=m8snY8oX+6YmtC09frMyMKHdNFRmz=Q@mail.gmail.com>
	<20160815080400.GC8399@victor>
Message-ID: <CABiOC74O=arjRZ1jaLJC0ueeyPJ-jN40UJxKcnfym6=sAnufMg@mail.gmail.com>

Hi Markus, App-ers,

2016-08-15 10:04 GMT+02:00 Markus Demleitner <msdemlei at ari.uni-heidelberg.de>:
> Hi Apps,
>
> On Thu, Aug 11, 2016 at 04:03:37PM +0200, Marco Molinaro wrote:
>> 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.
>
> 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?

To me it's ok, if we want to avoid GROUPing around or add an
additional PARAM to the table.
The FIELD element must be there in any case, so having the info
directly within it it's fair to me, even if you need a little
computation to extract the order value and you have to keep in mind
the meaning of the MAX VALUE there.

Marco

>
>          -- Markus
>
>

From thomas.boch at astro.unistra.fr  Wed Aug 17 09:11:06 2016
From: thomas.boch at astro.unistra.fr (Thomas Boch)
Date: Wed, 17 Aug 2016 09:11:06 +0200
Subject: Marking up HEALPix index columns in VOTable
In-Reply-To: <20160815080400.GC8399@victor>
References: <alpine.LRH.2.20.1608081750110.29860@andromeda.star.bris.ac.uk>
	<92d36f6c-b814-a3a5-2d6e-8b965db04a23@astro.unistra.fr>
	<alpine.LRH.2.20.1608082056530.4035@localhost>
	<57AB2726.6010208@astro.unistra.fr> <20160811091345.GA2286@victor>
	<CABiOC77POHvnOgM64W=m8snY8oX+6YmtC09frMyMKHdNFRmz=Q@mail.gmail.com>
	<20160815080400.GC8399@victor>
Message-ID: <57B40E0A.1050901@astro.unistra.fr>

Hi Markus,

I don't like the VALUES solution because it's semantically poor and not 
really explicit. My preference goes to the GROUPing because it's 
self-contained and descriptive.

Thomas

Le 08/15/2016 10:04 AM, Markus Demleitner a ?crit :
> Hi Apps,
>
> On Thu, Aug 11, 2016 at 04:03:37PM +0200, Marco Molinaro wrote:
>> 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.
> 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
>
>   

From laurent.michel at astro.unistra.fr  Wed Aug 17 15:18:20 2016
From: laurent.michel at astro.unistra.fr (Laurent Michel)
Date: Wed, 17 Aug 2016 15:18:20 +0200
Subject: Marking up HEALPix index columns in VOTable
In-Reply-To: <57B40E0A.1050901@astro.unistra.fr>
References: <alpine.LRH.2.20.1608081750110.29860@andromeda.star.bris.ac.uk>
	<92d36f6c-b814-a3a5-2d6e-8b965db04a23@astro.unistra.fr>
	<alpine.LRH.2.20.1608082056530.4035@localhost>
	<57AB2726.6010208@astro.unistra.fr> <20160811091345.GA2286@victor>
	<CABiOC77POHvnOgM64W=m8snY8oX+6YmtC09frMyMKHdNFRmz=Q@mail.gmail.com>
	<20160815080400.GC8399@victor> <57B40E0A.1050901@astro.unistra.fr>
Message-ID: <57B4641C.70200@astro.unistra.fr>

Hi,

I agree with Thomas.
Encoding nside is in a fields MAX_VALUE can be used for an had-hoc implementation but not at a standard level. I would add to 
the Thomas's arguments the lack of consistency. What  about if the value does does not match Value =12*(4^N)-1?
Using PARAMs is clearly a safer way to identify the healpix tessellation.
Does it worth to take into account the case where multiple Healpix columns must be described? We can consider that just one 
Healpix column, the MAIN one, has to be described by the three PARAMs. We can introduce a "pos.main.healpix" UCD in a similar 
way to the position columns to make sure to address the right column.

Laurent



Le 17/08/2016 09:11, Thomas Boch a ?crit :
> Hi Markus,
>
> I don't like the VALUES solution because it's semantically poor and not really explicit. My preference goes to the GROUPing
> because it's self-contained and descriptive.
>
> Thomas
>
> Le 08/15/2016 10:04 AM, Markus Demleitner a ?crit :
>> Hi Apps,
>>
>> On Thu, Aug 11, 2016 at 04:03:37PM +0200, Marco Molinaro wrote:
>>> 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.
>> 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
>>

-- 
jesuischarlie/Tunis/Paris/Bruxelles

Laurent Michel
SSC XMM-Newton
T?l : +33 (0)3 68 85 24 37
Fax : +33 (0)3 )3 68 85 24 32
laurent.michel at astro.unistra.fr <mailto:laurent.michel at astro.unistra.fr>
Universit? de Strasbourg <http://www.unistra.fr>
Observatoire Astronomique
11 Rue de l'Universit?
F - 67200 Strasbourg
http://amwdb.u-strasbg.fr/HighEnergy/spip.php?rubrique34

From francois.bonnarel at astro.unistra.fr  Wed Aug 17 18:16:45 2016
From: francois.bonnarel at astro.unistra.fr (=?UTF-8?Q?Fran=c3=a7ois_Bonnarel?=)
Date: Wed, 17 Aug 2016 18:16:45 +0200
Subject: Marking up HEALPix index columns in VOTable
In-Reply-To: <57B4641C.70200@astro.unistra.fr>
References: <alpine.LRH.2.20.1608081750110.29860@andromeda.star.bris.ac.uk>
	<92d36f6c-b814-a3a5-2d6e-8b965db04a23@astro.unistra.fr>
	<alpine.LRH.2.20.1608082056530.4035@localhost>
	<57AB2726.6010208@astro.unistra.fr> <20160811091345.GA2286@victor>
	<CABiOC77POHvnOgM64W=m8snY8oX+6YmtC09frMyMKHdNFRmz=Q@mail.gmail.com>
	<20160815080400.GC8399@victor> <57B40E0A.1050901@astro.unistra.fr>
	<57B4641C.70200@astro.unistra.fr>
Message-ID: <57B48DED.50601@astro.unistra.fr>

Hi all,
   - I also prefer a solution with GROUPS and PARAMS to describe the 
HEALPIX metadata. It seems to be more flexible and reusable for other 
use cases than the only "single column with the HEALPIX index in a 
single HEALPIX nside, scheme and RefFrame)

   - the right place to define the piece of HEALPIX metadata should be 
the stc datamodel. It is true that STC2 draft allready has the HEALPIX 
option in the CoordFlavor enumeration. UCD combination should not be 
used for accurate attribute definition but more to rapidly identfy 
anything related to healpix (ucd=pos.healpix). If we are not able to 
stableize the stc utype now (Markus argument), then let just define 
"names" for that in the standard. This is a solution which has been used 
for ObsCORE. Obscore Table names uniquely identify the model attribute 
(and ivoa role) of the content of the colomn.

Cheers
Fran?ois

Le 17/08/2016 15:18, Laurent Michel a ?crit :
> Hi,
>
> I agree with Thomas.
> Encoding nside is in a fields MAX_VALUE can be used for an had-hoc 
> implementation but not at a standard level. I would add to the 
> Thomas's arguments the lack of consistency. What  about if the value 
> does does not match Value =12*(4^N)-1?
> Using PARAMs is clearly a safer way to identify the healpix tessellation.
> Does it worth to take into account the case where multiple Healpix 
> columns must be described? We can consider that just one Healpix 
> column, the MAIN one, has to be described by the three PARAMs. We can 
> introduce a "pos.main.healpix" UCD in a similar way to the position 
> columns to make sure to address the right column.
>
> Laurent
>
>
>
> Le 17/08/2016 09:11, Thomas Boch a ?crit :
>> Hi Markus,
>>
>> I don't like the VALUES solution because it's semantically poor and 
>> not really explicit. My preference goes to the GROUPing
>> because it's self-contained and descriptive.
>>
>> Thomas
>>
>> Le 08/15/2016 10:04 AM, Markus Demleitner a ?crit :
>>> Hi Apps,
>>>
>>> On Thu, Aug 11, 2016 at 04:03:37PM +0200, Marco Molinaro wrote:
>>>> 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.
>>> 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
>>>
>

From M.B.Taylor at bristol.ac.uk  Thu Aug 25 12:23:20 2016
From: M.B.Taylor at bristol.ac.uk (Mark Taylor)
Date: Thu, 25 Aug 2016 11:23:20 +0100 (BST)
Subject: Marking up HEALPix index columns in VOTable
In-Reply-To: <20160815080400.GC8399@victor>
References: <alpine.LRH.2.20.1608081750110.29860@andromeda.star.bris.ac.uk>
	<92d36f6c-b814-a3a5-2d6e-8b965db04a23@astro.unistra.fr>
	<alpine.LRH.2.20.1608082056530.4035@localhost>
	<57AB2726.6010208@astro.unistra.fr> <20160811091345.GA2286@victor>
	<CABiOC77POHvnOgM64W=m8snY8oX+6YmtC09frMyMKHdNFRmz=Q@mail.gmail.com>
	<20160815080400.GC8399@victor>
Message-ID: <alpine.LRH.2.20.1608251105280.13385@andromeda.star.bris.ac.uk>

Hi all,

sorry for the belated response, I've just got back from holiday.

On Mon, 15 Aug 2016, Markus Demleitner wrote:

> On Thu, Aug 11, 2016 at 04:03:37PM +0200, Marco Molinaro wrote:
> > 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.
> 
> 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.

While I can see that it's not impossible in principle to have
multiple columns using HEALPix indices with different orders
in a single table, I'm struggling to think of any physical 
situation where that would be a desirable/meaningful thing to do.

But: yes I think some form of grouping should be able to solve 
Marco's problem.

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

Agree on all points.

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

meta.number's documentation is as follows:

    "Number (of things; e.g. nb of object in an image)"

which, assuming "nb" here means count, really doesn't fit healpix
order (what are the things it's a nb of?  You could argue that it
makes sense for NSIDE, though I really don't want to use NSIDE).
So, using meta.number is already abusing the existing UCD documented
semantics.  Agreed meta.order would work well - but that doesn't
exist in the current UCD list.

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

Yes do-able, though fiddly and abuses meta.number.
If it's the consensus I'll implement it ...

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

... but I'd still be reasonably happy to use VALUES as an ad-hoc
solution for now if we want to do it properly on a longer timescale
(e.g. meta.order and maybe meta.scheme in a future UCD list,
or follow Francois's argument and define names in STC2).

Mark

--
Mark Taylor   Astronomical Programmer   Physics, Bristol University, UK
m.b.taylor at bris.ac.uk +44-117-9288776  http://www.star.bris.ac.uk/~mbt/

From wlandry at caltech.edu  Thu Aug 25 15:08:30 2016
From: wlandry at caltech.edu (Walter Landry)
Date: Thu, 25 Aug 2016 06:08:30 -0700 (PDT)
Subject: Marking up HEALPix index columns in VOTable
In-Reply-To: <alpine.LRH.2.20.1608251105280.13385@andromeda.star.bris.ac.uk>
References: <CABiOC77POHvnOgM64W=m8snY8oX+6YmtC09frMyMKHdNFRmz=Q@mail.gmail.com>
	<20160815080400.GC8399@victor>
	<alpine.LRH.2.20.1608251105280.13385@andromeda.star.bris.ac.uk>
Message-ID: <20160825.060830.1034143209756051030.wlandry@caltech.edu>

Mark Taylor <M.B.Taylor at bristol.ac.uk> wrote:
>> On Thu, Aug 11, 2016 at 04:03:37PM +0200, Marco Molinaro wrote:
>> > 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.
>> 
>> 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.
> 
> While I can see that it's not impossible in principle to have
> multiple columns using HEALPix indices with different orders
> in a single table, I'm struggling to think of any physical 
> situation where that would be a desirable/meaningful thing to do.

I could see a case where you have different types of spatial indices.
So one column could be HEALPix and another column is q3c or htm.

Cheers,
Walter Landry

From thomas.boch at astro.unistra.fr  Fri Aug 26 15:00:41 2016
From: thomas.boch at astro.unistra.fr (Thomas Boch)
Date: Fri, 26 Aug 2016 15:00:41 +0200
Subject: Python TAP client library
Message-ID: <57C03D79.9000009@astro.unistra.fr>

Hi Apps,

I'm looking for a Python TAP client library that would allow to query 
(synchronously) a TAP service and retrieve the result as (say) as 
Astropy Table object.
Nothing fancy or especially hard to implement but if someone has already 
developed it, I'd prefer not to reinvent the wheel. I found some intent 
to implement this in astroquery ( see 
https://github.com/astropy/astroquery/issues/277 ) but no actual code yet.

Cheers,
Thomas

From iova at paul.sladen.org  Fri Aug 26 15:23:17 2016
From: iova at paul.sladen.org (Paul Sladen)
Date: Fri, 26 Aug 2016 14:23:17 +0100 (BST)
Subject: Python TAP client library
In-Reply-To: <57C03D79.9000009@astro.unistra.fr>
Message-ID: <Pine.LNX.4.21.1608261421300.3930-100000@starsky.19inch.net>

On Fri, 26 Aug 2016, Thomas Boch wrote:
> I'm looking for a Python TAP client library that would allow to query 
> (synchronously) a TAP service and retrieve the result as (say) as 
> Astropy Table object.

Hello Thomas, would 'python-gavovotable' meet your usecase?

  http://soft.g-vo.org/subpkgs#votable

This is VOtable handling library that happens to include an internal
TAP client.

	-Paul



From mjg at cd3.caltech.edu  Fri Aug 26 15:04:53 2016
From: mjg at cd3.caltech.edu (Matthew Graham)
Date: Fri, 26 Aug 2016 09:04:53 -0400
Subject: Python TAP client library
In-Reply-To: <57C03D79.9000009@astro.unistra.fr>
References: <57C03D79.9000009@astro.unistra.fr>
Message-ID: <0B7A8A34-5627-4E33-A726-6A32F34BE4B0@cd3.caltech.edu>

Hi Thomas,

I use the GAVO client to do this exactly.

-- Matthew


On Aug 26, 2016, at 9:00 AM, Thomas Boch wrote:

> Hi Apps,
> 
> I'm looking for a Python TAP client library that would allow to query (synchronously) a TAP service and retrieve the result as (say) as Astropy Table object.
> Nothing fancy or especially hard to implement but if someone has already developed it, I'd prefer not to reinvent the wheel. I found some intent to implement this in astroquery ( see https://github.com/astropy/astroquery/issues/277 ) but no actual code yet.
> 
> Cheers,
> Thomas
>