Streamline & generalise VOTable output

[MatthewWhiting]

For Selavy development we want to have the fitted components written to a VOTable format as well. To help this, the Duchamp code for outputting to VOTable should be improved and made a bit more general. In fact, it would be a good opportunity to make the whole aspect of writing out the catalogues generalised, with a base class and derived classes for each of the output types (ASCII results, ASCII log, VOTable/XML, ...)

[MatthewWhiting]

An initial improvement is to move the UCD/datatype/reference information from the VOField class to the Col class. This way the VOField can be directly instantiated from the Col and not require additional information at initialisation.

[MatthewWhiting]

Thoughts about the class structure:

• Have a base class TableWriter?, that provides basic functionality
• Derived classes would include ASCIITableWriter, LogTableWriter?, VOTableWriter
• Since we will want to use VOTableWriter to write out other types of catalogues (the fitted components in Selavy), this needs to be general enough that it doesn't assume the columns have any particular content.
• Methods would include:
  • Writing the header information (by which I mean the introductory descriptive stuff - flexible enough to take different inputs
  • Writing the parameters - the ASCII/Log versions would write the formatted version, the VOTable would write them as VOParams
  • Write the the column headers - VOTable would write the <FIELD> ... </FIELD information, while the ASCII/Log versions would write the column titles & units and the lines underneath.
  • Writing an individual entry (taken from an object).
  • Write any footer information (only necessary at this point for VOTable)

[MatthewWhiting]

Have introduced CatalogueWriter?, ASCIICatalogueWriter and VOCatalogueWriter, and implemented the latter instead of the old way of doing it. So far, working fine, as it reproduces the VOTable exactly.

Still to do the ASCIICatalogueWriter, which will handle both the results file (with optionally separate header) and the log file.

[MatthewWhiting]

One change that may have to be made is to remove the printing of the full cube stats in the case of smoothing -- currently we write out the stats as calculated on the smoothed cube, but also the stats in the original cube.

This can't be done in the new formalism, as the writer does not have access to the pixel data to recalculate the stats. But I'm actually happy with that, as we didn't do the same thing for the reconstruction case, and it is a bit odd that we report stats that have *no* bearing on the final catalogue at all. It is probably better to stick to only reporting the relevant stuff -- if a user is interested in this they can re-run Duchamp without the smoothing.

[MatthewWhiting]

This, combined with the new CatalogueSpecification? code, is essentially complete.

Closing ticket.