I.  Abstract

Moving feature data can represent various phenomena, including vehicles, people, animals, weather patterns, etc. The OGC API — Moving Features Standard defines a standard interface for querying and accessing geospatial data that changes over time, such as the location and attributes of moving objects like vehicles, vessels, or pedestrians. The API specified in this Standard provides a way to manage data representing moving features, which can be helpful for applications in domains such as transportation management, disaster response, and environmental monitoring. This Standard also specifies operations for filtering, sorting, and aggregating moving feature data based on location, time, and other properties. The OGC API — Moving Features — Part 1: Core Standard specifies a set of RESTful interfaces and data formats for querying and updating moving feature data over the web. The Standard is part of the OGC API family of Standards and makes use of the OpenAPI Specification. OGC API Standards define modular API building blocks that spatially enable Web APIs in a consistent way. OpenAPI is used to define the reusable API building blocks with responses in JSON and HTML.

The OGC API family of standards is organized by resource type.

Table 1 — Overview of Resources

III.  Preface

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.

1.  Scope

The scope of the OGC API — Moving Features — Part 1: Core Standard is to provide a uniform way to access, communicate, and manage data about moving features across different applications, data providers, and data consumers in contexts where the effects of Einstein’s relativity are not significant. The Standard defines a set of API building blocks that enable clients to discover, retrieve, and update information about moving features, as well as a data model for describing moving features and their trajectories.

The OGC API — Moving Features — Part 1: Core Standard defines an API with two goals.

The OGC API — Moving Features Standard is an extension of the OGC API — Common and the OGC API — Features Standards.

2.  Conformance

This Standard defines multiple requirements classes and conformance classes that describe different levels of conformance to the Standard. These requirements / conformance classes help to ensure interoperability between separate implementations of the Standard and enable data providers to specify which parts of the Standard they support. The standardization targets are “Web APIs”.

The conformance classes specified in this Standard are:

The conformance class defines the minimum requirements for an API to be compliant with the OGC API — Moving Features Standard. This includes support for querying and retrieving information about moving features using HTTP GET requests. Also, the conformance class enables clients to add, modify, or delete features from the server using HTTP POST, PUT, and DELETE requests. Lastly, the conformance class adds support for querying and retrieving features based on their temporal characteristics, such as their position at a specific time or their velocity over a given time interval.

Implementers of the OGC API — Moving Features can choose which conformance classes they want to support based on the specific needs of their use case and the capabilities of their software. However, to be considered compliant with the Standard, an implementation shall support all the conformance classes listed in Table 2.

The URIs of the associated conformance classes are:

Table 2 — Conformance class URIs

Conformance with this Standard shall be checked using all the relevant tests specified in Annex A of this document. The framework, concepts, and methodology for testing, and the criteria to be achieved to claim conformance are specified in the OGC Compliance Testing Policies and Procedures and the OGC Compliance Testing website. The schemas and example API definition documents specified in this Standard can be found in the OGC Schema Repository.

3.  Normative references

The following documents are referred to in the text in such a way that some or all of their content constitutes requirements of this document. For dated references, only the edition cited applies. For undated references, the latest edition of the referenced document (including any amendments) applies.

Policy SWG: OGC 08-131r3, The Specification Model — Standard for Modular specifications. Open Geospatial Consortium (2009).

Hideki Hayashi, Akinori Asahara, Kyoung-Sook Kim, Ryosuke Shibasaki, Nobuhiro Ishimaru: OGC 16-120r3, OGC Moving Features Access. Open Geospatial Consortium (2017). http://www.opengis.net/doc/is/movingfeatures-access/1.0.0.

Kyoung-Sook KIM, Nobuhiro ISHIMARU: OGC 19-045r3, OGC Moving Features Encoding Extension — JSON. Open Geospatial Consortium (2020). http://www.opengis.net/doc/IS/mf-json/1.0.0.

Clemens Portele, Panagiotis (Peter) A. Vretanos, Charles Heazel: OGC 17-069r4, OGC API — Features — Part 1: Core corrigendum. Open Geospatial Consortium (2022). http://www.opengis.net/doc/IS/ogcapi-features-1/1.0.1.

Charles Heazel: OGC 19-072, OGC API — Common — Part 1: Core. Open Geospatial Consortium (2023). http://www.opengis.net/doc/is/ogcapi-common-1/1.0.0.

Charles Heazel: OGC API — Common — Part 2: Geospatial Data (Draft). OGC 20-024, Open Geospatial Consortium, http://docs.ogc.org/DRAFTS/20-024.html

Panagiotis A. Vretanos, Clemens Portele: OGC API — Features — Part 4: Create, Replace, Update and Delete (Draft). http://docs.ogc.org/DRAFTS/20-002.html

E. Levinson: IETF RFC 2387, The MIME Multipart/Related Content-type. RFC Publisher (1998). https://www.rfc-editor.org/info/rfc2387.

E. Rescorla: IETF RFC 2818, HTTP Over TLS. RFC Publisher (2000). https://www.rfc-editor.org/info/rfc2818.

G. Klyne, C. Newman: IETF RFC 3339, Date and Time on the Internet: Timestamps. RFC Publisher (2002). https://www.rfc-editor.org/info/rfc3339.

T. Berners-Lee, R. Fielding, L. Masinter: IETF RFC 3986, Uniform Resource Identifier (URI): Generic Syntax. RFC Publisher (2005). https://www.rfc-editor.org/info/rfc3986.

R. Fielding, J. Reschke (eds.): IETF RFC 7230, Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing. RFC Publisher (2014). https://www.rfc-editor.org/info/rfc7230.

R. Fielding, J. Reschke (eds.): IETF RFC 7231, Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content. RFC Publisher (2014). https://www.rfc-editor.org/info/rfc7231.

R. Fielding, J. Reschke (eds.): IETF RFC 7232, Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests. RFC Publisher (2014). https://www.rfc-editor.org/info/rfc7232.

R. Fielding, Y. Lafon, J. Reschke (eds.): IETF RFC 7233, Hypertext Transfer Protocol (HTTP/1.1): Range Requests. RFC Publisher (2014). https://www.rfc-editor.org/info/rfc7233.

R. Fielding, M. Nottingham, J. Reschke (eds.): IETF RFC 7234, Hypertext Transfer Protocol (HTTP/1.1): Caching. RFC Publisher (2014). https://www.rfc-editor.org/info/rfc7234.

R. Fielding, J. Reschke (eds.): IETF RFC 7235, Hypertext Transfer Protocol (HTTP/1.1): Authentication. RFC Publisher (2014). https://www.rfc-editor.org/info/rfc7235.

M. Nottingham, E. Wilde: IETF RFC 7807, Problem Details for HTTP APIs. RFC Publisher (2016). https://www.rfc-editor.org/info/rfc7807.

H. Butler, M. Daly, A. Doyle, S. Gillies, S. Hagen, T. Schaub: IETF RFC 7946, The GeoJSON Format. RFC Publisher (2016). https://www.rfc-editor.org/info/rfc7946.

M. Nottingham: IETF RFC 8288, Web Linking. RFC Publisher (2017). https://www.rfc-editor.org/info/rfc8288.

T. Bray (ed.): IETF RFC 8259, The JavaScript Object Notation (JSON) Data Interchange Format. RFC Publisher (2017). https://www.rfc-editor.org/info/rfc8259.

Open API Initiative: OpenAPI Specification 3.0.3, https://github.com/OAI/OpenAPI-Specification/blob/main/versions/3.0.3.md

4.  Terms and definitions

This document uses the terms defined in OGC Policy Directive 49, 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 document and OGC documents do not use the equivalent phrases in the ISO/IEC Directives, Part 2.

This document also uses terms defined in the OGC Standard for Modular specifications (OGC 08-131r3), also known as the ‘ModSpec’. The definitions of terms such as standard, specification, requirement, and conformance test are provided in the ModSpec.

For the purposes of this document, the following additional terms and definitions apply.

one of a sequence of numbers designating the position of a point
Note 1 to entry: In a spatial coordinate reference system, the coordinate values are qualified by units.
[source: ISO 19111]

coordinate system that is related to an object by a datum
Note 1 to entry: Geodetic and vertical datums are referred to as reference frames.
Note 2 to entry: For geodetic and vertical reference frames, the object will be the Earth. In planetary applications, geodetic and vertical reference frames may be applied to other celestial bodies.
[source: ISO 19111]

collection of data, published or curated by a single agent, and available for access or download in one or more formats
[source: DCAT]

specification of a value domain with operations allowed on values in this domain
Examples: Integer, Real, Boolean, String and Date.
Note 1 to entry: Data types include primitive predefined types and user definable types.
[source: ISO 19103]

represents an accessible form of a dataset
Note 1 to entry: EXAMPLE: a downloadable file, an RSS feed or a web service that provides the data.
[source: DCAT]

characteristic of a feature in which its value varies with time
[source: OGC 19-045r3]

abstraction of a real-world phenomena
Note 1 to entry: A feature can occur as a type or an instance. Feature type or feature instance should be used when only one is meant.
[source: ISO 19101-1:2014]

characteristic of a feature
Note 1 to entry: A feature attribute can occur as a type or an instance. Feature attribute type or feature attribute instance is used when only one is meant.
[source: ISO 19101‑1:2014]

table where the columns represent feature attributes, and the rows represent features
[source: OGC 06-104r4]

representation of real-world phenomenon associated with a location relative to the Earth
[source: ISO 19101-2]

spatial object representing a geometric set
[source: ISO 19107:2003]

<one parameter set of geometries>
geometry at a particular value of the parameter
[source: ISO 19141]

feature whose position changes over time
Note 1 to entry: Its base representation uses a local origin and local coordinate vectors of a geometric object at a given reference time. [source: ISO 19141]
Note 2 to entry: The local origin and ordinate vectors establish an engineering coordinate reference system (ISO 19111), also called a local frame or a local Euclidean coordinate system.[source: ISO 19141]
[source: OGC 19-045r3]

facet or attribute of an object referenced by a name
[source: ISO 19143]

entity that might be identified
Note 1 to entry: The term “resource”, when used in the context of an OGC Web API standard, should be understood to mean a web resource unless otherwise indicated.
[source: Dublin Core Metadata Initiative — DCMI Metadata Terms]

a type of resource
Note 1 to entry: Resource types are re-usable components that are independent of where the resource resides in the API.
[source: OGC 19-072]

path of a moving point described by a one parameter set of points
[source: ISO 19141]

API using an architectural style that is founded on the technologies of the Web
[source: W3C Data on the Web Best Practices]

a resource that is identified by a URI
[source: OGC 17-069r4]

5.  Conventions

This section provides details and examples for any conventions used in the document. Examples of conventions are symbols, abbreviations, use of schema, or special notes regarding how to read the document.

6.  Overview

6.1.  General

The OGC API — Moving Features Standard extends both the OGC API — Features Standard and the OGC API — Common Standard. The OGC API — Features Standard enables access to resources using the HTTP protocol and its associated operations (GET, PUT, POST, DELETE, etc.). The OGC API — Common Standard defines a set of capabilities that are applicable to all implementations of OGC API Standards. Other OGC API Standards extend OGC API — Common with capabilities specific to a resource type.

The OGC API — Moving Features — Part 1: Core Standard defines an API with the goal of:

• Providing a standard interface for creating (HTTP POST), retrieving (HTTP GET), updating (HTTP PUT), and deleting (HTTP DELETE) Moving Features, with conformance to the OGC Moving Features JSON Encoding Standard (OGC 19-045r3).

Resources exposed through an implementation of an OGC API Standard may be accessed via a Uniform Resource Identifier (URI). The URI representation in this Standard is composed of three sections:

• Dataset distribution API: The endpoint corresponding to a dataset distribution, where the landing page resource as defined in OGC API — Common — Part 1: Core is available (subsequently referred to as Base URI or {root}).

• Access Paths: Unique paths to Resources.

• Query Parameters: Parameters to adjust the representation of a Resource or Resources like encoding format or sub-setting.

Access Paths are used to build resource identifiers. This approach is recommended, but not required. Most resources are also accessible through links to previously accessed resources. Unique relation types are used for each resource.

Table 3 summarizes the access paths and relation types defined in this Standard.

Table 3 — Moving Features API Paths

Path Template	Relation	Resource
Collections
{root}/collections	data	Metadata describing the Collection Catalog of data available from this API.
{root}/collections/{collectionId}		Metadata describing the Collection Catalog of data which has the unique identifier {collectionId}
MovingFeatures
{root}/collections/{collectionId} /items	items	Static information of MovingFeature about available items in the specified Collection
{root}/collections/{collectionId}/items/{mFeatureId}	item	Static information describing the MovingFeature data which has the unique identifier {mFeatureId}
{root}/collections/{collectionId}/items/{mFeatureId}/tgsequence	items	Sequence of TemporalPrimitiveGeometry about available items in the specified MovingFeature
{root}/collections/{collectionId}/items/{mFeatureId}/tgsequence/{tGeometryId}	item	Temporal object describing the TemporalPrimitiveGeometry of data which has the unique identifier {tGeometryId}
{root}/collections/{collectionId}/items/{mFeatureId}/tgsequence/{tGeometryId}/{queryType}		Identifies an Information Resource of type {queryType} associated with the TemporalPrimitiveGeometry instance
{root}/collections/{collectionId}/items/{mFeatureId}/tproperties	items	Temporal object information of TemporalProperties about available items in the specified MovingFeature
{root}/collections/{collectionId}/items/{mFeatureId}/tproperties/{tPropertyName}	item	Temporal object describing the TemporalProperty of data which has the unique identifier {tPropertyName}
{root}/collections/{collectionId}/items/{mFeatureId}/tproperties/{tPropertyName}/{tValueId}	item	Temporal object describing the TemporalPrimitiveValue of data which has the unique identifier {tValueId}

Where:

• {root} = Base URI for the API server

• {collectionId} = An identifier for a specific Collection of data

• {mFeatureId} = An identifier for a specific MovingFeature of a specific Collection of data

• {tGeometryId} = An identifier for a specific TemporalPrimitiveGeometry of a specific MovingFeature of data

• {tPropertyName} = An identifier for a specific TemporalProperty of a specific MovingFeatures of data

• {tValueId} = An identifier for a specific TemporalPrimitiveValue of a specific TemporalProperty of data

• {quertyType} = An identifier for the query pattern performed by an implementation instance of the OGC API — Moving Features Standard.

 

Figure 1 — Class diagram for OGC API — Moving Features

Figure 1 shows a Unified Modeling Language (UML) class diagram for OGC API — Moving Features which represents the basic resources of this Standard, such as Collections, Collection, MovingFeatures, MovingFeature, TemporalGeometrySequence, TemporalPrimitiveGeometry, TemporalProperties, TemporalProperty, and TemporalPrimitiveValue. In this Standard, a single moving feature can have temporal geometries, such as a set of trajectories. Also, a moving feature can have multiple temporal properties, and each property can have a set of parametric values.