For the minimal goal Trey has articulated, a VO-ish way to express the logic is:

Look at the UCDs for the table columns. Limit the scope of consideration to ones with UCDs beginning with "pos.eq.". If columns with UCDs including "pos.eq.ra" and "pos.eq.dec" are present, determine how many such pairs are present. Associate pairs by comparing their column names. If there is only one, use it for catalog overlays on images. If there are multiple pairs, look for one where the UCDs include "meta.main" (e.g., "pos.eq.ra;meta.main") and use that. If there is no "meta.main" pair (or if multiple pairs include "meta.main") use the leftmost such pair in the table.

Optionally (as a later upgrade which should be a separate ticket), in the layer dialog, if there are multiple "pos.eq.ra/dec" column pairs, allow users to select a non-default pair of columns to be used for the overlay for a catalog.

Emmanuel Joliet this is also just the first piece of DM-15783, all of which must be completed before LSST new-features funding ends. We need to get started on that work ASAP in order to finish all of it in time.

The suggestion I made two comments up applies to all tables that we ingest and should be used as a predecessor to whatever our current logic is for finding the ra/dec columns to use for overlays.

In thinking of this as the first step toward implementing DM-15783, though, we are going to have to define the logic for when we recognize a table as an image metadata table and so enable a mode of the application in which we start actually retrieving and displaying the referenced images.

I'll comment on that on the parent ticket.

DM-16476 is there partially to give us more fine grain control as to how the recognized tables. We need to run all the tables though some master table recognition task that can be configured for different applications.

If ra/dec columns finding for normal catalog overlay is made at client side, some table search processors at Firefly server already having the functions to identify the center columns and set the relevant metadata into the table may need to be reviewed. The review work includes,

• checking if the center column search is necessary.
• checking if center column search method is consistent with the one done at client side.

The following search processors (files) are found with implementation to search the center columns and may need some review,

• QueryVOTABLE.java and VOTableReader.java
• UserCatalogQuery
• IpacTableFromSource