This document is an OGC Member approved international standard. This document is available on a royalty free, non-discriminatory basis. Recipients of this document are invited to submit, with their comments, notification of any relevant patent rights of which they are aware and to provide supporting documentation.
Approved for Public Release
Permission is hereby granted by the Open Geospatial Consortium, ("Licensor"), free of charge and subject to the terms set forth below, to any person obtaining a copy of this Intellectual Property and any associated documentation, to deal in the Intellectual Property without restriction (except as set forth below), including without limitation the rights to implement, use, copy, modify, merge, publish, distribute, and/or sublicense copies of the Intellectual Property, and to permit persons to whom the Intellectual Property is furnished to do so, provided that all copyright notices on the intellectual property are retained intact and that each person to whom the Intellectual Property is furnished agrees to the terms of this Agreement.
If you modify the Intellectual Property, all copies of the modified Intellectual Property must include, in addition to the above copyright notice, a notice that the Intellectual Property includes modifications that have not been approved or adopted by LICENSOR.
THIS LICENSE IS A COPYRIGHT LICENSE ONLY, AND DOES NOT CONVEY ANY RIGHTS UNDER ANY PATENTS THAT MAY BE IN FORCE ANYWHERE IN THE WORLD.
THE INTELLECTUAL PROPERTY IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, AND NONINFRINGEMENT OF THIRD PARTY RIGHTS. THE COPYRIGHT HOLDER OR HOLDERS INCLUDED IN THIS NOTICE DO NOT WARRANT THAT THE FUNCTIONS CONTAINED IN THE INTELLECTUAL PROPERTY WILL MEET YOUR REQUIREMENTS OR THAT THE OPERATION OF THE INTELLECTUAL PROPERTY WILL BE UNINTERRUPTED OR ERROR FREE. ANY USE OF THE INTELLECTUAL PROPERTY SHALL BE MADE ENTIRELY AT THE USER’S OWN RISK. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR ANY CONTRIBUTOR OF INTELLECTUAL PROPERTY RIGHTS TO THE INTELLECTUAL PROPERTY BE LIABLE FOR ANY CLAIM, OR ANY DIRECT, SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES, OR ANY DAMAGES WHATSOEVER RESULTING FROM ANY ALLEGED INFRINGEMENT OR ANY LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR UNDER ANY OTHER LEGAL THEORY, ARISING OUT OF OR IN CONNECTION WITH THE IMPLEMENTATION, USE, COMMERCIALIZATION OR PERFORMANCE OF THIS INTELLECTUAL PROPERTY.
This license is effective until terminated. You may terminate it at any time by destroying the Intellectual Property together with all copies in any form. The license will also terminate if you fail to comply with any term or condition of this Agreement. Except as provided in the following sentence, no such termination of this license shall require the termination of any third party end-user sublicense to the Intellectual Property which is in force as of the date of notice of such termination. In addition, should the Intellectual Property, or the operation of the Intellectual Property, infringe, or in LICENSOR’s sole opinion be likely to infringe, any patent, copyright, trademark or other right of a third party, you agree that LICENSOR, in its sole discretion, may terminate this license without any compensation or liability to you, your licensees or any other party. You agree upon termination of any kind to destroy or cause to be destroyed the Intellectual Property together with all copies in any form, whether held by you or by any third party.
Except as contained in this notice, the name of LICENSOR or of any other holder of a copyright in all or part of the Intellectual Property shall not be used in advertising or otherwise to promote the sale, use or other dealings in this Intellectual Property without prior written authorization of LICENSOR or such copyright holder. LICENSOR is and shall at all times be the sole entity that may authorize you or any third party to use certification marks, trademarks or other special designations to indicate compliance with any LICENSOR standards or specifications. This Agreement is governed by the laws of the Commonwealth of Massachusetts. The application to this Agreement of the United Nations Convention on Contracts for the International Sale of Goods is hereby expressly excluded. In the event any provision of this Agreement shall be deemed unenforceable, void or invalid, such provision shall be modified so as to make it valid and enforceable, and as so modified the entire Agreement shall remain in full force and effect. No decision, action or inaction by LICENSOR shall be construed to be a waiver of any rights or remedies available to it.
The GeoJSON encoding defined in this document is defined as a compaction through a normative context, of the proposed JSON-LD encoding, with some extensions as presented in section 8 of this document. Therefore, the JSON-LD encoding can also be applied to other RDF [OR8] encodings including RDF XML [OR11] and RDF Turtle [OR12].
This document makes no assumptions as to the “service” interfaces through which the metadata are accessed and applies equally well to a Service Oriented Architecture as well as a Resource Oriented or RESTful Architecture. The documented approach can be applied in combination with the following technologies:
OGC OpenSearch extensions [OR19], [OR20], [OR25],
W3C Linked Data Platform [OR21], [OR22],
OASIS searchRetrieve [OR23],
OASIS OData [OR24].
GeoJSON is a format for encoding collections of simple geographical features along with their non-spatial attributes using JSON. GeoJSON objects may represent a geometry, a feature, or a collection of features. GeoJSON supports the following geometry types derived from the OGC Simple Features specification: Point, LineString, Polygon, MultiPoint, MultiLineString, MultiPolygon and GeometryCollection. Features in GeoJSON contain a geometry object and additional properties, and a feature collection represents a list of features.
JSON is human readable and easily parseable. However, JSON is schemaless. JSON and GeoJSON documents do not include an explicit definition of the structure of the JSON objects contained in them. Therefore, this standard is based on a normative JSON-LD context which allows each property to be explicitly defined as a URI. Furthermore, the JSON encoding is defined using JSON Schema [OR18] which allows validation of instances against these schemas.
The following are keywords to be used by search engines and document catalogues
Attention is drawn to the possibility that some of the elements of this document may be the subject of patent rights. The Open Geospatial Consortium shall not be held responsible for identifying any or all such patent rights.
Recipients of this document are requested to submit, with their comments, notification of any relevant patent claims or other intellectual property rights of which they may be aware that might be infringed by any implementation of the standard set forth in this document, and to provide supporting documentation when possible.
iv. Submitting organisations
The following organisations will submit the original document or its revisions to the Open Geospatial Consortium (OGC):
CEOS – Committee on Earth Observation Satellites
ESA – European Space Agency
The editors would like to acknowledge that this work is the result of collaboration and review of many organisations and would like to thank for the comments and contributions from:
Note: this acknowledgement does not imply an endorsement by these organisations.
All questions regarding this submission should be directed to the editor or the submitters:
Andrea Della Vecchia
This OGC standard defines a GeoJSON [NR2] and JSON-LD [NR3] encoding of Earth Observation (EO) metadata for datasets (i.e., products or granules). The standard provides document models for the exchange of information describing EO datasets, both within and between different organisations.
The document model is derived from the conceptual models defined in the Earth Observation Metadata Profile of Observations and Measurements (O&M) OGC 10-157r4 [OR1], and the Unified Metadata Model for Granules (UMM-G) [OR2], depicted below.
Please note that the proposed encoding can also be applied to EO dataset metadata originally encoded according to other models, including ISO-19139 [OR27], ISO-19139-2 [OR28], etc. The mapping between UMM-G to these encodings can be found in [OR2] while this document defines the GeoJSON to UMM-G model. Future versions of this document may contain mappings to ISO models as annexes.
1.1 Design Approach and Rationale
This section is non-normative.
The metadata encoding defined in the document satisfies the following design goals.
Feature-based GeoJSON model: The model maximizes reuse of pre-existing standardized property names. Wherever possible, existing properties from GeoJSON [NR2] and OWS Context [NR5] are used for modeling EO product properties instead of new EO-specific property names. These are then are grouped under either feature.properties, feature.properties.[acquisitionInformation], or feature.properties.productInformation.
Simplicity: This document does not describe the full information models or XML encodings referred to above. The above standards (i.e., OGC 10-157r4 and UMM-G) should be referred to for these details. This standard intends to provide a simpler, overarching exchange format integrating comments from the Committee on Earth Observation Satellites (CEOS) Working Group on Information Systems and Services (WGISS) community, which supported the submission of this standard to the OGC.
Multiple use cases: The metadata model supports metadata for an acquisition (e.g., planned or acquired), for a simple product derived from one acquisition (planned, acquired or archived), or for a synthesis product (i.e., derived from multiple acquisitions over a certain period of time or from acquisitions by multiple sensors).
1.2 Document Outline
Hereafter a brief outline of the document content allows readers to jump directly to the topic of their interest.
Chapter 3 lists the normative and informative references used in this document.
Chapter 4 defines the main terms used in the document.
The conventions used in this document are explained in Chapter 5.
Chapter 6 gives an overview.
Chapter 7 specifies the proposed GeoJSON encoding.
Chapter 8 describes how the encoding can be extended with additional properties and describes the extension to JSON-LD which allows for describing multi-dimensional arrays as allowed by GeoJSON.
Chapter 9 provides information about the expected MIME media types which correspond to the proposed encodings.
Chapter 10 describes future work.
Finally, the following information is provided in the Annexes:
Annex A defines the Abstract Test Suite for the standard.
Annex B includes normative JSON-LD @context definitions that allow interpreting the GeoJSON encoding as JSON-LD. It also formally defines the EO vocabulary (i.e., RDF properties and classes) in RDF Schema format.
Annex C presents the mapping of the EO properties proposed in this specification to the OGC 10-157r4 and UMM-G conceptual models.
Annex D contains the complete listing of examples illustrating the encodings defined in this document.
Annex E includes the JSON schema definitions defining the GeoJSON encoding.
Annex F explains where the schema file, context files and examples can be found in the OGC schema repository.
Annex G provides the revision history of this document.
2.1 Conformance to base specifications
This section describes the compliance testing required for an implementation of this standard.
2.2 Conformance classes
The framework, concepts, and methodology for testing and the criteria to be achieved in order to claim conformance are specified in the OGC Compliance Testing Policies and Procedures and the OGC Compliance Testing web site.
Annex A defines a set of tests and conformance classes that will support various applications with a range of different requirements. The following conformance classes are distinguished. Testing is based on data validation. In order to conform to this OGC standard, an implementation shall choose to implement one or more of the conformance classes specified in Annex A (normative).
Table : Conformance classes related to data instances
Single EarthObservation object or
collection of EarthObservation objects.
The following normative documents contain provisions that, through reference in this text, constitute provisions of this document. For dated references, subsequent amendments to, or revisions of, any of these publications do not apply. For undated references, the latest edition of the normative document referred to applies.
3.1 Normative references
[NR2] RFC 7946, The GeoJSON Format, 2016, https://tools.ietf.org/html/rfc7946
This document uses the terms defined in Sub-clause 5.3 of OGC 06-121r9 [NR6], which is based on the ISO/IEC Directives, Part 2, Rules for the structure and drafting of International Standards. In particular, the word “shall” (not “must”) is the verb form used to indicate a requirement to be strictly followed to conform to this standard.
For the purposes of this document, the following additional terms and definitions apply.
While expansion removes context from a given input, compaction’s primary function is to perform the opposite operation: to express a given input according to a particular context. Compaction applies a context that specifically tailors the way information is expressed for a particular person or application. This simplifies applications that consume JSON or JSON-LD by expressing the data in application-specific terms, and it makes the data easier to read by humans [OR13].
A set of rules for interpreting a JSON-LD document as specified in the section “The Context” of the JSON-LD specification [NR3].
Observation obtained by satellite instruments (OGC 10-140). See granule and product.
A satellite acquisition. May consists of multiple scenes.
4.5 Domain (RDF)
Domain (rdfs:domain) is used to state that any resource that has a given property is an instance of one or more classes [OR10].
The algorithm that removes [JSON-LD] context is called expansion [OR13].
The smallest aggregation of data that can be independently managed. Granule usually matches the individual file of EO satellite data.
A character string that may be composed of numbers and characters that is exchanged between the client and the server with respect to a specific identity of a resource.
4.11 JSON Schema
JSON Schema is a JSON media type for defining the structure of JSON data. JSON Schema provides a contract for what JSON data is required for a given application and how to interact with it [OR18].
A Product or a Dataset corresponds to an identifiable collection of data under one single identifier. It is independent of a physical form or an encoding even if it is normally distributed in a single file.
4.13 Range (RDF)
Range (rdfs:range) is used to state that values of a property are instances of one or more classes [OR10].
4.14 RDF Triple
An RDF triple consists of three components: the subject, the predicate and the object. An RDF triple is conventionally written in the order subject, predicate, object. [OR9].
The result of cutting a datastrip into multiple parts
4.16 service interface
Shared boundary between an automated system or human being and another automated system or human being [ISO 19101].
Area imaged on the surface by an Earth observation instrument.
4.18 synthesis products
Synthesis (or composite) products are products that are generated by combining information from multiple EO Products that are acquired over a certain period of time.
This section provides details and examples for any conventions used in the document. Examples of conventions are symbols, abbreviations, use of XML schema, or special notes regarding how to read the document.
5.1 Abbreviated terms
Some frequently used abbreviated terms:
API Application Programming Interface
ATS Abstract Test Suite
CEOS Committee on Earth Observation Satellites
EO Earth Observation
EOP Earth Observation Product
GML Geography Markup Language
HMA Heterogeneous Missions Accessibility
HTTP HyperText Transfer Protocol
IRI Internationalised Resource Identifier
ISO International Organisation for Standardisation
LDP Linked Data Protocol
LMB LiMB looking
OASIS Organization for the Advancement of Structured Information Standards
OGC Open Geospatial Consortium
O&M Observations and Measurements
OWC OGC Web Services Context
RDF Resource Description Framework
RDFS RDF Schema
REST Representational State Transfer
SAR Synthetic Aperture Radar
SI International System of Units (French: Système international d’unités)
SSP Synthesis and Systematic
UML Unified Modeling Language
UMM Unified Metadata Model
UMM-G Unified Metadata Model for Granules
URI Uniform Resource Identifier
URL Uniform Resource Locator
URN Uniform Resource Name
W3C World Wide Web Consortium
WGISS Working Group on Information Systems and Services
WKT Well-Known Text
XML eXtensible Markup Language
XSD XML Schema Definition Language
5.2.1 JSON Schema diagrams
The schema diagrams included in the document show the GeoJSON structure expressed in JSON Schema [OR18] and documented in Annex E.1.
Table : JSON Schema diagram symbols
JSON Schema Entity
Definitions are shown as blue rectangles with solid
Mandatory properties are shown with solid borders.
Optional properties are shown with dashed borders.
Property of type "Object" referring to a
"Definition" of the Object.
The "Def" attribute inside a rectangle
representing a property of type Object refers to the corresponding Object
"All Of" operator
Contains one or more sub-schemas (definitions), added as
children of the operator. An instance is valid if it is valid against all
"Any Of" operator
Contains one or more sub-schemas (definitions), added as
children of the operator. An instance is valid if it is valid against at
least one of these sub-schemas.
"One Of" operator
Contains one or more sub-schemas (definitions), added as
children of the operator. An instance is valid if it is valid against exactly
one of these sub-schemas.
The "Def" attribute inside a rectangle
representing a (Sub) Schema refers to the corresponding Object definition.
The data dictionary tables in the current document use the JSONPath notation [OR34]. A brief overview of this notation is included in the table below which is taken from [OR34].
the root object/element
the current object/element
. or 
recursive descent. JSONPath borrows this syntax from E4X.
wildcard. All objects/elements regardless their names.
subscript operator. XPath uses it to iterate over element
Union operator in XPath results in a combination of node
sets. JSONPath allows alternate names or array indices as a set.
applies a filter (script) expression.
5.3 Namespace abbreviations
The following namespace abbreviations will be used in this document:
Table : Namespace abbreviations
Full namespace URI
5.4 Layout and identifiers
The normative provisions in the current document are denoted by the URI http://www.opengis.net/spec/eo-geojson/1.0. All requirements and conformance classes that appear in this document are denoted by relative URIs which are relative to this base URI.
This document applies the “double quote” guideline defined in [OR16]: “If a property requires quotes, double quotes must be used. All property names must be surrounded by double quotes. Property values of type string must be surrounded by double quotes. Other value types (like boolean or number) should not be surrounded by double quotes.”
5.6 Data dictionary tables
This document includes data dictionary tables with information as per sub-clause 5.5 of OGC 06-121r9 [NR6]. The following comments apply.
The mapping of property names (column 1) on properties of the abstract metadata models (OGC 10-157r4 and UMM-G) is included in Annex C. Column 1 provides the JSON property name as well as the corresponding JSONPath [OR34] expression.
Properties representing measurements (e.g., gml:measureType) are encoding in a simplified way. Only the value is represented as a numeric property. The unit of measure is implied and shall correspond to the SI base unitor derived unit without prefix.
This standard defines a GeoJSON-based [NR2] serialization syntax for the Earth Observation Vocabulary (Annex B) that conforms to a subset of [NR3] syntax constraints but does not require JSON-LD processing. While other serialization forms are possible, such alternatives are not discussed in this document.
When serialized, absent properties are represented by either (a) setting the property value to null, or (b) by omitting the property declaration altogether at the option of the publisher. These representations are semantically equivalent. If a property has an array value, the absence of any items in that array shall be represented by omitting the property entirely or by setting the value to null. The appropriate interpretation of an omitted or explicitly null value is that no value has been assigned as opposed to the view that the given value is empty or nil.
JSON does not have a formal class model. JSON objects are just sets of properties. However, the JSON encoding described in this standard features a “type” property on each JSON object.
An EO Dataset Metadata Document conforming to this standard is a GeoJSON document whose root value is a Feature or FeatureCollection object, and whose MIME media type corresponds to one of the media types described in chapter 9.
The JSON format is currently described by two competing standards, RFC7159 [NR1] and ECMA-404 [NR13]. Both standards documents are consistent, but the latter defines mainly the grammatical syntax where the former provides some additional semantic and security points.
6.2 GeoJSON Format Specification
GeoJSON [NR2] is a format for encoding collections of simple geographical features along with their non-spatial attributes using JSON. GeoJSON consists of a single object representing a geometry, feature, or collection of features. The geometries supported are Point, MultiPoint, LineString, MultiLineString, Polygon, MultiPolygon and Geometry Collections.
7 GeoJSON Encoding Specification
7.1 Requirements class: Earth Observation
"EarthObservation" object shall implement the properties shown in Table 4, with the value matching the type shown, and with the
The EarthObservation block inherits all properties of the GeoJSON Feature object. In addition, it may contain an optional @context property. The @context properties shall typically be absent in the GeoJSON encoding and implicitly refer to the normative @context defined in Annex B.
Complete description of EarthObservation is given in Table 4. Most properties are inherited from the Feature object defined in [NR2].
Table : EarthObservation object properties
context property either embedding an actual context or a reference to the
normative JSON-LD context defined in Annex B: "normative JSON-LD @context definition".
See Annex B.1.1.
Zero or one
Type of the
EarthObservation metadata element.
This property is a string with fixed value "Feature".
identifier for the EarthObservation element (IRI).
on the coordinate range of the geometry object representing the footprint
(See [NR2]). The value is an array of length 4 (assuming the number of
dimensions represented in the contained geometries is 2). Typically, south-west point and north-east
point. The value defines a shape with
edges that have constant longitude and latitude.
Zero or one
description of the target location observed during the EarthObservation. See
shall be either a Geometry object or a JSON null value.
Geometry or null value (See section 7.4)
other properties of the EarthObservation not covered by the properties higher
in this table as imposed by [NR2]. See section 7.1.1
In the remainder of the document, we will not include the @context property in the GeoJSON encoding in which case it is implied as explained in Annex B.1.1.
"Properties" object shall implement the properties shown in Table 5, with the value matching the type shown, and with the
"Properties" object shall implement the properties of a MetadataInformation
object (Table 8).
"Properties" object shall implement the properties of a
DataIdentification object (Table 9).
The Properties block contains the EO properties and hypermedia links to related objects. It inherits all MetadataInformation and DataIdentification properties. The EO properties are in two main groups, i.e., “acquisitionInformation” and “productInformation” with multiplicity shown below. This allows having metadata:
Only consisting of “acquisitionInformation” and no productInformation, and
Consisting of multiple “acquisitionInformation” elements and 0 or 1 “productInformation” elements as occurs for synthesis products.