I. Abstract
JavaScript Object Notation (JSON) [NR1] has been gaining in popularity for encoding data in Web-based applications. JSON consists of sets of objects described by name/value pairs. GeoJSON [NR2] is a format for encoding collections of simple geographical features along with their non-spatial attributes using JSON. This OGC Best Practice describes a GeoJSON [NR2] and JSON-LD [NR13] encoding for Earth Observation (EO) metadata for collections (dataset series). This standard can be applied to encode metadata based on the OGC 11-035r1 [OR20] or ISO19139 [OR27], ISO19139-2 [OR28] specifications, or as an encoding of the Unified Metadata Model for Collections (UMM-C) conceptual model [OR2].
The GeoJSON encoding defined in this document is defined as a compaction1 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.
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 [OR7] which allows validation of instances against these schemas.
II. Keywords
The following are keywords to be used by search engines and document catalogues.
ogcdoc, ogc documents, Earth Observation, EO, EO Collection, EO Dataset, EO Dataset Series, EO Product, GeoJSON, JSON, JSON-LD, Linked Data, Metadata
III. Security Considerations
No security considerations have been made for this document.
IV. Submitting Organizations
The following organizations submitted this Document to the Open Geospatial Consortium (OGC):
- CGI
- Con terra GmbH
- ESA – European Space Agency
- EUMETSAT
- Spacebel s.a.
V. Submitters
All questions regarding this submission should be directed to the editor or the submitters:
Name | Affiliation |
---|---|
Yves Coene | Spacebel s.a. |
Uwe Voges | con terra GmbH |
Olivier Barois | ESA |
Andrea Della Vecchia | ESA |
John Taylor | CGI |
Michael Schick | EUMETSAT |
The editors would like to acknowledge that this work is the result of collaboration and review of many organizations and would like to thank for the comments and contributions from:
-
CEOS/WGISS
-
DLR
-
NASA
-
VITO
Note: this does not imply a complete endorsement by these organisations.
EO Collection GeoJSON(-LD) Encoding
1. Scope
This OGC Best Practice defines a GeoJSON [NR2] and JSON-LD [NR13] encoding of Earth Observation (EO) metadata for collections (a.k.a. dataset series). The Best Practice provides document models for the exchange of information describing EO collections, both within and between different organisations.
EO collections are collections of datasets sharing the same product specification. These collections are also called dataset series as they may be mapped to ‘dataset series’ following the terminology defined in ISO 19113, ISO 19114, and ISO 19115. An EO collection typically corresponds to a series of EO datasets (also called EO products) derived from data acquired:
-
Either from an instrument in a dedicated mode on board a single satellite platform; or
-
by a series of instruments, possibly from different satellite platforms, but in this case working in the same instrument mode.
Examples of EO dataset series are, for instance, datasets stemming from satellite platforms such as ‘TerraSAR-X spotlight mode,’ ‘ESA Envisat MERIS Full Resolution L1+2,’ or ‘SPOT multispectral 10 m resolution.’ However, there is a tendency to group products into dataset series following other kinds of criteria such as range of resolution or product quality (e.g., snow collections or cloud-free collections).
Figure 1 — EO Collection Metadata Simlified Conceptual Model from [OR19]
The implementation is derived from the conceptual models defined in OGC 11-035r1 [OR19], itself based on ISO19115:2003 [OR22], ISO19139:2007 [OR27] and ISO19139-2 [OR28], and the Unified Metadata Model for Collections (UMM-C) [OR2].
Figure 2 — Unified Metadata Model for Collections [OR2]
1.1. Design Approach and Rationale
This section is non-normative.
The response encoding defined in the current document satisfies the following design goals.
-
Feature-based GeoJSON model: The model maximises reuse of pre-existing standardized property names. Whereever possible, existing properties from the GeoJSON [NR2] and OWS Context [NR5] Feature objects are used for modeling EO Collection properties instead of proposing new property names. Existing properties are extended where needed (e.g., links).
-
Simplicity: This document does not describe the full information models or XML encodings referred to above. The original metadata models should be referred to for these details. This Best Practice 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 Best Practice to the OGC.
-
Convergence: A final design goal is to aim for future convergence of the proposed JSON-LD mapping with GeoDCAT-AP [OR15]. This requires future work.
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 was moved to the appendices.
-
Annex A defines the Abstract Test Suite for the specification.
-
Annex B includes normative JSON-LD @context definitions that allow interpreting the GeoJSON encoding as JSON-LD.
-
Annex C.1 presents the mapping of the properties proposed in this specification to the OGC 11-035r1 and UMM-C 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 file, and examples can be found in the OGC schema repository.
-
Annex G provides the revision history of this document.
2. Conformance
2.1. Conformance to base specifications
This section describes the compliance testing required for an implementation of this Best Practice.
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 site2.
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 Best Practice, an implementation shall implement all conformance classes specified in Annex A (normative).
Table 1 — Conformance classes related to data instances
Conformance Class | Description | Clause |
---|---|---|
conf/feature | Single EO Collection objects. | Section 7.1 |
conf/properties | Properties objects. | Section 7.1.1 |
conf/metadata-information | MetadataInformation objects | Section 7.2 |
conf/data-identification | DataIdentification objects | Section 7.3 |
conf/data-contact | DataContact objects | Section 7.3.2 |
conf/attribution | Attribution objects | Section 7.3.3 |
conf/activity | Activity objects | Section 7.3.6 |
conf/association | Association objects | Section 7.3.8 |
conf/plan | Plan objects | Section 7.3.9 |
conf/resource-constraints | ResourceConstraint objects | Section 7.4 |
conf/descriptive-keywords | DescriptiveKeywords objects | Section 7.5 |
conf/related-url | RelatedUrl objects | Section 7.6 |
conf/links | Links objects | Section 7.6.1 |
conf/offering | Offering objects | Section 7.6.3 |
conf/spatial-information | Spatial information objects | Section 7.7 |
conf/geometry | Geometry objects | Section 7.7.1 |
conf/temporal-information | TemporalInformation objects | Section 7.8 |
conf/acquisition-information | AcquisitionInformation | Section 7.9 |
conf/product-information | ProductInformation | Section 7.10 |
3. Normative references
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.
Hyperlinks to Normative References within this document will be listed as [NR*] and will map to below reference [*]. Bibliographic references will be labeled as [OR*] to map to the references in the bottom section.
3.1. Normative References
[1] The JavaScript Object Notation (JSON) Data Interchange Format, 2014, http://www.ietf.org/rfc/rfc7159.txt
[2] The GeoJSON Format, 2016, https://tools.ietf.org/html/rfc7946
[3] OGC OpenSearch-EO GeoJSON(-LD) Response Encoding Standard, 2020, http://docs.opengeospatial.org/is/17-047r1/17-047r1.html.
[4] OGC EO Dataset Metadata GeoJSON(-LD) Encoding Standard, 2020, http://docs.opengeospatial.org/is/17-003r2/17-003r2.html.
[5] OGC OWS Context GeoJSON Encoding, 2017, http://docs.opengeospatial.org/is/14-055r2/14-055r2.html
[6] OGC Web Services Common Standard, Version 2.0.0, 2010, http://portal.opengeospatial.org/files/?artifact_id=38867
[7] Uniform Resource Identifiers (URI): Generic Syntax, 2005, http://www.ietf.org/rfc/rfc3986.txt
[8] Internationalised Resource Identifiers (IRIs), 2005, https://tools.ietf.org/html/rfc3987
[9] Hypertext Transfer Protocol – HTTP/1.1, 1999 http://www.ietf.org/rfc/rfc2616.txt
[10] Web Linking, 2010, http://www.ietf.org/rfc/rfc5988.txt
[11] ECMAScript Language Specification, Edition 5.1, Standard ECMA-262, 2011, http://www.ecma-international.org/publications/standards/Ecma-262.htm
[12] The JSON Data Interchange Format, 2017, http://www.ecma-international.org/publications/files/ECMA-ST/ECMA-404.pdf
[13] A JSON-based Serialisation for Linked Data, W3C Recommendation, 2014, http://www.w3.org/TR/json-ld/
3.2. Bibliography
[1] Unified Metadata Model Common Elements, Version 1.10, 18/01/2018, https://wiki.earthdata.nasa.gov/display/CMR/CMR+Documents.
[2] Unified Metadata Model for Collections (UMM-C), Version 1.10, 18/01/2018, https://wiki.earthdata.nasa.gov/display/CMR/CMR+Documents.
[3] Dublin Core Metadata Initiative, DCMI Metadata Terms, 14/06/2012, http://dublincore.org/documents/dcmi-terms/.
[4] JSON-LD 1.0 Processing Algorithms and API, W3C Recommendation 16 January 2014, https://www.w3.org/TR/json-ld-api/
[5] OGC 12-084r2, OWS Context Atom Encoding Standard, 09/12/2013, http://docs.opengeospatial.org/is/12-084r2/12-084r2.html
[6] OGC 15-053, Implementing JSON/GeoJSON in an OGC Standard ER, Joan Masó.
[7] JSON Schema, https://tools.ietf.org/html/draft-zyp-json-schema-04
[8] RDF 1.1 Primer, W3C Working Group Note 25 February 2014, http://www.w3.org/TR/rdf11-primer/
[9] RDF 1.1 Concepts and Abstract Syntax, W3C Recommendation 25 February 2014, http://www.w3.org/TR/rdf11-concepts/
[10] RDF Schema 1.1, W3C Recommendation 25 February 2014, http://www.w3.org/TR/rdf-schema/
[11] RDF 1.1 XML Syntax, W3C Recommendation 25 February 2014, http://www.w3.org/TR/rdf-syntax-grammar/
[12] RDF 1.1 Turtle, Terse RDF Triple Language, W3C Recommendation 25 February 2014, http://www.w3.org/TR/turtle/
[13] Data Catalog Vocabulary (DCAT), W3C Recommendation 16 January 2014, https://www.w3.org/TR/vocab-dcat/.
[14] RFC 4287, The Atom Syndication Format, December 2005, https://tools.ietf.org/html/rfc4287
[15] GeoDCAT-AP: A geospatial extension to DCAT application profiles for data portals in Europe, Version 1.0.1, 02/08/2016, https://semiceu.github.io/GeoDCAT-AP/releases/1.0.1/geodcat-ap_1.0.1.pdf
[16] Google JSON Style Guide, Revision 0.9, https://google.github.io/styleguide/jsoncstyleguide.xml
[17] W3C vCard Ontology — for describing People and Organizations, W3C Interest Group Note 22 May 2014, http://www.w3.org/TR/vcard-rdf/
[18] GeoJSON-LD Vocabulary, http://geojson.org/geojson-ld/, http://geojson.org/geojson-ld/vocab.rdf
[19] OGC 11-035r1, EO Product Collection, Service and Sensor Discovery using the CS-W ebRIM Catalog, Version 1.0, 26/03/2013.
[20] FOAF Vocabulary Specification 0.99, Namespace Document 14 January 2014 – Paddington Edition, http://xmlns.com/foaf/spec/ .
[21] JSON-LD 1.1, “A JSON-based Serialisation for Linked Data”, W3C Proposed Recommendation, 07 May 2020, https://www.w3.org/TR/json-ld11/.
[22] OGC 08-167r2, Semantic Annotations in OGC Standards, Version 2.0, 10/10/2012, https://portal.opengeospatial.org/files/?artifact_id=47857.
[23] OGC 11-052r4, OGC GeoSPARQL – A Geographic Query Language for RDF Data, Version 1.0, https://portal.opengeospatial.org/files/?artifact_id=47664
[24] http://goessner.net/articles/JsonPath/index.html
[25] Data Catalog Vocabulary (DCAT) – Version 2, W3C Recommendation 04 February 2020, https://www.w3.org/TR/vocab-dcat/.
[26] ISO 19115:2003/Cor 1:2006, Geographic Information – Metadata – Implementation specification, http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=44361
[27] ISO 19139, Geographic Information – Metadata XML (ISO 19139:2007), http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=32557
[28] ISO 19139-2:2012, Geographic information — Metadata — XML schema implementation — Part 2: Extensions for imagery and gridded data, http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=57104
[29] Dublin Core Metadata Initiative term declarations represented in RDF schema language, http://dublincore.org/schemas/rdfs/.
[30] W3C PROV-O: The PROV Ontology, W3C Recommendation 30 April 2013, https://www.w3.org/TR/prov-o/
[31] SKOS Simple Knowledge Organization System Reference, W3C Recommendation 18 august 2009, http://www.w3.org/TR/skos-reference/.
[32] European Commission, ISA Programme, “ISA Programme Location Core Vocabulary,” 2015, http://www.w3.org/ns/locn#.
[33] Technical Guidance for the implementation of INSPIRE dataset and service metadata based on ISO/TS 19139:2007, Version 2.0.1, 2017-03-02, https://inspire.ec.europa.eu/id/document/tg/metadata-iso19139
4. Terms and definitions
For the purposes of this document, the following terms and definitions apply.
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 Best Practice.
For the purposes of this document, the following additional terms and definitions apply.
4.1.
compaction
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 [OR4].
4.2.
collection
A Collection or a Dataset Series (in short Series) defines a container for a list of Products (or datasets) that have common properties. Products inherit all the Collection properties that are not explicitly overridden.
4.3.
context
A set of rules for interpreting a JSON-LD document as specified in the section “The Context” of the JSON-LD specification [NR13].
4.4.
dataset
Observations obtained by satellite instruments (OGC 10-140). See granule and product.
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].
4.6.
embedding
Embedding is a JSON-LD feature that allows using node objects as property values [NR13].
4.7.
expansion
The algorithm that removes [JSON-LD] context is called expansion [OR4].
4.8.
fatal exception
A server supplies exceptions (diagnostics) in the response as appropriate. A diagnostics is fatal or non-fatal. A fatal diagnostic is generated when the execution of the request cannot proceed and no results are available. For example, if the client supplied an invalid query there might be nothing that the server can do. A non-fatal diagnostic is one where processing may be affected but the server can continue (See section 2.9 of [OR2]).
4.9.
GeoJSON
A geospatial data interchange format based on Javascript Object Notation (JSON) [NR2].
4.10.
identifier
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
A lightweight, text-based, language-independent data interchange format, based on the Javascript programming language.
4.12.
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 [OR7].
4.13.
Product
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.14.
Range (RDF)
Range (rdfs:range) is used to state that values of a property are instances of one or more classes [OR10].
4.15.
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].
4.16.
service interface
Shared boundary between an automated system or human being and another automated system or human being [ISO 19101].
5. Conventions
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 |
HTTP | HyperText Transfer Protocol |
IRI | Internationalised Resource Identifier |
ISO | International Organisation for Standardisation |
JSON | JavaScript Object Notation |
JSON-LD | JavaScript Object Notation for Linked Data |
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 |
SI | International System of Units (French: Système international d’unités) |
SRU | Search/Retrieval via URL |
UML | Unified Modeling Language |
UMM | Unified Metadata Model |
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. Symbols
5.2.1. Symbols and abbreviated terms
The schema diagrams3 included in the document show the JSON structure expressed in JSON Schema [OR7] and documented in Annex E.1.
Table 2 — JSON Schema diagram symbols
JSON Schema Entity | Representation | Description |
---|---|---|
Definition |
| Definitions are shown as blue rectangles with solid borders. |
Mandatory property |
| Mandatory properties are shown with solid borders. |
Optional property |
| 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 definition. |
Pattern property |
| A pattern property defines the property’s name as a regular expression. There are no minimum or maximum occurrence settings for a pattern property. |
Unspecified property |
| A property can be implicitly specified by adding a suitable pattern property or property wildcard. |
“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 these sub-schemas. |
“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. |
Subschema (definitions) |
| The “Def” attribute inside a rectangle representing a (Sub) Schema refers to the corresponding Object definition. |
5.2.2. Symbols and abbreviated terms
The data dictionary tables in the current document use the JSONPath notation [OR24]. A brief overview of this notation is included in the table below which is taken from [OR24].
XPath | JSONPath | Description |
---|---|---|
/ | $ | the root object/element |
. | @ | the current object/element |
/ | . or [] | child operator |
// | .. | recursive descent. JSONPath borrows this syntax from E4X. |
* | * | wildcard. All objects/elements regardless their names. |
[] | [] | subscript operator. XPath uses it to iterate over element collections and for predicates. In Javascript and JSON it is the native array operator. |
| | [,] | 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 3 — Namespace abbreviations
5.4. Layout and identifiers
The normative provisions in the current document are denoted by the URI http://www.opengis.net/spec/eoc-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.
5.5. Style
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.”
6. Overview
This specification defines a GeoJSON-based [NR2] serialization syntax for Earth Observation Collection Metadata that conforms to a subset of [NR13] syntax constraints but does not require JSON-LD processing. While other serialization forms are possible, such alternatives are not discussed by 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, similar to GeoJSON, the JSON encoding described in this Best Practice features a “type” property on each JSON object.
An EO Collection Metadata Document conforming to this Best Practice is a GeoJSON document whose root value is a Feature object, and whose MIME media type corresponds to one of the media types described in chapter 9. The Feature object may or may not be part of a FeatureCollection representing an OpenSearch response document according to OGC 17-047r1 [NR3].
6.1. JavaScript Object Notation
JavaScript Object Notation (JSON) is a lightweight, text-based, language-independent data interchange format that defines a small set of formatting rules for the portable representation of structured data. JSON is derived from the object literals of JavaScript, as defined in the ECMAScript Programming Language Standard [NR11] and can represent four primitive types (strings, numbers, boolean values, and null) and two structured types (objects and arrays). The ordering of the members or properties of any JSON object is considered irrelevant. Even though JSON is based on a subset of the JavaScript Programming Language it is currently well supported by nearly all programming languages, including Java, Python, and C#.
The JSON format is currently described by two competing standards, RFC7159 [NR1] and ECMA-404 [NR12]. 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: Feature
Requirement Class: Feature | |
---|---|
/req/feature | |
Target Type | Data instance |
Dependency | JSON [NR1] |
Dependency | GeoJSON [NR2] |
Dependency | /req/geometry |
Dependency | /req/properties |
Requirement 1: | /req/feature/properties |
Requirement 1: | |
---|---|
/req/feature/properties | |
A “Feature” object representing an EO Collection shall implement the properties shown in Table 4, with the value matching the type shown, and with the obligation shown. |
The Feature object represents the EO Collection (a.k.a. EO Dataset Series). It 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.