EUCLID: new x-match method

[cosmoJFH]

Dear astroquery team,

The built-in cross-match functionality (like the one available in the Astroquery.gaia package) is demanded by the community. Currently, the Astroquery.Gaia built-in cross-match tool was updated in #3320, therefore, we would like to implement a similar x-match method in the Euclid module.

cc @esdc-esac-esa-int
jira: EUCLIDMNGT-1449

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 70.15%. Comparing base (b81cecb) to head (d4787d0).
⚠️ Report is 142 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #3386      +/-   ##
==========================================
+ Coverage   70.07%   70.15%   +0.07%     
==========================================
  Files         232      232              
  Lines       19893    19946      +53     
==========================================
+ Hits        13940    13993      +53     
  Misses       5953     5953              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[keflavich]

Just to be sure - this is for users to upload catalogs for server-side x-matching, right? I'm happy with this, then.

[cosmoJFH]

Just to be sure - this is for users to upload catalogs for server-side x-matching, right? I'm happy with this, then.

Hi @keflavich, this function runs a (positional) x-match for:

1. 2 user's tables, previously uploaded to the user's private area;
2. a user's table previously uploaded to the user's private area and an Euclid catalogue;
3. 2 Euclid catalogues.

[bsipocz]

This all looks good, I only have minor comments looking at the code.

However, as there are no remote tests I couldn't really test this in reality and relied on the assumption that this is the same in gaia thus it is expected to work just as good.

[bsipocz]

We have default table names for gaia, would any of that make sense here, too?
If not, then I would still use the None as default rather than null strings.

[cosmoJFH]

Yes, there exist default tables too. They are defined in the constructor

        self.main_table = conf.ENVIRONMENTS[self.environment]['main_table']
        self.main_table_ra = conf.ENVIRONMENTS[self.environment]['main_table_ra_column']
        self.main_table_dec = conf.ENVIRONMENTS[self.environment]['main_table_dec_column']

But these values cannot be used as the default values for the parameters.

We have changed the default values to None

table_b_full_qualified_name=None, table_b_column_ra=None, table_b_column_dec=None

[bsipocz]

Suggested change

	results[‘separation’].unit = u.degree. To speed up the cross-match, pass the biggest table to the
	``results[‘separation’].unit = u.degree``. To speed up the cross-match, pass the biggest table to the

[cosmoJFH]

Changes committed to the branch.

[bsipocz]

Should this be just named cross_match, or are there plans to have a more generic one like we have for gaia?

[cosmoJFH]

Yes, the idea is to follow the same names as in gaia. We are not 100 % that the "other" x-match will be implemented.

[bsipocz]

Please use a more specific, expected exception type here as not all the problems with be due to not having the table in the archive.
(I see this problem exists in the gaia module, too)

[cosmoJFH]

The aim is to catch any exception and not to continue with the process.

[bsipocz]

Yeap, but then just let them raise as they come as the new exception may not be correct.

[cosmoJFH]

The exception is propagated. Changes committed to the branch.

[bsipocz]

Thanks!