Description
The DIASource record given in the DPDD (in Table 1) does not contain the filterName that the source is detected in; it is stored in the CcdVisit table because of database normalization. Accordingly, the DPDD does not explicitly specify that the alert packet will identify which filter a DIASource was detected in (Section 4.5.1).
Since we must know the filter in order to interpret the flux measurements in an alert packet, I propose we clarify that filterName will be included with each DIASource in the alerts.
Based on previous discussion in DM-8050, I believe the filterName is already included as a foreign key in the DIASource cat schema, so this change only requires a documentation change.
Attachments
Issue Links
- is triggering
-
DM-11247 Add additional alert packet contents to DPDD
- Done
Activity
It's not obvious to me that there are others that need to be included from CcdVisit.
From Visit, one might imagine including programID to enable downstream filtering (e.g., broker selection of Deep Drilling observations), but I tend to think that can be accomplished as easily with spatial cuts. In general users will want all the data available (regardless of what program triggered it), in any case.
Eric Bellm please add the triggered implementation ticket to this RFC.
Accepted; implementation ticket is DM-11247.
Eric Bellm it looks like this RFC can be marked as implemented.
Rather than phrasing this as adding filterName to DIASource, could we make a list of fields from the CcdVisit table that will also be included in alerts?