DM-834 is a request to unify
CoaddBoundedField (CBF) contains an
CoaddBoundedFieldElement, and there is much overlap:
apCorrMap, which contains a
weight(an added field)
calib, two fields not needed by
bbox(as part of
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
- I don’t yet know how difficult it is to add a
BoundedFieldto a schema.
- CBF’s constructor would require a key or name for each added field:
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
If we go that route then users of
EposureTable need to add
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
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).