LoadReferenceObjectsConfig has a defaultFilter field, whose description is:

Default reference catalog filter to use if filter not specified in exposure; if blank then filter must be specified in exposure"

This is in addition to the filterMap field, which is used when loading a reference catalog to pick a refcat filter given a camera filter (e.g. HSC's "N387" narrowband filter uses PS1 "g" band).

I had filed DM-26007 to tweak this field slightly, because defaultFilter only comes into play if the user does not supply filterName to loadSkyCircle. In jointcal, I want to always supply a filterName when loading the refcat, because I don't know, when loading said refcat, whether there is a filterMap (e.g. PS1), or whether there is only one filter that ever matters (e.g. Gaia DR2). The way defaultFilter was implemented, I would have had to build a trivial filterMap for Gaia for every instrument, which seemed excessive. As Russell Owen and I discussed it during review, we realized that this modification of defaultFilter would be confusing, and could cause usage errors.

Searching the stack, I found no uses of defaultFilter outside of unittests, nor did I find any calls to loadSkyCircle or loadPixelBox that did not specify the filterName parameter. It seems that we have no use cases for defaultFilter, and I cannot think of any cases where a user would not know the filterName for the camera they are loading.

This proposal is to remove (or first deprecate, then remove) defaultFilter from LoadReferenceObjectsConfig. The use case of "I always want to use this refcat filter, no matter what" will be handled via the anyFilterMapsToThis proposal (name still in flux) currently under discussion on slack, which would be implemented on DM-26007. I also propose to make filterName a non-optional parameter in loadSkyCircle and loadPixelBox: so far, all of our configurations and uses have required it, even if we weren't aware of that.