Implement CMR query to get collection-level metadata elements that can be used in UMM-G construction.

[lisakaser]

Pre-met and UMM-G files may require information already available from collection metadata. Determine whether there are any granule metadata building blocks in a dataset's collection-level metadata, and if so write a new story to implement a simple retrieval mechanism from CMR.

Information available from collection metadata:

• correct padding of version number
• GranuleSpatialRepresentation (may be set to GEODETIC, CARTESIAN, ORBIT)

Acceptance criteria for implementation:

When app is run:

• UMM-C metadata is retrieved
• AUTHID and version number will be displayed as tool output (padding should be correct in UMM-G and tool output)
• Spatial representation in UMM-G metadata files reflects the spatial representation associated with the collection. "GEODETIC" will result in Gpolygons representing the spatial coverage for a granule.

[juliacollins]

I didn't think through the use case of a SIPS provider when I suggested utilizing collection-level metadata. In that case, I believe there will be no collection-level metadata available when granule-metgen executes. I suggest working through the SIPS use case in more detail, along with other use cases (e.g. the Data Production Team generating UMM-G as part of the data production workflow, and data producers who provide us with only data files), to clarify where different bits of information will be needed.

My current feeling is that Ops users configuring the data ingest process may benefit most from information existing in collection-level metadata files. Any regexes we have to produce to scrape metadata from data input files (in the case where the data producer only delivers data files) would also be candidates for re-use in both the UMM-G generation and data ingest steps.

[lisakaser]

Primarily needed for data set version padding