I think the distance is always meant to be radians on the sky. Thus if distance is set from centroids, it must take the plate scale into account. I think it should be an Angle and that it should be better documented.
The current design feels messy and dangerous to me. It is far too easy for the distance field to be unset or set incorrectly. This is especially a problem while fitting a WCS: the distance might be valid for an older version of the WCS. This whole issue of consistency is deeper than Match, though. It originates in sources and reference objects. I think something like the following would be a huge improvement:
- Source and reference object catalogs should have an pointer to a WCS.
- Each catalog entry has access to this WCS.
- Source coord is computed from slot centroid and catalog WCS.
- Reference centroid is computed from the reference coord and catalog WCS.
- Once this is done, then match distance can similarly be reliably computed at need.
Subtleties:
- One might cache the computed values, but I think this would be too difficult to be worth the effort.
- Handling a null WCS pointer requires some care. I think for catalogs that the computed field values should be NaNs, since that matches other field access. Perhaps an associated flag would help. Catalogs can have a method "hasWcs", but sometimes users only have individual entries (e.g. in the case of matches), not the full catalog.
Meanwhile, is there a reasonable short-term solution for DM-2511 that will not leave us with legacy code we regret later? If a design such as I just mentioned sounds reasonable then we won't need the function in question in this ticket and I could move it to meas_astrom where it will be relatively out of the way. I could even hide it in meas.astrom.detail (I am loath to make it private, because I want a unit test).
Changes in meas_algorithms on tickets/
DM-2511:Changes in meas_algorithms on tickets/
DM-2511: