You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 3 Next »

Element Description

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

Best Practices

In the CMR, spatial extent of data may be specified as a horizontal spatial domain, a vertical spatial domain, or an orbital spatial domain. The type of spatial domain being described in the metadata is identified via the 'Spatial Coverage Type' element. There are five different options for 'Spatial Coverage Type' in CMR. These include:

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

Certain metadata elements are associated with each of the Spatial Coverage Types. These are summarized below:

Horizontal 

Horizontal spatial extent is the area of the surface of the Earth which is covered by data. For horizontal spatial extent, the coverage must be specified as either Cartesian or Geodetic via the Coordinate System element:

SpatialExtent/HorizontalSpatialDomain/Geometry/CoordinateSystem:

Choice of:

  • CARTESIAN: 
  • GEODETIC: 

Furthermore, there are four different ways to express the horizontal spatial coverage. Only one of these options may be selected (i.e. you can't provide both a bounding rectangle and a point). However - each one of these options may be repeated as many times as necessary (i.e. multiple bounding rectangles may be provided) :

(1) Point

  • Point location as expressed in latitude and longitude coordinates. Multiple points may be provided if necessary.

(2) Bounding Rectangle

  • A rectangle as expressed with 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 whose shape/edges is defined by latitude/ longitude point pairs. The more points are provided, the more detailed the polygon will be. Exclusive zones within the polygon may also be identified (e.g. a small polygon within a larger polygon is specified as not being included in the spatial extent of the data set). 

(4) Line

  • A width-less line expressed as latitude/ longitude point pairs. Multiple points/ line vertices may be provided to express a complex line.   

Vertical

Vertical spatial extent can be used to describe data with a vertical component. The type of vertical spatial extent being described must be selected from a controlled list of options via the Type element:

SpatialExtent/VerticalSpatialDomain/Type:

Choice of:

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

Once a Type is selected, it is required to provide an accompanying value in the SpatialExtent/VerticalSpatialDomain/Value field. For example, the Type selected could be "Maximum Altitude" and the corresponding Value could be "50 KM".

Orbital 

When data is systematically collected via a satellite, it may provide useful to describe the orbital characteristics of the satellite platform. The Orbital spatial coverage type includes the following sub-elements, most of which are required if providing orbital information:

Swath Width: R

Period: R

Inclination Angle: R

Number of Orbits: R

Start Circular Latitude:    


Examples:


Element Specification

ModelElementTypeUsable Valid ValuesRequired?Cardinality
UMM-CCollectionProgressEnumeration

PLANNED

ACTIVE

COMPLETE

NOT APPLICABLE

Yes1

Value needed for translations:

The following value is needed by the CMR to translate older non UMM compliant records to and from the UMM and other supported specifications where non required elements are considered required but no valid is given.  This is needed partly because the CMR still allows a non UMM compliant record to be ingested with warnings.

NOT PROVIDED - It is necessary for this value to exist so that the CMR can translate older non UMM compliant records into the latest UMM specification where CollectionProgress is required. This value should not be used by metadata providers.


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).

Please see the expandable sections below for flowchart details.


  • Manual Review
    • Identify errors, discrepancies or omissions
  • Automated Review
    • Check that the field has been populated
    • Check that the field value is valid


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

DIF 9

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


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

DIF 10

<Dataset_Progress>IN WORK</Dataset_Progress>

UMM

"CollectionProgress" : "COMPLETE",

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

ECHO 10

<CollectionState>COMPLETED</CollectionState>

UMM

"CollectionProgress" : "COMPLETE",



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

ISO 19115-2 MENDS

<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>

UMM

"CollectionProgress" : "COMPLETE",



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

ISO 19115-2 SMAP

<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>

UMM

"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

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.

ISO 19115-1

<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>

UMM

"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



  • No labels