Review Mosaic Associations

[PaulHuwe]

Prune the Mosaic_Associations schema and possibly merge with the Association schema, if appropriate.

[stscijgbot-rstdms]

This issue is tracked on JIRA as RAD-150.

[stscijgbot-rstdms]

Comment by Nadia Dencheva on JIRA:

The mosaic_association schema does not have description and I'm not clear what it represents and. how this ticket aims to improve it. Could you put some more details here?

[PaulHuwe]

It is my understanding that the current mosaic_association schema contains the minimum set of association keywords required to associate it to its related files. @stscieisenhamer Please correct me if I am wrong.
In that case, this ticket is to possibly pare the overlapping keywords in mosaic_association and association into one set of tags that both point to (with extra tags left in the original *association schema).

[stscieisenhamer]

I am not sure of all aspects on this, but there are two different things going on I believe. One is where an association, the contents itself, needs to be represented. This I believe is the association schema. The other is the documentation of just sources of the association, which is currently represented by mosaic_association. For JWST, the association was not stored in the headers, hence pointers to the association file/pool were needed.

For roman, if instead of the file references, one wants to actually put the association in the meta data, I do not see any reason why not to replace mosaic_association with association: The association should already have the "from what pool" the association had been generated from. IMHO this is a better approach. The current approach is just the "this is how it was done for JWST".

[schlafly]

My recollection is that we started with associations being in the L3 metadata but removed it because there were problems serializing it. You two know better than I do. I think we have what we need in the mosaic schema right now and I don't think either the mosaic association or main association schema buys us very much, so I would probably leave things as they are for now. Since we're already including the list of contributing exposures in the individual image metadata I think that's the chief thing. Let me know if you see things differently here.

[stscieisenhamer]

A "pro" for having the association itself in the meta is ease of reproducibility: If in the meta, it would be trivial to extract/save the association, as it had been defined, to use as input again. On the other hand, a "reproduce association from L3 meta" tool is still straightforward, since the list of inputs is represented in the meta.

Another "pro" just thought of though is consistency amongst our products: If L2 has an association meta, users would expect the same in L3?

[stscieisenhamer]

About the serialization, I do not have knowledge about that except that if it isn't an issue with L2 data, not sure why it would be an issue with L3? Or maybe it is an issue in L2?

[schlafly]

It doesn't look to me like the L2s have association metadata, and it makes less sense for them. But let's wait for Paul to get back re serialization.

[stscijgbot-rstdms]

Comment by Paul Huwe on JIRA:

Circling back to this: there should be no serialization issues with the association group at present. Is there a consensus on including the full association set in mosaic vs. just keeping what is there now?

[PaulHuwe]

@tddesjardins Do you have an opinion here, vis-a-vis the L3 File Schema Document?