Gaia: get votable column names as lowercase names

[cosmoJFH]

In issue https://github.com/astropy/astroquery/issues/2911 it was shown that the Gaia class launch_job returns the upper case column name DESIGNATION.

This came from that fact that IDs are used instead of the names in the votable.

Recently, the votables returned by gaia has been updated in order to include the datalink "Service Descriptors", so these votables contain a few new ID, where their corresponding values are capitalized. Therefore, this implies that the column names will be changed when the votable are read from astropy: they would be shown as uppercase names. We need to keep generating astropy tables that returns column names as lowercase names, based on the names and not on the IDs. This is an example:

>>> job = gaia.launch_job("select top 1 solution_id,source_id,designation from gaiadr3.gaia_source order by source_id")
>>> print(job.get_results())
    solution_id          SOURCE_ID              DESIGNATION         
------------------- ------------------- ----------------------------
1636148068921376768 4111834567779557376 Gaia DR3 4111834567779557376

Could you give us some support to carry out this change in gaia? Could we make use the parameter use_names_over_ids=True at the time the votable is read? Where could we make this change?

cc @esdc-esac-esa-int

[bsipocz]

Could you give us some support to carry out this change in gaia? Could we make use the parameter use_names_over_ids=True at the time the votable is read? Where could we make this change?

I would think you can use use_names_over_ids at the point you convert the votable to an astropy table. At least that is the point we do it in pyvo, but I'm not exactly familiar with the TapPlus implementation to be able to pinpoint the best location.

In fact, I would love to reignite the discussion of how we could join efforts of switching to pyvo in the esa modules, too. Historically there have been missing features in pyvo, but it has come a long way both in features and the scaffolding for supporting prototype (not-yet-in-vo-standard) features.

[cosmoJFH]

Hi @bsipocz, thanks for your quick reply. So. from you point of view, somewhere in the TapPlus class the build of the astropy table is carried out.

Is the project pyvo an independent project from astropy? We never checked that the changes in gaia could affect this project.

[bsipocz]

yes, pyvo is separate from core astropy and maintained by several IVOA people atm. A couple of years ago we talked about a roadmap of moving features from tapplus to pyvo so that the ESA modules can use that and we can retire tapplus from astroquery but the implementation has stalled. If you think it's still feasible, I would like to suggest this as a small-group discussion topic at the next IVOA interop

[cosmoJFH]

yes, pyvo is separate from core astropy and maintained by several IVOA people atm. A couple of years ago we talked about a roadmap of moving features from tapplus to pyvo so that the ESA modules can use that and we can retire tapplus from astroquery but the implementation has stalled. If you think it's still feasible, I would like to suggest this as a small-group discussion topic at the next IVOA interop

It sounds appealing!! In fact we could implement some bdd tests (with behave) as we have done for astroquery, just to have this project under the radar.

[cosmoJFH]

We have committed the PR https://github.com/astropy/astroquery/pull/2967 to handle this problem.