FIREFLY-1787: Default filters for Spatial Search Position Columns

[kpuriIpac]

Ticket: FIREFLY-1787

• Note: This PR addresses the first part of the ticket, and not the second part. I wasn't sure about the second part, but we can discuss it over zoom, and I can then include it in this or another small PR.
  • First part pre-filters the position columns for Spatial Search by UCD as specified in the ticket.
• Question: Do we need to pre-filter columns elsewhere? This PR only does it for Spatial Search on TAP.

Testing: https://fireflydev.ipac.caltech.edu/firefly-1787-tap-col-improvement/firefly

• Open the column picker for TAP's Spatial Search position columns. They should have some pre-filtered UCDs according to the ticket.

[robyww]

you need to support pos.eq. This is when the ra and dec are in the same column.
test on TAP with CANFAR -> pgm -> gaiadr2

[kpuriIpac]

I see what you mean. If I just add pos.eq though, we'll end up seeing all ra/dec possibilities for both lon and lat col.

I did notice that for the table you mentioned, the single value for both ra/dec (named pos) has the following UCD:
pos.eq;meta.main

And normally for other ra/dec values, meta.main doesn't show up. Can I assume meta.main always shows up for these same column ra/dec values?

In that case my filter could become something like :

pos.eq;meta.main, pos.eq.ra, pos.galactic.lon, pos.ecliptic.lon

Let me know what you think.

[robyww]

It might take a little more code but pos.eq does not have to match pos.eq.ra. If you can’t make that work then pos.eq;meta.main is fine.

[robyww]

I thought about this a little more. Yes, just go with pos.eq;meta.main

[kpuriIpac]

Got it, yes with a little more code I can get your first suggestion going, but if pos.eq;meta.main works just as well then yes that's much more straightforward.

[kpuriIpac]

@robyww so I was stuck on this for a bit running into some bugs, but I think we only support one OR in our filters currently. But it's not obvious that we don't support more, which is why it took me some time to track it down too.

So if I have a filter like:

pos.eq.ra OR pos.galactic.lon OR pos.eq;meta.main (any number over 2)

then only the first filter gets applied. But if we have only 2 (or 1) filters, then they both get applied.

I'm happy to work on a fix for this later (unless this is intended behavior for some reason) but I wasn't able to get to it in time for tomorrow. But according to the ticket, @gpdf mentioned to use equatorial values if we can't do ORs. But since we can do one OR at least, I did:

pos.eq.ra OR pos.eq;meta.main and pos.eq.dec OR pos.eq;meta.main

So this will at least support the 2 most common use cases for this filter (you can try this on the table with single column for both ra/dec you mentioned above)

[robyww]

looks good.