In TAP, with few extensions, it could be possible to get Healpix information
and/or to add constraints on Healpix information.
Proposed new features:
- New UDFs:
- ivo_healpix_index(hpx_order INTEGER, position POINT) --> BIGINT
- ivo_healpix_index(hpx_order INTEGER, ra DOUBLE, dec DOUBLE) --> BIGINT
- ivo_healpix_center(hpx_order INTEGER, hpx_index BIGINT) --> POINT
- moc_agg(hpx_order INTEGER, position POINT) --> MOC
- moc_agg(hpx_order INTEGER, hpx_index BIGINT) --> MOC
- Addition of the geometrical type 'MOC' in
DALI (in addition of the already
existing POINT and REGION)
- in VOTable: <FIELD ... datatype="char" arraysize="*" xtype="MOC" />
- a MOC would be serialized into an ASCII representation described in the
appendices of the talk
[Bringing Healpix capability in TAP][http://....].
Example: "10/63-65,87 11/1 13/" (i.e. MOC of order 13 with 4 cells at
order 10 and one cell at order 11)
- using this ASCII serialization, it could be possible to create manually
a MOC using the function REGION(...).
Example: "REGION('1/1,3,4 2/4,25,12-14,21')"
- The
ADQL grammar of some geometrical functions (like AREA, CONTAINS and
INTERSECTS) should be adapted in order to be able to operate on any
function returning geometrical regions. For the moment, it is limited to
POINT, BOX, CIRCLE, POLYGON and REGION. This does not allow the usage
of UDFs returning region, like moc_agg(...) as defined above or REGION(...)
with an ASCII representation of a MOC.
Still to answer:
- How to designate an Healpix-related value (e.g. Hpx index, MOC) in a VOTable?
- UCD? Datatype? XType (xtype='MOC', ok but what about an Hpx index: xtype='HEALPIX'?) Or more complex a VOTable GROUP?
- An Healpix index or derived product always requires 2 additional pieces of
information: scheme ('nested' or 'ring') and order (an integer between 0 and 29).
How to provide them along to the Healpix-related value in a VOTable?
Usage examples:
SELECT ivo_healpix_index(7, POINT(’’, ra, dec)) AS hpx_index,
COUNT(*) AS density
FROM tycho2
GROUP BY hpx_index
- creating a MOC at Healpix order 7 from Tycho2 (or a subset):
SELECT moc_agg(7, POINT(’’, ra, dec)) AS mymoc
FROM tycho2
...
- filtering by Healpix index:
SELECT *
FROM tycho2
WHERE ivo_healpix_index(7, POINT(’’, ra, dec)) IN (12,23,68,69,70)
- filtering by MOC:
- with an ASCII serialization:
SELECT *
FROM tycho2
WHERE 1= CONTAINS(POINT(’’, ra, dec), REGION(’2/12-20 5/60’))
- with a MOC embedded in a VOTable column (or more):
SELECT t.*
FROM tycho2 AS t JOIN TAP_UPLOAD.mymoc AS m
ON 1=CONTAINS(POINT(’’, t.ra, t.dec), m.moc1)
TAP_UPLOAD.mymoc is a normal uploaded VOTable table with a column named
moc1 of type ‘VARCHAR’ and xtype 'MOC'.
- with a MOC formatted into a binary FITS table:
SELECT t.*
FROM tycho2 AS t JOIN TAP_UPLOAD.mymoc AS m
ON 1=CONTAINS(POINT(’’, t.ra, t.dec), m.moc)
Instead of uploading a VOTable, a FITS file would be uploaded (the TAP
implementation has to allow that). The uploaded FITS file has special
headers specifying that it represents neither an image nor a table, but a
MOC. Then, it should be considered as such while used in the
ADQL query.
But TAP allows only the upload of table. So, in order to use the uploaded
MOC, the TAP service has to create a table of only one cell containing the
uploaded MOC (so, one cell for the entire FITS file). As for a "normal"
upload, the name of the table is provided in the HTTP parameter UPLOAD,
but there is no name for the column containing the single MOC and that
we need to refer to in the
ADQL query. To solve this issue, we could agree
on a standard name for this column: let's say "moc". So, on the above
example we had UPLOAD="mymoc,param:moc.fits" which has been uploaded as
the table TAP_UPLOAD.mymoc with only row and one column named "moc".