Created by user-7b92a, last modified by Anonymous on Feb 03, 2017
No labels
5 Comments
user-7b92a
This is a list of fields within a granule that must match values within the parent collection. The names used below are using UMM nomenclature. Depending on the format the parent collection may not have some of these defined. Some of these validations won't be applicable if the collection and granules do not specify the field.
Collection identifier fields
short name and version id, entry title (aka dataset id), or entry id
Spatial Representation
If the collection defines a granule spatial representation of type ORBIT then the granule must have orbit parameters. If the spatial representation is CARTESIAN or GEODETIC then the granule must define a spatial shape.
Temporal
Platform short name
Instrument short name
Instrument operation modes
Sensor short name
Platform, Instrument, or Sensor Characteristic names
so I knew from looking at some granual xml that there is mention of platform, but am I to read this correctly that if you change a platform in the collection from say AM-1 to Terra and leave the granules alone then you will no longer be able to find those granular when doing a spatial or a short name search? Does a change of any of these fields result in orphaned granules? Which actions result in deleted granules (out side of collection deletion)?
We discussed this via a Google Hangout but I'm putting the information here for anyone else who reads this. Granules can refer to a subset of the platforms in a collection. If they do not refer to any of the platforms then it's assumed that all of the platforms apply to that granule. If you were to change a platform short name in a collection you would want to update the granule metadata so that it matched. Search results would be inconsistent and granule ingest updates would be rejected until the granule used the new platform short name.
Nothing will cause granules to be deleted with the exception of explicitly deleting the granule or deleting its parent collection.
Changing the Spatial Coverage ranges will cause issues with the linkage of the archived granules too. If some of the archived granules don't fall within the new spatial coverage range.
5 Comments
user-7b92a
This is a list of fields within a granule that must match values within the parent collection. The names used below are using UMM nomenclature. Depending on the format the parent collection may not have some of these defined. Some of these validations won't be applicable if the collection and granules do not specify the field.
Thomas Cherry
so I knew from looking at some granual xml that there is mention of platform, but am I to read this correctly that if you change a platform in the collection from say AM-1 to Terra and leave the granules alone then you will no longer be able to find those granular when doing a spatial or a short name search? Does a change of any of these fields result in orphaned granules? Which actions result in deleted granules (out side of collection deletion)?
user-7b92a
We discussed this via a Google Hangout but I'm putting the information here for anyone else who reads this. Granules can refer to a subset of the platforms in a collection. If they do not refer to any of the platforms then it's assumed that all of the platforms apply to that granule. If you were to change a platform short name in a collection you would want to update the granule metadata so that it matched. Search results would be inconsistent and granule ingest updates would be rejected until the granule used the new platform short name.
Nothing will cause granules to be deleted with the exception of explicitly deleting the granule or deleting its parent collection.
Michael Morahan
Changing the Spatial Coverage ranges will cause issues with the linkage of the archived granules too. If some of the archived granules don't fall within the new spatial coverage range.
user-7b92a
I did a demo of some of these rules for GCMD. The wiki file https://wiki.earthdata.nasa.gov/download/attachments/68387948/gcmd_granule_collection_field_relationship_demo.pdf?version=1&modificationDate=1456955342937&api=v2 shows the demo request and responses.