If a user performs a non-fine filter on a margin catalog, the resulting margin has very unexpected properties where points a healpix pixel width away from the search area is included, which results in strange crossmatches.
This is because to filter a margin to include all margin points within an area, we need to include the neighboring healpix pixels. With fine filtering, any points outside of the search region in neighboring pixels are removed, but without fine filtering, these are still included, which can be quite far away from the original search region.
The options for fixing this I can think of are:
- Make non-fine filtering ignore any margins pixels outside of the search region. This would solve this case, but would also lead to us missing potential matches.
- Make non-fine filtering drop the margin. This would cause us to lose even more potential matches, but would warn the user that they might be missing matches. Though the behavior of dropping a margin unexpectedly could be confusing.
- Make non-fine margin filtering do a fine pixel filter of the catalogs search region. This would make sure we catch all matches and the margin filter would contain only the points that exist in the main catalog, which seems sensible.
The third option is probably my favorite.
If a user performs a non-fine filter on a margin catalog, the resulting margin has very unexpected properties where points a healpix pixel width away from the search area is included, which results in strange crossmatches.
This is because to filter a margin to include all margin points within an area, we need to include the neighboring healpix pixels. With fine filtering, any points outside of the search region in neighboring pixels are removed, but without fine filtering, these are still included, which can be quite far away from the original search region.
The options for fixing this I can think of are:
The third option is probably my favorite.