Gaia class launch_job returns capitalizes DESIGNATION column name

[adrn]

Hello!

I noticed something strange today with the astroquery.gaia.Gaia class: the table resulting from a launch_job() query has all lower-cased column names except for DESIGNATION, which is in all caps. If you query the Gaia archive via their web interface, all column names are returned in lower case. Also, if you use the astroquery TapPlus class directly to query the Gaia archive, designation appears in lower case. I don't see anything obvious that would capitalize that one column in the source code. Is this intended behavior? Do you have any other ideas for what could be going on?

Here is a demonstration with the latest dev version of astroquery:
https://gist.github.com/adrn/2dc9d901aa082e971aa650d357e5b59d

[cosmoJFH]

Hi @adrn, here you have my 2 cents: if you download the results as a votable (job = Gaia.launch_job(query,dump_to_file=True)) you can find the following

Could it be that the column name is read from the 'ID' instead of from the 'name'?

I am not an expert in astropy, but I found the following method in votable/connect/read_table_votable

[bsipocz]

I would say this is upstream, the capitalization is coming directly from the server and astropy defaults to using ID. Ideally, the server should use the same capitalization independently of the format requested from it.
Why the difference within gaia and direct use of TapPlus is a bit of an enigma and would require more digging, I suppose the default output formats may differ, etc.

(In astropy, when both present ID is given preference over name (see the notes section in here: https://docs.astropy.org/en/stable/io/votable/index.html#examples) )

[adrn]

That makes sense -- thanks @bsipocz and @cosmoJFH for digging into this!

[bsipocz]

OK, so a bit more digging:

If you use PyVO for the direct TAP query, you get the lower case column name, but in the repr, and only because we have specifically set use_names_over_ids=True when converting the VOTable to an astropy Table (that we also use for printing the repr). The fieldnames property is also populated by looping through the field names rather than the ID.

Anyway, I also found the difference between calling the module and TapPlus. You have used a different server_context. You used 'data-server' while the module uses 'tap-server', changing your example to use tap-service would result in the same all caps column name.

So with this, the horse is beaten dead, and I will close this issue as upstream.

If @cosmoJFH or others at ESA think that we should work around this, it's their decision and I'll merge their PR that would either opt in use_names_over_ids or switching the context, or something else.