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
Resource | Path | HTTP Method | Document Reference |
---|---|---|---|
Collections metadata | /collections | GET, POST | Resource Collections |
Collection instance metadata | /collections/{collectionId} | GET, DELETE, PUT | Resource Collection |
MovingFeatures | /collections/{collectionId}/items | GET, POST | Resource MovingFeatures |
MovingFeature instance | /collections/{collectionId}/items/{mFeatureId} | GET, DELETE | Resource MovingFeature |
TemporalGeometrySequence | /collections/{collectionId}/items/{mFeatureId}/tgsequence | GET, POST | Resource TemporalGeometrySequence |
TemporalPrimitiveGeometry instance | /collections/{collectionId}/items/{mFeatureId}/tgsequence/{tGeometryId} | DELETE | Resource TemporalPrimitiveGeometry |
Queries for TemporalPrimitiveGeometry | collections/{collectionId}/items/{mFeatureId}/tgsequence/{tGeometryId}/{queryType} | GET | TemporalGeometry Query Resources |
TemporalProperties | /collections/{collectionId}/items/{mFeatureId}/tproperties | GET, POST | Resource TemporalProperties |
TemporalProperty instance | /collections/{collectionId}/items/{mFeatureId}/tproperties/{tPropertyId} | GET, POST, DELETE | Resource TemporalProperty |
TemporalPrimitiveValue instance | /collections/{collectionId}/items/{mFeatureId}/tproperties/{tPropertyId}/{tValueId} | DELETE | Resource TemporalProperty |
II. Keywords
The following are keywords to be used by search engines and document catalogues.
ogcdoc, OGC document, OGC Moving Features, OGC Moving Features JSON, Moving Features Access, API, OpenAPI, REST, trajectory
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.
IV. Security considerations
The OGC API — Moving Features — Part 1: Core Standard does not mandate any specific security controls. However, it was designed to support addition of security controls without impacting conformance, in a similar way to the OGC API — Common — Part 1: Core Standard.
This document therefore applies Requirement /req/oas30/security of OGC API — Common — Part 1: Core for OpenAPI 3.0 support of security controls.
V. Submitting Organizations
The following organizations submitted this Document to the Open Geospatial Consortium (OGC):
- Artificial Intelligence Research Center, National Institute of Advanced Industrial Science and Technology
- Université libre de Bruxelles
- Geomatys
- Central Research Laboratory, Hitachi Ltd.
- Feng Chia University
VI. Submitters
All questions regarding this submission should be directed to the editor or the submitters:
Name | Organization |
---|---|
Taehoon KIM | Artificial Intelligence Research Center, National Institute of Advanced Industrial Science and Technology |
Kyoung-Sook KIM | Artificial Intelligence Research Center, National Institute of Advanced Industrial Science and Technology |
Mahmoud SAKR | Université libre de Bruxelles |
Esteban Zimanyi | Université libre de Bruxelles |
Martin Desruisseaux | Geomatys |
Akinori Asahara | Central Research Laboratory, Hitachi Ltd. |
Chen-Yu Hao | Feng Chia University |
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.
First, to provide access to representations of Moving Features that conform to the OGC Moving Features JSON Encoding Standard.
Second, to provide functionality comparable to that of the OGC Moving Features Access Standard.
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 class | URI |
---|---|
MovingFeatures Collection Catalog | http://www.opengis.net/spec/ogcapi-movingfeatures-1/1.0/conf/mf-collection |
MovingFeatures | http://www.opengis.net/spec/ogcapi-movingfeatures-1/1.0/conf/movingfeatures |
Common Requirements | http://www.opengis.net/spec/ogcapi-movingfeatures-1/1.0/conf/common |
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.
5.1. Identifiers
The normative provisions in this Standard are denoted by the URI
http://www.opengis.net/spec/ogcapi-movingfeatures-1/1.0
All requirements and conformance tests that appear in this document are denoted by partial URIs which are relative to this base.
5.2. Use of HTTPS
For simplicity, this OGC Standard only refers to the HTTP protocol. This is not meant to exclude the use of HTTPS. This is simply a shorthand notation for “HTTP or HTTPS”. In fact, most servers are expected to use HTTPS and not HTTP.
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
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.
6.2. Search
The core search capability is based on OGC API — Common and thus supports:
bounding box searches,
time instant or time period searches, and
equality predicates (i.e. property=value).
OGC API — Moving Features extends these core search capabilities to include:
spatiotemporal queries for accessing TemporalGeometry resources.
6.3. Dependencies
The OGC API — Moving Features Standard is an extension of the OGC API — Common and the OGC API — Features Standards. Therefore, an implementation of OGC API — Moving Features shall first satisfy the appropriate Requirements Classes from OGC API — Common and OGC API — Features. Also, the OGC API — Moving Features Standard is based on the OGC Moving Features Encoding Extension — JSON Standard (OGC MF-JSON). Therefore, an implementation of OGC API — Moving Features shall satisfy the appropriate Requirements Classes from OGC MF-JSON. Table 4 identifies the OGC API — Common and OGC API — Features Requirements Classes which are applicable to each section of this Standard. Instructions on when and how to apply these Requirement Classes are provided in each section.
Table 4 — Mapping OGC API — Moving Features Sections to OGC API — Common, OGC API — Features, and OGC MF-JSON Requirements Classes
API — MF Section | API — MF Requirements Class | API — Common, API — Features, MF-JSON Requirements Class |
---|---|---|
Collections | /req/mf-collection | http://www.opengis.net/spec/ogcapi-common-2/1.0/req/collections, http://www.opengis.net/spec/ogcapi-features-4/1.0/req/create-replace-delete |
MovingFeatures | /req/movingfeatures | http://www.opengis.net/spec/ogcapi-features-1/1.0/req/core, http://www.opengis.net/spec/ogcapi-features-4/1.0/req/create-replace-delete, http://www.opengis.net/spec/movingfeature |