DM-834 is a request to unify CoaddPsf
and CoaddBoundedField
. CoaddPsf
uses ExposureTable
, whereas CoaddBoundedField
(CBF) contains an std::vector
of CoaddBoundedFieldElement
, and there is much overlap:
ExposureTable
's ExposureRecord
contains:
-
apCorrMap
, which contains adict
of name:boundedField
bbox
validPolygon
wcs
-
weight
(an added field)
plus psf
and calib
, two fields not needed by CoaddBoundedField
.
CoaddBoundedFieldElement
contains:
-
boundedField
(one perboundedField
in anapCorrMap
) -
bbox
(as part ofboundedField
) validPolygon
wcs
weight
Note: for a given exposure there is one ExposureRecord
, but potentially many CoaddBoundedFieldElements
, since each apCorrMap
may contain many bounded fields.
For unifying these I lean towards having CBF take an ExposureTable
that has one field added: a BoundedField
. However:
- I don’t yet know how difficult it is to add a
BoundedField
to a schema. - CBF’s constructor would require a key or name for each added field:
weight
andboundedField
Also, CBF would ignore 3 fields in the table, but this does not worry me as they could be empty pointers.
Another option is to add a new kind of table that contains the common subset of ExposureTable
and CoaddBoundedFieldElement
:
bbox
validPolygon
wcs
weight
If we go that route then users of EposureTable
need to add psf
, calib
and apCorrMap
and users of CoaddBoundedFieldElement
would have to add a single boundedField
. Note that users of ExposureTable
rely on convenience functions to access the extra elements, so this would require at least one new table class.
An option that would require no changes, but which I strongly dislike, is to construct a CBF
using an ExposureTable
with just the weight
field added and encode the BoundedField
as a single entry in apCorrMap
. This seems like an abuse of apCorrMap
and would require extracting the contained boundedField
from the apCorrMap
in each record every time the CBF was evaluated at a point.
As an aside, ExposureTable
is little more than an unpacked ExposureInfo
. I wonder if it would be cleaner for the table to store the ExposureInfo
itself. That would eliminate the convenience methods (we just need one to get the ExposureInfo
, then call its methods to get contained data) at the expense of one added level of lookup. This would be even nicer once ExposureInfo
gains a bbox
. However, I this would be a much more disruptive change (though ExposureTable
is not used in very many places).