Module Documentation: eml-coverage

Geographic Coverage is a container for spatial information about a project, a resource, or an entity within a resource. It allows a bounding box for the overall coverage (in lat long), and also allows description of arbitrary polygons with exclusions.
Example(s):
Please see the individual sub fields for specific examples.

Derived from: TemporalCoverage (by xs:extension)

This field specifies temporal coverage, and allows coverages to be a single point in time, multiple points in time, or a range of dates. Dates can be expressed in terms of both calendar dates and geologic dating systems.
Example(s):
Please see the individual sub fields for specific examples.

Derived from: TaxonomicCoverage (by xs:extension)

Taxonomic Coverage is a container for Taxonomic information about a project, a resource, or an entity within a resource. It includes a list of species names (or higher level ranks) from one or more classification systems.
Example(s):
Please see the individual sub fields for specific examples.

The singleDateTime field is intended to describe a single date and time for an event. There is a choice between two options: a calendar date with a time, or a geologic age.
Example(s):
Please see the individual sub-elements for example.

The 'RangeOfDatesType' field is intended to be used for describing a range of dates and/or times. It may be used multiple times to document multiple date ranges. It allows for two 'singleDateTime' fields, the first to be used as the beginning dateTime, and the second to be used as the ending dateTime of the range.
Example(s):
Please see the examples from the 'singleDateTime' field for specific examples.

A single time stamp signifying the beginning of some time period. There is a choice between two options: a calendar date with a time, or a geologic age.
Example(s):
Please see the individual sub-elements for example.

A single time stamp signifying the end of some time period. There is a choice between two options: a calendar date with a time, or a geologic age.
Example(s):
Please see the individual sub-elements for example.

The calendar date field is used to express a date, giving the year, month, and day. The format should be one that complies with the International Standards Organization's standard 8601. The recommended format for EML is YYYY-MM-DD, where Y is the four digit year, M is the two digit month code (01 - 12, where January = 01), and D is the two digit day of the month (01 - 31). This field can also be used to enter just the year portion of a date.
Example(s):
2001-01-01
2001-10-12
2001
1895

The time field is used to express the hour (and optionally minute, or minute and second) of the day for an event, and should comply with the International Standards Organization's standard 8601. The recommended format for EML is hh:mm:ssTZD, where hh is the two digit hour of the day, mm is the two digit minute of the hour, and ss is the two digit second of the minute. TZD stands for Time Zone Designator which is used to handle time zone offsets. Times may be expressed in two ways: 1) UTC (Coordinated Universal Time, also known as Greenwich Mean Time, or GMT), with a special UTC designator ("Z"), 2) local time, together with a time zone offset in hours and minutes. A time zone offset of "+hh:mm" indicates that the date or time uses a local time zone which is "hh" hours and "mm" minutes ahead of UTC. A time zone offset of "-hh:mm" indicates a local time zone which is "hh" hours and "mm" minutes behind UTC.
Example(s):
1) 08:31:22Z , which means eight thirty one and 22 seconds in the morning at Coordinated Universal Time (Greenwich Mean Time). 2) 14:06:09-08:00 , which means six minutes, nine seconds past two o'clock p.m., Pacific Standard Time (which is offset eight hours behind UTC)

A name, code, or date describing an event or period in an alternative time scale, for instance as an absolute date calculated using a named dating method, or as a relative date that is drawn from stratigraphy or biostratigraphy. Calendar dates as provided in the ISO 8601 dating system used in the standard CSDGM are not adequate to describe geologic time periods. Absolute geologic time is usually measured in millions of years before present, but may use different units and relative base times. Relative geologic time is measured by subdivisions of the earth's geology. in an order based upon relative age, most commonly, vertical or stratigraphic position. The actual dating systems used in geologic studies often tie relative times measured through stratigraphy or biostratigraphy to a particular absolute time using radioisotope dating techniques, among others. As these methods for absolute dating have improved, the estimates of the dates for strata have changed, consequently, it would be inaccurate to record absolute dates in situations where relative dates were measured. This structure is provided as an optional alternative to the standard calendar dates provided by ISO 8601.
Example(s):
Please see the individual sub-fields for specific examples.

Name of a recognized alternative time scale. This includes 'Absolute' as the name of the time scale for measuring geologic dates before the present and names of geologic dating systems that are arrangements of symbols or names in order of relative geologic time.
Example(s):
'Absolute', 'Geomagnetic Polarity Time Scale', 'International Geological Time Scale', 'Oxygen-Isotope'

Either an absolute date or a relative age name describing an event or period in an alternative time scale such as the Geologic Time Scale.
Example(s):
For example, '300 Ma' (300 million years before present) is a Geologic_Age_Estimate based on the Absolute Geologic_Time_Scale, 'C28r' is a chron name from the Geomagnetic Polarity Time Scale, and 'Maastrichtian' and 'Jurassic' are names from the International Geological Time Scale. Since different relative geologic time scales are often not aligned, multiple geologic dates may need to be specified. For example, the Geomagnetic Polarity Time Scale chron 'C29r', at the K/T boundary lies in both the 'Maastrichtian' and the 'Danian' stages from the International Geological Time Scale, thus if you were documenting this event using the International Geological Time Scale, both 'Maastrichtian' and 'Danian' should be included here.

The error estimate for the alternative time. This should include the units of measure, a description of what the error estimate represents and how it was calculated.
Example(s):
+/- 5 Ma (Million Years)

The name and/or description of the method used to calculate the age estimate. Detailed information about the method may be provided through references contained in the Time Scale Citation field.

Citation for works providing detailed information about any element of the time scale age.
Example(s):
For example, a publication describing the methodology used for carbon dating or describing the basic geologic time scale in more detail could be cited here.

geographicDescription is a short text description of a dataset's geographic areal domain. A text description is especially important to provide a geographic setting when the extent of the data set cannot be well described by the "boundingCoordinates", or in the case of data which are not specifically geospatial. Assuming the "boundingCoordinates" do not adequately describe the extent of the data set, the discrepancy can be identified and described here. The coordinates may define a rectangle around a country, with this geographicDescription element containing a disclaimer and/or further details concerning the border. A study of the diseases of salmon may not have a specific geographic extent associated with it, but the salmon were collected in the states of Washington and Oregon. The "boundingCoordinates" might form a general rectangle around the states of Washington and Oregon, but the "geographicDescription" might describe the fact that the study took place only along certain rivers within those states.

This data element differs from the standard data element "Place_Keyword" in that it allows a free text description of the geographic extent, rather than just a list of words or phrases useful as an index of location names associated with the data set.

This element can also contain information about the collection of the boundingCoordinates, e.g., an altitude value that is referenced to Mean Lower Low Water, or the projection system that the latitude and longitude coordinates were taken from.

Example(s):
"Manistee River watershed"
"extent of 7 1/2 minute quads containing any property belonging to Yellowstone National Park"
"ponds and reservoirs larger than 2 acres in Jefferson County, Colorado".

Bounding Coordinates are the four margins (N, S, E, W) of a bounding box, or when considered in lat-lon pairs, the corners of the box. These elements are meant to convey general information and are not for accurate mapping. More specific information may be included by using the elements in the spatialReference schema. The limits of coverage of a data set should be expressed as decimal latitudes and longitudes, and in the order western-most, eastern-most, northern-most, and southern-most. By convention, latitudes and longitudes are referenced to the Equator and to the Prime Meridian (the datums), respectively. By definition, the 0 and 180 meridians themselves do not belong in either hemisphere, but local conventions may place them in either. All coordinates are typed as decimals. Since all four elements are required, a bounding area that is a single point should use the same values for northBoundingCoordinate and southBoundingCoordinate, and likewise for westBoundingCoordinate and eastBoundingCoordinate. In the case of a data set that comprises all longitudes (e.g., a horizontal band between 2 parallels that fully encompasses the earth ), please use a westBoundingCoordinate of -180.0, and an eastBoundingCoordinate of 180.0 (or +180.0). In this case, it could be considered geographically appropriate to specify both values as "180" (or any other meridian), but this could also be interpreted as only the meridian itself, so this is not recommended
Example(s):
Please see the individual sub-fields.

The westBoundingCoordinate field defines the longitude of the western-most point of the bounding box that is being described. A longitude coordinate is typed as a decimal, i.e., decimal degrees from -180 to 180, inclusive. Decimal degrees may be expressed to any precision desired. Fractions of a degree in minutes and seconds should be converted to degree fractions. Strings denoting direction or hemisphere (e.g., 'W' or 'west') are not allowed. Longitudes east of the prime meridian must be specified by a plus sign (+), or by the absence of a minus sign (-), and longitudes west of the meridian shall be prefixed with minus sign (-). In the case of a data set that comprises all longitudes (e.g., a horizontal band between 2 parallels that fully encompasses the earth ), please use a westBoundingCoordinate of -180.0, and an eastBoundingCoordinate of 180.0 (or +180.0). In this case, it could be considered geographically appropriate to specify both values as "180" (or any other meridian), but this could also be interpreted as only the meridian itself, so this is not recommended.
Example(s):
-118.25
+25
45.24755

Derived from: xs:decimal (by xs:restriction)

Allowed values:

• Minimum: -180.0
• Maximum: 180.0

The eastBoundingCoordinate field defines the longitude of the eastern-most point of the bounding box that is being described. A longitude coordinate is typed as a decimal, i.e., decimal degrees from -180 to 180, inclusive. Decimal degrees may be expressed to any precision desired. Fractions of a degree in minutes and seconds should be converted to degree fractions. Strings denoting direction or hemisphere (e.g., 'W' or 'west') are not allowed. Longitudes east of the prime meridian must be specified by a plus sign (+), or by the absence of a minus sign (-), and longitudes west of the meridian shall be prefixed with minus sign (-). In the case of a data set that comprises all longitudes (e.g., a horizontal band between 2 parallels that fully encompasses the earth ), please use a westBoundingCoordinate of -180.0, and an eastBoundingCoordinate of 180.0 (or +180.0). In this case, it could be considered geographically appropriate to specify both values as "180" (or any other meridian), but this could also be interpreted as only the meridian itself, so this is not recommended.
Example(s):
-118.25
+25
45.24755

Derived from: xs:decimal (by xs:restriction)

Allowed values:

• Minimum: -180.0
• Maximum: 180.0

The northBoundingCoordinate field defines the latitude of the northern-most point of the bounding box that is being described. A latitude coordinate is typed as a decimal, i.e., decimal degrees from -180 to 180, inclusive. Decimal degrees may be expressed to any precision desired. Fractions of a degree in minutes and seconds should be converted to degree fractions. Strings denoting direction or hemisphere (e.g., 'N' or north') are not allowed. Latitudes north of the equator must be denoted by a plus sign (+), or by the absence of a minus sign (-), and latitudes south of the equator shall be prefixed with minus sign (-). A location with latitude of +90 (90) or -90 degrees will specify the position at the North or South Pole, respectively.
Example(s):
-18.25
+25
65.24755

Derived from: xs:decimal (by xs:restriction)

Allowed values:

• Minimum: -90.0
• Maximum: 90.0

The southBoundingCoordinate field defines the latitude of the southern-most point of the bounding box that is being described. A latitude coordinate is typed as a decimal, i.e., decimal degrees from -180 to 180, inclusive. Decimal degrees may be expressed to any precision desired. Fractions of a degree in minutes and seconds should be converted to degree fractions. Strings denoting direction or hemisphere (e.g., 'N' or north') are not allowed. Latitudes north of the equator must be denoted by a plus sign (+), or by the absence of a minus sign (-), and latitudes south of the equator shall be prefixed with minus sign (-). A location with latitude of +90 (90) or -90 degrees will specify the position at the North or South Pole, respectively.
Example(s):
-118.25
+25
84.24755

Derived from: xs:decimal (by xs:restriction)

Allowed values:

• Minimum: -90.0
• Maximum: 90.0

The bounding altitude field is intended to contain altitudinal (elevation) measurements for the bounding box being described. It allows for minimum and maximum altitude fields, as well as a field for the units of measure. The combination of these fields provide the vertical extent information for the bounding box.
Example(s):
Please see the individual sub-fields for specific examples.

The minimum altitude extent of coverage for the bounding box that is being described. The minimum altitude should be in reference to a known datum (e.g., Mean Sea Level), which should be part of the geographicDescription.
Example(s):
100.6
-12

The maximum altitude extent of coverage for the bounding box that is being described. The maximum altitude should be in reference to a known datum, which should be part of the geographicDescription.
Example(s):
100.6
-10

The unit that the altitude is expressed in. See the description under the Type definition

This construct creates a spatial ring with a hollow center. This doughnut shape is specified by the outer ring (datasetGPolygonOuterRing) and the inner exclusion zone (datasetGPolygonExclusionGRing) which can be thought of as the hole in the center of a doughnut. This is useful for defining areas such as the shores of a pond where you only want to specify the shore excluding the pond itself.
Example(s):
Please see the individual sub-fields for specific examples.

The outer containment loop of a datasetGPolygon. This is the outer part of the doughnut shape that encompasses the broadest area of coverage. It can be created either by a gRing (list of points) or 3 or more gRingPoints. See the sub-elements and their Type definitions for more specific information.

This element is generally analogous to the FGDC outer ring although somewhat differently specified. Documentation for an FGDC G-Ring states that 4 points are required to define a polygon, and the first and last should be identical. However this is not enforceable in XML Schema, and so in EML a minimum of 3 <gRingPoint>s is required to define a polygon, and it can be assumed that a polygon is closed by joining the last point to the first. XSL stylesheets that transform EML instances to the FGDC specification should repeat the first gRingPoint node as the last when creating a list of points.

A single geographic location. As a child of <datasetGPolygonOuterGRing> a minimum of 3 are required to define a polygon. The polygon is presumed to be closed. Please see the sub elements and the Type description for more information about creating a point location.

A set of ordered pairs of floating-point numbers, The number of points in the string is not enforced by EML. However, authors should note that in order for this field is to be directly translated to FGDC, 4 points should be included in the string. See the Type for more information on constructing the string.

the closed nonintersecting boundary of a void area (or hole in an interior area). This is the center of the doughnut shape created by the datasetGPolygon. It can be created either by a gRing (list of points) or one or more gRingPoints. See the sub-elements and their Type definitions for more information.

This element is generally analogous to an FGDC exclusion ring "Data Set G-Polygon Exclusion G-Ring", although it's children are somewhat differently described. Documentation for the FGDC component states that 4 points are required to define a polygon, and the first and last should be identical. However this EML element requires only one point so that a single point can be excluded, presumably, a single station. If multiple single stations are to be excluded, then authors should include multiple <datasetGPolygonExclusionGRing>s.

A single geographic location. This is useful if you register your datasets by a single geospatial point, such as the lat/long of your research station. Please see the sub elements and the Type description for more information on constructing a gRingPoint

A set of ordered pairs of floating-point numbers, See the Type for more information

A latitude coordinate is typed as a decimal, i.e., decimal degrees from -90 to 90, inclusive. Decimal degrees may be expressed to any precision desired. Fractions of a degree in minutes and seconds should be converted to degree fractions. Strings denoting direction or hemisphere (e.g., 'S' or 'south') are not allowed. Latitudes north of the equator must be specified by a plus sign (+), or by the absence of a minus sign (-), and latitudes south of the equator shall be prefixed with minus sign (-).
Example(s):
34.123
-18.25
+78.25

Derived from: xs:decimal (by xs:restriction)

Allowed values:

• Minimum: -90.0
• Maximum: 90.0

The longitude of a point of the g-ring A longitude coordinate is typed as a decimal, i.e., decimal degrees from -180 to 180, inclusive. Decimal degrees may be expressed to any precision desired. Fractions of a degree in minutes and seconds should be converted to degree fractions. Strings denoting direction or hemisphere (e.g., 'W' or 'west') are not allowed. Longitudes east of the prime meridian must be specified by a plus sign (+), or by the absence of a minus sign (-), and longitudes west of the meridian shall be prefixed with minus sign (-).
Example(s):
-118.25
+25
45.24755

Derived from: xs:decimal (by xs:restriction)

Allowed values:

• Minimum: -180.0
• Maximum: 180.0

Documentation of taxonomic sources, procedures, and treatments.

Information about the classification system or authority used.
Example(s):
Flora of North America

Relevant literature for documenting the used classification system.

A description of any modifications or exceptions made to the classification system or authority used.

Information on any non-authoritative materials (e.g. field guides) useful for reconstructing the actual identification process.

Information about the individual(s) responsible for the identification(s) of the specimens or sightings, etc.

Description of the methods used for the taxonomic identification.
Example(s):
specimen processing, comparison with museum materials, keys and key characters, chemical or genetic analyses

Information concerning the proportions and treatment of unidentified materials, estimates of the importance and possible identities of uncertain determinations, synonyms or other incorrect usages, taxa not well treated or requiring further work, and expertise of field workers.
Example(s):
materials sent to experts, and not yet determined

Information on the types of specimen, the repository, and the individuals who identified the vouchers.

A word or phrase describing the type of specimen collected.
Example(s):
herbarium specimens, blood samples, photographs, individuals, or batches

Information about the curator or contact person and/or agency responsible for the specimens.

The 'originator' element provides the full name of the person, organization, or position associated with the resource. Typically, the originator role is set to "owner" to indicate the list of parties who "own" the resource, but other roles such as "principal investigator", "author", and "editor" are provided.
Example(s):
Please see the examples within the sub fields for the responsible party.

A description of the range of taxa addressed in the data set or collection.
Example(s):
"All vascular plants were identified to family or species, mosses and lichens were identified as moss or lichen."

Information about the range of taxa addressed in the data set or collection. See the Type definition for more information.

The name of the taxonomic rank for which the Taxon rank value is provided. This field allows for the name one of the accepted levels of Taxa.
Example(s):
'Kingdom', 'Division/Phylum', 'Class', 'Order', 'Family', 'Genus', and 'Species'

The name representing the taxonomic rank of the taxon being described. The values included may be referenced from an authoritative source such as the Integrated Taxonomic Information System (ITIS)in the U.S. (http://www/itis.usda.gov) and in Canada (http://sis.agr.gc.ca/pls/itisca/taxaget). Also, Species2000 is another source of taxonomic information, found at (http://www.sp2000.org)
Example(s):
'Acer' would be an example of a genus rank value, and 'Acer rubrum' would be an example of a species rank value with the common name of red maple. It is recommended to start with Kingdom and include ranks down to the most detailed level possible.

Specification of applicable common names. These common names may be general descriptions of a group of organisms if appropriate.
Example(s):
insects, vertebrate, grasses, waterfowl, vascular plants, red maple.

Information about the range of taxa addressed in the data set or collection. See the Type definition for more information.

Type: res:SystemType

Use: optional

Type: res:ScopeType

Use: optional

Default value: document

Type: res:SystemType

Use: optional

Type: res:ScopeType

Use: optional

Default value: document

Type: res:IDType

Use: optional

Type: res:SystemType

Use: optional

Type: res:ScopeType

Use: optional

Default value: document

Type: res:IDType

Use: optional

Type: res:IDType

Use: optional

Type: res:SystemType

Use: optional

Type: res:ScopeType

Use: optional

Default value: document

Type: res:IDType

Use: optional

This field is a container for the spatial, temporal and taxonomic coverages that apply to various resources, often dataset resources. Please see the individual descriptions of the sub fields for more detail.
Example(s):
Please see the individual sub fields for specific examples.

The temporal coverage fields are intended to be used in describing the date and time of an event. It allows for three general descriptions: a single date or time, multiple dates or times, and a range of date or times.
Example(s):
Please see the individual sub fields for specific examples.

The SingleDateTimeType field is intended to describe a single date and time for an event. There is a choice between two options: a calendar date with a time, or a geologic age.
Example(s):
Please see the individual sub-elements for example.

Geographic Coverage is a container for spatial information about a a project, a resource, or an entity within a resource. It is meant for general information and not for accurate mapping. More specific information, including mapping projections, is covered by EML in the spatialReference schema.
Example(s):
Please see the individual sub-elements for specific examples.

A single geographic location. This is useful if you register your datasets by a single geospatial point, such as the lat/long of your research station.

Taxonomic Coverage is a container for taxonomic information about a project, a resource, or an entity within a resource.
Example(s):
Please see the individual sub-fields for specific examples.

Information about the range of taxa addressed in the data set or collection. It is recommended that one provide information starting from the taxonomic rank of kingdom, to a level which reflects the data set or collection being documented. The levels of Kingdom, Division/Phylum, Class, Order, Family, Genus, and Species should be included as ranks as appropriate. Because the taxonomic ranks are hierarchical, the Taxonomic Classification field is self-referencing to allow for an arbitrary depth of rank, down to species.
Example(s):
The Taxonomic Classification field consists of a sequence of 4 fields: taxonomic rank, taxonomic rank value, common name, and finally Taxonomic Classification (self-referencing). Please see the sub-fields for specific examples.

Derived from: xs:string (by xs:restriction)

Allowed values:

A set of ordered pairs of floating-point numbers, separated by commas, in which the first number in each pair is the longitude of a point and the second is the latitude of the point. Longitude and latitude are specified in decimal degrees with north latitudes positive and south negative, east longitude positive and west negative

Note on the relationship to FGDC: This element is generally analogous to the FGDC component for ring, although implemented somewhat differently. Documentation for FGDC states that 4 points are required to define a polygon, and the first and last should be identical, although this is not enforceable in XML Schema. In addition, EML does not enforce any pattern on the string used for a GRingType, so that it may be used differently as a child of EML's <datasetGPolygonOuterGRing> or <datasetGPolygonExclusionGRing> elements. If authors of EML instance documents wish the contents of this element to be directly translated to FGDC, they should comply with the example below when constructing their strings. Alternatively, in most cases, a sequence of gRingPoints can be used in EML instances, which can be processed into content for an FGDC Data Set G-Polygon G-Ring.

Example(s):
This is an acceptable gRing:
12, 2.0987 12, -7.5555 34.345,10.40
However, for translation to FGDC, construct your string like this:
-119.453,35.0 -125,37.5555 -122,40 -119.453,35.0