GammaLib

The GVOTable class should satisfy the following use case (here in Python):

import gammalib
skymap = gammalib.GSkyMap("my_map.fits")
votable = gammalib.GVOTable(skymap)
client = gammalib.GVOClient()
client.send(votable)

The GVOTable class should take a sky map object as constructor argument and translate the sky map information into a VO table. Two cases need to be distinguished: a sky map in a WCS projection, an a HealPix skymap. Implementing of the WCS projection has priority as most sky maps are in that format. The GVOTable class should only provide the conversion capabilities, but no capabilities to send the object to the hub. The GVOTable class should have a GXml member that will contain the VO table.

The publishing of the VO table is accomplished by a GVOClient::send method. Eventually, this method could also be named GVOClient::publish which may be more appropriate for the action that is taken. This needs to be decided before implementing the method.

GVOtable is now an accessible object in python whitout going through GSkymap.

Standard for GVOTable (http://www.ivoa.net/documents/REC/DM/STC-20071030.html) under implementation.
GVOTable needs access to skymap elements like number of pixels in each axis, which can be found in GSkymap. If those informations are not available in GWs, it will be necessary to add an access method to GSkymap to get them.

test that can be used to see the current VOTable:
skymap = gammalib.GSkymap("./gammalib/test/data/cena_lobes_parkes.fits”)
votable = gammalib.GVOTable(skymap)
makes VOTableExemple.xml on the current directory

List of corrected bugs during 6th coding sprint:

B1 → GVOClient bug
Description: GVOClient always launched GVOHub, even when another Hub was running.
Cause: The ping method malfunctioned, the structure of SAMP message was incorrect.
Fix: correction of ping SAMP message structure (empty params required, was not empty)

B2 → GVOClient bug
Description: When using another HUB than GVOHub, images wont be displayed in external applications.
Cause: bad structure of message image.load.fits
This bad structure is OK for the GVOHub but not functionning with other hubs.
Fix: removed a parasite string in the message structure for table.load.votable
Replaced the hub secret key in the structure values with the client private key value

B3 → GVOClient bug
Description, fix: same as B2 but concerning table.load.fits

B4 → GVOHub malfunction
Description: After B2 and B3 solved, GVOHub didn’t recognized the concerned messages types anymore.
Fix: Modification of the xml parsing to get the relevant mtypes from the corrected SAMP structure.

Oveview:
The GVOHub messages to the clients were OK.
The messages sent by the clients to the GVOHub were not always well understood by GVOHub (image.load.fits, table.load.votable not OK).
The GVOClient always started a GVOHub even if a hub was already running.
GVOClient didn’t sent the correct SAMP messages structures for non-GVOHub (→ GVOHub was not fully standard)

List of new functionalities:
GVOTable can now load an xml file and be shared through SAMP
GVOClient can share VoTables and Fits with VO applications using either GVOHub or any SAMP hub runnning (result of bug fixing)

Testing:
import gammalib
client = gammalib.GVOClient()
client.connect()
fits = gammalib.GFits("<Any available FITS File>”)
hdu = fits.at(<HDU considered>)
client.publish(hdu)
votable = gammalib.GVOTable("<Any available VOTable File>”)
client.publish(votable)

To be done:
We are not sure of GVOTable usefulness.
SAMP doesn’t allows to share a stream, but needs a copy of a file no matter the format used (VOTable, FITS...).
If any data can be expressed in FITS and correctly interpreted bu VO applications, then GVOTable is of no use.
If cases happen where data can’t be put into FITS format, or not understood into FITS format by other apps, then GVOTable may be usefull.
For now, GVOTable is usable but limited: it reads an xml file containing a VOTable data and that’s it.
Functions already exist in GVOTable to construct a GVOTable xml format from data inside gammalib, but putting it all together should be considered only if GVOTa
ble may be of any use.

I integrated the code into devel.

I reworked a bit the GVOTable class so that one can now generate a VO table from a FITS table. I checked that the code works by loading an event list, translating the event list into a VO table, and sending the VO table via the hub to Topcat (either via the Topcat Hub or the GammaLib Hub).

I also checked that publishing an image to Aladin still works. Publishing a FITS table to Aladin works also, Aladin seems to convert automatically that table into an image. Even publishing a VO table to Aladin works, also here Aladin converts the VO table into an image.

I think there is a definite need for the GVOTable class, namely for the transmission of tables to Topcat. Trying to send a FITS table to Topcat does not work, but this seems normal since the GVOClient::publish() method sends the FITS table using the image.load.fits command. If one tries this, Topcat seems simply to ignore the notification. Hence to display VO tables in Topcat the GVOTable class is necessary.