Gaia class launch_job returns capitalizes DESIGNATION column name about astroquery

[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) )

[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.

[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

[adrn]

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