You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
issue-15 implemented the step to communicate with CMR and retrieve collection metadata if it exists. The entire TemporalExtents element is currently saved in a Collection class object. An example of the TemporalExtents element for SNEX23_SSADUCk is shown below. Representations for collections with a single date and time, or periodic dates/times, are slightly different.
Based on a quick comparison of the UMM-G schema and the UMM-C schema, the main difference between the two is that collections can have an array of TemporalExtent elements, whereas a granule can only have a single range of date/time values (begin and end) or a single date/time value. If a collection only has one TemporalExtent element then it's straightforward to apply that one RangeDateTime or SingleDateTime to each granule. If the collection has multiple temporal extent entries (i.e. an array of RangeDateTime objects), then we may not want to mess with using the collection metadata at all to populate UMM-G temporal information. My guess is that we'd need to merge the multiple collection TemporalExtent elements into a range that covers all of the collection objects and apply that big range to the granule, which seems like it might be a fairly inaccurate representation.
Outcome of this story: MetGenC can extract a single collection temporal information RangeDateTime or SingleDateTime object (if there is only one) and use it to populate the temporal information in UMM-G output.
Story points: 2, assuming we would only apply this feature to collections with a single temporal extent.
issue-15 implemented the step to communicate with CMR and retrieve collection metadata if it exists. The entire
TemporalExtents
element is currently saved in aCollection
class object. An example of theTemporalExtents
element for SNEX23_SSADUCk is shown below. Representations for collections with a single date and time, or periodic dates/times, are slightly different.Based on a quick comparison of the UMM-G schema and the UMM-C schema, the main difference between the two is that collections can have an array of
TemporalExtent
elements, whereas a granule can only have a single range of date/time values (begin and end) or a single date/time value. If a collection only has oneTemporalExtent
element then it's straightforward to apply that oneRangeDateTime
orSingleDateTime
to each granule. If the collection has multiple temporal extent entries (i.e. an array ofRangeDateTime
objects), then we may not want to mess with using the collection metadata at all to populate UMM-G temporal information. My guess is that we'd need to merge the multiple collection TemporalExtent elements into a range that covers all of the collection objects and apply that big range to the granule, which seems like it might be a fairly inaccurate representation.Outcome of this story: MetGenC can extract a single collection temporal information
RangeDateTime
orSingleDateTime
object (if there is only one) and use it to populate the temporal information in UMM-G output.Story points: 2, assuming we would only apply this feature to collections with a single temporal extent.
References:
The text was updated successfully, but these errors were encountered: