VOTable unit parsing #10791

Problem

Problems might occur when reading in VOTables as QTables. Depending on the formatting of composite units in the data, the unit of some of the Quantities in the QTable might be an instance of UnrecognizedUnit, which means that several useful Quantity methods, e.g. unit conversion, result in an error. This happens with VOTables provided by the Gaia archive, which lists the proper motion units as mas.yr**-1 and radial velocity units as km.s**-1, both of which end up as UnrecognizedUnit instances in a QTable. This motivated the pull request #10786, and even though the changes proposed there allow Gaia VOTables to be read in the expected manner they should be considered to be a workaround rather than a proper solution. The actual problem seems to be caused by unit parsing done while reading a VOTable from a file.

Solution(?)

A likely culprit is the function _get_default_unit_format() that always returns 'cds', meaning that the unit format is expected to be as specified at http://vizier.u-strasbg.fr/doc/catstd-3.2.htx. Indeed, the proper motion and radial velocity units in the Gaia archive do not conform to this standard explaining why unit parsing fails. Astropy documentation states that this unit format was used in VOTable versions up to 1.2. Indeed, the current VOTable version (1.4) has a different unit format specification. The composite units in the Gaia archive do conform to this newer specification and the following code does resolve the problem with reading in Gaia VOTables.

def _get_default_unit_format(config):
    if config['version_1_3_or_later']:
        return 'vounit'
    else:
        return 'cds'

However, the VOTable version 1.3 seems to have the same unit format specification as version 1.2 and different from the specification in version 1.4. This would suggest that _get_default_unit_format() should check the 'version_1_4_or_later' flag instead, but that conflicts the aforementioned Astropy documentation and also prevents Gaia VOTables from being parsed properly, as they claim their version to be 1.3.

Open questions

Where does the statement in Astropy documentation come from? Could it be that the VOTables from the Gaia archive are actually version 1.4 VOTables despite what they claim to be?

System Details

Linux-5.4.0-48-generic-x86_64-with-glibc2.29
Python 3.8.2 (default, Jul 16 2020, 14:00:26)
[GCC 9.3.0]
Numpy 1.19.2
astropy 4.2.dev744+gf57719321
Scipy 1.5.2
Matplotlib 3.3.2