Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Table of Contents
stylecircle

Element Description

The Spatial Extent element describes the geographic coverage of data provided in a file or in a data collection.  

Best Practices

In the CMR, there is the option to describe horizontal, vertical, and orbital spatial coverage. The type of spatial coverage being described in the metadata is identified via the 'Spatial Coverage Type' metadata element. There are five different controlled vocabulary options for 'Spatial Coverage Type' in UMM-Common. These include:

  • Horizontal
  • Vertical
  • Orbital
  • Horizontal and Vertical
  • Orbital and Vertical  

Each type of spatial extent requires different information. The information needed for each is summarized below: 

Horizontal 

Horizontal spatial extent refers to data covering the surface of the Earth. For horizontal spatial extent, a coordinate system must be specified with the choice of either a Cartesian or Geodetic coordinate system:

SpatialExtent/HorizontalSpatialDomain/Geometry/CoordinateSystem:

Choice of:

  • CARTESIAN   
  • GEODETIC

Please see the Coordinate Systems section of the CMR Data Partner User Guide for instructions on how to assign the appropriate coordinate system.

Furthermore, there are four different options for expressing horizontal spatial coverage. Only one of these options may be selected, however, the selected option may be repeated as many times as necessary (e.g. you can't provide a bounding rectangle and a point, but you can provide multiple bounding rectangles). The four options are:

(1) Point

    • A point location defined by a latitude and longitude coordinate. Multiple points may be provided if necessary.

(2) Bounding Rectangle

    • A rectangle defined by a north latitude coordinate, south latitude coordinate, east longitude coordinate, and west longitude coordinate. The north bounding latitude may not exceed 90 degrees, the south bounding coordinate may not be less that -90 degrees, the west bounding coordinate may not be smaller than -180 degrees, and the east bounding coordinate may not exceed 180 degrees. 

(3) GPolygon

    • A polygon defined by latitude/ longitude point pairs. The more points are provided, the more detailed the polygon will be. Exclusion zones within the polygon can also be identified. Please see the CMR Data Partner User Guide for more details. 

(4) Line

    • A width-less line defined by latitude/ longitude point pairs. Multiple points may be provided to express a complex line. Please see the CMR Data Partner User Guide for more details.    

Vertical

Vertical spatial domain can be used to describe coverage of data with a vertical component. The type of vertical coverage being described in the metadata is identified via the 'Vertical Spatial Domain/ Type' metadata element. There are five different controlled vocabulary options for 'Vertical Spatial Domain/ Type' in UMM-Common. These include:

SpatialExtent/VerticalSpatialDomain/Type:

Choice of:

  • Atmosphere Layer
  • Maximum Altitude
  • Minimum Altitude
  • Maximum Depth
  • Minimum Depth

Once a Type is selected, an accompanying value in the SpatialExtent/VerticalSpatialDomain/Value field must also be provided. For example, if "Maximum Altitude" was selected as the Type, the corresponding Value could be "50 KM".

Orbital 

When data is collected via satellite, the Orbit Parameters metadata elements may be used to describe spatial coverage. Please see the CMR Data Partner User Guide for additional details on how Orbit Parameters are used by the backtrack search algorithm for conducting spatial searches. Orbit Parameters includes the following sub-elements:

Swath Width: The width of the strip of the Earth's surface from which geospatial data are collected by a satellite, in kilometers. Just provide the number, the unit of kilometers is implied. If providing orbit parameters, Swath Width is required.  

Period: The time it takes a satellite to complete one complete orbit around the Earth, in decimal minutes. Just provide the number, the unit of decimal minutes is implied. If providing orbit parameters, Period is required.  

Inclination Angle: The angle between the equatorial plane of the Earth and the orbital plane of a satellite, in degrees. Just provide the number, the unit of degrees is implied. If providing orbit parameters, Inclination Angle is required.

Number of Orbits: "Indicates the number of orbits." 

Start Circular Latitude: "The latitude start of the orbit relative to the equator. This is used by the backtrack search algorithm to treat the orbit as if it starts from the specified latitude. This is optional and will default to 0 if not specified."   

Furthermore, the Granule Spatial Representation element is a required element. This element identifies how spatial extent is expressed in the granule metadata associated with a collection. The spatial representation used in the collection metadata can be different than what is used in the granule metadata. Granule Spatial Representation is a controlled vocabulary field in the UMM-Common schema with the following options: 

  • CARTESIAN
  • GEODETIC
  • ORBIT
  • NO_SPATIAL

The granule spatial representation selected at the collection level must be utilized by the granules. Please see the Collection & Granule Spatial Relationships section of the CMR Data Partner User Guide for additional details.

The spatial extent of the granules should always fall within the spatial extent specified in the collection level metadata (and vice versa). It is the responsibility of the metadata author to ensure that collection-granule spatial relationships are compatible.   

Examples:


Element Specification

ModelElementTypeUsable Valid ValuesConstraintsRequired?Cardinality
UMM-CommonSpatialExtent/SpatialCoverageType Enumeration

HORIZONTAL

VERTICAL

ORBITAL

HORIZONTAL_VERTICAL

ORBITAL_VERTICAL

n/aNo0..1
UMM-CommonSpatialExtent/HorizontaSpatialDomain/ZoneIdentifierStringn/a1 - 80 charactersNo0..1
UMM-CommonSpatialExtent/HorizontaSpatialDomain/Geometry/CoordinateSystemEnumeration

CARTESIAN

GEODETIC

n/aYes1
UMM-CommonSpatialExtent/GranuleSpatialRepresentationEnumeration

CARTESIAN

GEODETIC

ORBIT

NO_SPATIAL

n/aYes1

Choice of one of the following for Horizontal Spatial Domain/ Geometry:

(1) Point

If Point is selected, the cardinality is 1..*

ModelElementTypeConstraintsRequired?CardinalityNotes
UMM-CommonSpatialExtent/HorizontaSpatialDomain/Geometry/Point/LongitudeNumber-180 to 180Yes, if applicable1Number in degrees
UMM-CommonSpatialExtent/HorizontaSpatialDomain/Geometry/Point/LatitudeNumber-90 to 90Yes, if applicable1Number in degrees

(2) Bounding Rectangle

If BoundingRectangle is selected, the cardinality is 1..*

ModelElementTypeConstraintsRequired?CardinalityNotes
UMM-CommonSpatialExtent/HorizontaSpatialDomain/Geometry/BoundingRectangles/WestBoundingCoordinateNumber-180 to 180Yes, if applicable1Number in degrees
UMM-CommonSpatialExtent/HorizontaSpatialDomain/Geometry/BoundingRectangles/NorthBoundingCoordinateNumber-90 to 90Yes, if applicable1Number in degrees
UMM-CommonSpatialExtent/HorizontaSpatialDomain/Geometry/BoundingRectangles/EastBoundingCoordinateNumber-180 to 180Yes, if applicable1Number in degrees
UMM-CommonSpatialExtent/HorizontaSpatialDomain/Geometry/BoundingRectangles/SouthBoundingCoordinateNumber-90 to 90Yes, if applicable1Number in degrees

(3) GPolygon

If GPolygon is selected, the cardinality is 1..*

ModelElementTypeConstraintsRequired?CardinalityNotes
UMM-CommonSpatialExtent/HorizontaSpatialDomain/Geometry/GPolygon/Boundary/Points/LongitudeNumber-180 to 180Yes, if applicable14..*Number in degrees. A minimum of 4 GPolygon bounding points must be provided.
UMM-CommonSpatialExtent/HorizontaSpatialDomain/Geometry/GPolygon/Boundary/Points/LatitudeNumber-90 to 90Yes, if applicable14..*Number in degrees. A minimum of 4 GPolygon bounding points must be provided.
UMM-CommonSpatialExtent/HorizontaSpatialDomain/Geometry/GPolygon/ExclusiveZone/Boundaries/Points/LongitudeNumber-180 to 180Yes, if applicableNo0..*1Number in degrees. A minimum of 4 GPolygon exclusion zone bounding points must be provided, if applicable (providing an exclusion zone is optional).
UMM-CommonSpatialExtent/HorizontaSpatialDomain/Geometry/GPolygon/ExclusiveZone/Boundaries/Points/LatitudeNumber-90 to 90Yes, if applicableNo0..*1Number in degrees. A minimum of 4 GPolygon exclusion zone bounding points must be provided, if applicable (providing an exclusion zone is optional).

(4) Line 

If Line is selected, the cardinality is 1..*

ModelElementTypeConstraintsRequired?CardinalityNotes
UMM-CommonSpatialExtent/HorizontaSpatialDomain/Geometry/Lines/Points/LongitudeNumber-180 to 180Yes, if applicable12..*Number in degrees. A minimum of 2 points must be provided to create a line.
UMM-CommonSpatialExtent/HorizontaSpatialDomain/Geometry/Lines/Points/LatitudeNumber-90 to 90Yes, if applicable12..*Number in degrees. A minimum of 2 points must be provided to create a line.

Vertical Spatial Domain:

Providing a Vertical Spatial Domain is optional (Cardinality 0..*)

ModelElementTypeUsable Valid ValuesConstraintsRequired?CardinalityNotes
UMM-CommonSpatialExtent/VerticalSpatialDomain/TypeEnumeration

Atmosphere Layer

Maximum Altitude

Maximum Depth

Minimum Altitude

Minimum Depth

n/aYes, if applicable1Provide multiple iterations of the vertical spatial domain elements to define an upper and a lower vertical boundary (e.g. a minimum altitude and a maximum altitude).
UMM-CommonSpatialExtent/VerticalSpatialDomain/ValueStringn/a1 - 80 charactersYes, if applicable1Both Type and Value are required. Use the Value field to describe the number and unit of the Type provided in the previous field (e.g. 50 KM, 208 meters)

Orbit Parameters:

Providing Orbit Parameters is optional (Cardinality 0..*)

ModelElementTypeConstraintsRequired?CardinalityNotes
UMM-CommonSpatialExtent/OrbitParameters/SwathWidthNumbern/aYes, if applicable1In kilometers.
UMM-CommonSpatialExtent/OrbitParameters/PeriodNumbern/aYes, if applicable1In decimal minutes.
UMM-CommonSpatialExtent/OrbitParameters/InclinationAngleNumber-90 to 90Yes, if applicable1In degrees.
UMM-CommonSpatialExtent/OrbitParameters/NumberOfOrbitsNumbern/aYes, if applicable1
UMM-CommonSpatialExtent/OrbitParameters/StartCircularLatitudeNumber-90 to 90No0..1In degrees.


Metadata Validation and QA/QC

All metadata entering the CMR goes through the below process to ensure metadata quality requirements are met. All records undergo CMR validation before entering the system. The process of QA/QC is slightly different for NASA and non-NASA data providers. Non-NASA providers include interagency and international data providers and are referred to as the International Directory Network (IDN).

Lucidchart
rich-viewertrue
autofittrue
nameCopy of Wiki Page Metadata Evaluation Workflow-1939-672ea43a
width1102
id98e5dc28-3252-4209-953f-66f1378e1cf4
alignLeft
height299

Please see the expandable sections below for flowchart details.


Expand
titleGCMD Metadata QA/QC
  • Manual Review
    • Identify errors, discrepancies or omissions
  • Automated Review
    • Check that the field has been populated
    • Check that the field value is valid
Expand
titleCMR Validation


Expand
titleARC Metadata QA/QC

ARC Priority Matrix

Priority CategorizationJustification

This element is categorized as highest priority when:

  • The element is not included at all
  • The element is included but is empty
  • The valid value in the element appears to be out of sync with data collection. Examples include:
    • Data has stopped being collected in the distant past but the element lists the progress as 'ACTIVE.' As a rule of thumb, this applies when the last available granule has an ending date time of 1+ years in the past. 
    • The element lists the collection progress as 'PLANNED' but data is actually now being collected.
    • Data is still being collected but the element lists the progress as 'COMPLETE.'

This element is categorized as medium priority when:

  • The valid value in the element appears to be out of sync with data collection.
  • The ending date time of the latest granule in the collection is in the past, however the element lists the collection progress as 'ACTIVE' - The latest granule in the collection is less than 1 year from the present day, and the collection is part of a field or flight campaign which may still be ongoing (this could result in gaps in the data). The DAAC should confirm whether data collection is still ongoing for the field/ flight campaign or whether the collection is complete.

Not applicable

The element is provided, a correct valid value is used, and the valid value matches the status of the dataset.

ARC Automated Checks



Dialect Mappings

Expand
titleDIF 9

DIF 9

DIF 9 (Note: DIF-9 is being phased out and will no longer be supported after 2018)


Expand
titleDIF 10

DIF 10

SpecificationPathTypeUsable Valid ValuesRequired in DIF 10?CardinalityNotes
DIF 10/DIF/Dataset_ProgressEnumeration

PLANNED

IN WORK

COMPLETE

No0..1

n/a

Enumeration Mapping

DIF 10

Translation

Direction

UMM
PLANNEDPLANNED
IN WORKACTIVE
COMPLETECOMPLETE
Blank or doesn’t existNOT PROVIDED
Don’t translateNOT PROVIDED

Example Mapping

Section
Column
width50%

DIF 10

No Format
<Dataset_Progress>IN WORK</Dataset_Progress>
Column
width50%

UMM

No Format
"CollectionProgress" : "COMPLETE",
Expand
titleECHO 10

ECHO 10

SpecificationPathTypeConstraintsRequired in ECHO10?CardinalityNotes
ECHO 10/Collection/CollectionStateString
No0..1While this field is not enumeration controlled in ECHO10, use of the UMM enumeration values (PLANNED, ACTIVE, COMPLETE) is strongly encouraged in order to prevent translation errors.


Enumeration Mapping

ECHO 10

Translation

Direction

UMM
PLANNEDPLANNED
IN WORKACTIVE
COMPLETECOMPLETE
completedCOMPLETE
NOT APPLICABLENOT APPLICABLE
Blank or doesn’t existNOT PROVIDED
Any other valueNOT PROVIDED
Don’t translateNOT PROVIDED

Example Mapping

Section
Column
width50%

ECHO 10

No Format
<CollectionState>COMPLETED</CollectionState>
Column
width50%

UMM

No Format
"CollectionProgress" : "COMPLETE",



Expand
titleISO 19115-2 MENDS

ISO 19115-2 MENDS

SpecificationPathTypeNotes
ISO 19115-2 MENDS/gmi:MI_Metadata/gmd:identificationInfo/gmd:MD_DataIdentification/gmd:status/gmd:MD_ProgressCode codeList="https://cdn.earthdata.nasa.gov/iso/resources/Codelist/gmxCodelists.xml#MD_ProgressCode" codeListValue=StringProgressCode has code values of completed, historicalArchive, obsolete, onGoing, planned, required, underDevelopment. gmd:status is not required. Any string can be substituted as well. Since ISO supports multiple statuses for a collection/series, the CMR translates only the first one to UMM.

Enumeration/Code List Mapping

ISO MENDS

Translation

Direction

UMM
plannedPLANNED
underDevelopmentPLANNED
onGoingACTIVE
completedCOMPLETE
historicalArchiveCOMPLETE
obsoleteCOMPLETE

NOT APPLICABLE

a string is used instead

of the defined codes.

The codeList=”” and

codeListValue = “”

NOT APPLICABLE
Blank or doesn’t existNOT PROVIDED
Any other valueNOT PROVIDED
Don’t translateNOT PROVIDED

Example Mapping

Section
Column
width50%

ISO 19115-2 MENDS

No Format
<gmd:status>
    <gmd:MD_ProgressCode codeList=
        "https://cdn.earthdata.nasa.gov/iso/resources/Codelist/gmxCodelists.xml#MD_ProgressCode"
        codeListValue="completed">completed</gmd:MD_ProgressCode>
</gmd:status>
Column
width50%

UMM

No Format
"CollectionProgress" : "COMPLETE",



Expand
titleISO 19115-2 SMAP

ISO 19115-2 SMAP

SpecificationPathTypeNotes
ISO 19115-2 SMAP/gmd:DS_Series/gmd:seriesMetadata/gmi:MI_Metadata/gmd:identificationInfo/gmd:MD_DataIdentification/gmd:status/gmd:MD_ProgressCode codeList="https://cdn.earthdata.nasa.gov/iso/resources/Codelist/gmxCodelists.xml#MD_ProgressCode" codeListValue=StringProgressCode has code values of completed, historicalArchive, obsolete, onGoing, planned, required, underDevelopment. gmd:status is not required. Any string can be substituted as well. Since ISO supports multiple statuses for a collection/series, the CMR translates only the first one to UMM.

Enumeration/Code List Mapping

ISO SMAP

Translation

Direction

UMM
plannedPLANNED
underDevelopmentPLANNED
onGoingACTIVE
completedCOMPLETE
historicalArchiveCOMPLETE
obsoleteCOMPLETE

NOT APPLICABLE

a string is used instead

of the defined codes.

The codeList=”” and

codeListValue = “”

NOT APPLICABLE
Blank or doesn’t existNOT PROVIDED
Any other valueNOT PROVIDED
Don’t translateNOT PROVIDED

Example Mapping

Section
Column
width50%

ISO 19115-2 SMAP

No Format
<gmd:status>
    <gmd:MD_ProgressCode codeList=
         "https://cdn.earthdata.nasa.gov/iso/resources/Codelist/gmxCodelists.xml#MD_ProgressCode"
         codeListValue="completed">completed</gmd:MD_ProgressCode>
</gmd:status>
Column
width50%

UMM

No Format
"CollectionProgress" : "COMPLETE",



UMM Migration


UMM Version 1.9.0

Translation

Direction

UMM Version 1.10.0
PLANNEDPLANNED
IN WORKACTIVE
COMPLETECOMPLETE
NOT APPLICABLENOT APPLICABLE
NOT PROVIDEDNOT PROVIDED
Any other valueNOT PROVIDED

Future Mappings

Expand
titleISO 19115-1

ISO 19115-1

SpecificationPathTypeNotes
ISO 19115-1

/mdb:MI_Metadata/mdb:identificationInfo/mri:MD_DataIdentification/mri:status/mri:MD_ProgressCode

with codeList and codeListValue attributes

StringProgressCode has code values of completed, historicalArchive, obsolete, onGoing, planned, required, underDevelopment. gmd:status is not required. Any string can be substituted as well. Since ISO supports multiple statuses for a collection/series, the CMR translates only the first one to UMM.
Section
Column
width50%

ISO 19115-1

No Format
<mri:MD_DataIdentification>
  <mri:citation>
    ...
    <mri:status>
      <mri:MD_ProgressCode codeList="{codeListLocation}#MD_ProgressCode"
        codeListValue="onGoing">onGoing</mri:MD_ProgressCode>
    </mri:status>
    ...
  </mri:citation>
</mri:MD_DataIdentification>
Column
width50%

UMM

No Format
"CollectionProgress" : "ACTIVE",


History

UMM Versioning

VersionDateWhat Changed
1.10.0
Changes would be tracked here
1.9.0

ARC Documentation

VersionDateWhat ChangedAuthor
1.02/19/18Recommendations/priority matrix transferred from internal ARC documentation to wiki space