Open Geospatial Consortium |
Submission Date: <yyyy-mm-dd> |
Approval Date: <yyyy-mm-dd> |
Publication Date: <yyyy-mm-dd> |
External identifier of this OGC® document: http://www.opengis.net/doc/is/rem/1.0.0-draft.1 |
Internal reference number of this OGC® document: 21-001 |
Version: 1.0.0-draft.1 |
Category: OGC® Implementation Specification |
Editor: Clemens Portele, Ignacio Correas |
OGC Route Exchange Model |
Copyright notice |
Copyright © 2025 Open Geospatial Consortium |
To obtain additional rights of use, visit http://www.opengeospatial.org/legal/ |
Warning |
This document is not an OGC Standard. This document is distributed for review and comment. This document is subject to change without notice and may not be referred to as an OGC Standard.
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.
Document type: OGC® Standard |
Document subtype: if applicable |
Document stage: Draft |
Document language: English |
License Agreement
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.
- 1. Scope
- 2. Conformance
- 3. References
- 4. Terms and Definitions
- 5. Conventions
- 6. Overview of the Route model
- 7. Route Exchange Model
- 8. Media Types
- Annex A: Abstract Test Suite (Normative)
- A.1. Conformance Class "Route Exchange Model"
- A.1.1. Conformance Test 1
- A.1.2. Conformance Test 2
- A.1.3. Conformance Test 3
- A.1.4. Conformance Test 4
- A.1.5. Conformance Test 5
- A.1.6. Conformance Test 6
- A.1.7. Conformance Test 7
- A.1.8. Conformance Test 8
- A.1.9. Conformance Test 9
- A.1.10. Conformance Test 10
- A.1.11. Conformance Test 11
- A.1.12. Conformance Test 12
- A.1.13. Conformance Test 13
- A.1.14. Conformance Test 14
- A.1.15. Conformance Test 15
- A.1.16. Conformance Test 16
- A.1.17. Conformance Test 17
- A.1. Conformance Class "Route Exchange Model"
- Annex B: JSON Schema (Normative)
- Annex C: Example (Informative)
- Annex D: Revision History
- Annex E: Bibliography
i. Abstract
The Route Exchange Model represents a route as a JSON document in a standardized way that is independent of the underlying data, routing engine software, and algorithms that are used to compute the route.
For example, the complementary standard OGC API - Routes - Part 1: Core uses the Route Exchange Model to represent and share routes with users on the web.
For providers of routes, the API building blocks and the Route Exchange Model provide a simple model to publish and offer those routes as resources for use by other systems.
For users, applications, and enterprises, the capability to get routes in a common format, regardless of the underlying routing data, engines, or algorithms, represents a significant step forward in geospatial interoperability.
ii. Keywords
The following are keywords to be used by search engines and document catalogues.
OGC, Routing, Routing API, Route Exchange Model
iii. Preface
The work on this Standard started in the OGC Open Routing Pilot. After the pilot, the work on the specification continued in the OGC Routing Standards Working Group.
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. Submitting organizations
The following organizations submitted this Document to the Open Geospatial Consortium (OGC):
-
US Army Geospatial Center (AGC)
-
Ecere Corporation
-
interactive instruments GmbH
-
Skymantics LLC
v. Submitters
All questions regarding this submission should be directed to the editor or the submitters:
| Name | Affiliation |
|---|---|
Clemens Portele (editor) |
interactive instruments GmbH |
Jeff Harrison |
US Army Geospatial Center (AGC) |
Amy Youmans |
US Army Geospatial Center (AGC) |
Jérôme Jacovella-St-Louis |
Ecere Corporation |
Ignacio Correas |
Skymantics LLC |
1. Scope
This document specifies the Route Exchange Model (REM).
The REM is a GeoJSON representation of a route, independent of the underlying routing data set, routing engine or algorithm.
2. Conformance
This Standard defines one requirements / conformance class:
The standardization target of the conformance class is JSON.
Conformance with this Standard shall be checked using all the relevant tests specified in Annex A (normative) 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 web site.
| Conformance class | URI |
|---|---|
|
3. 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.
-
Internet Engineering Task Force (IETF). RFC 3339: Date and Time on the Internet: Timestamps [online]. Edited by G. Klyne, C. Newman. 2002 [viewed 2020-03-16]. Available at http://tools.ietf.org/rfc/rfc3339.txt
-
Internet Engineering Task Force (IETF). RFC 7946: The GeoJSON Format [online]. Edited by H. Butler, M. Daly, A. Doyle, S. Gillies, S. Hagen, T. Schaub. 2016 [viewed 2020-03-16]. Available at http://tools.ietf.org/rfc/rfc7946.txt
4. Terms and Definitions
This document used 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 standard 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.
- action
-
a predefined operation, task, or activity assigned to a specific waypoint along a route, to be performed when reaching or interacting with that location, regardless of the type of the route(such as walking, cycling, driving, autonomous vehicle, etc).
|
Note
|
Actions can include a range of activities relevant to the purpose of the journey and context of the route. Examples of actions include, but are not limited to: changing speed, taking a photo, delivering a package, buying tickets, starting a guided tour, having lunch, or pausing for a rest. Actions may require interacting with a physical location (e.g., purchasing an entry ticket at a museum waypoint), performing a digital task (e.g., checking in via an app), or initiating vehicle, equipment, or sensor operations (e.g., activating a camera at a scenic viewpoint, unloading cargo at a delivery point). |
- contingency
-
a predefined alternative plan or course of action developed to address specific events or changes in the conditions during a trip along a route.
|
Note
|
Contingencies ensure that an autonomous vehicle or a vehicle operator can respond effectively to situations such as changes in traffic conditions, equipment malfunctions, loss of communication, environmental hazards, etc. They are particularly useful for autonomous vehicles and support the safe and effective execution of a trip. Contingencies are specific procedures or adaptations that can be executed, if the original plan for the trip is disrupted, allowing the continuation of the trip, or, alternatively, its abort or return as needed. |
- feature
-
abstraction of real world phenomena [ISO 19101-1:2014]
- GeoJSON
-
geospatial data interchange format based on JavaScript Object Notation (JSON) [IETF RFC 7946]
- mode
-
a configurable setting selected by the operator and provided as an input to the planning server that determines the operational profile and planning parameters for an autonomous vehicle’s plan.
|
Note
|
Modes specify the purpose of the mission (such as survey, delivery, or patrol) or adapt planning for the characteristics and requirements of a particular vehicle type (such as pedestrian, bicycle, or aerial vehicle). The selected mode influences how the planning server generates the plan, including which behaviors, constraints, and priorities to use during route and action generation. For example, in “parking mode” or “highway mode,” the planning algorithms and resource allocations are optimized differently to meet the needs of each mission context. Operators select the appropriate mode based on mission objectives or the type of vehicle, ensuring the plan is safe, efficient, and tailored to the operating scenario. Modes enable the planning system to flexibly support a wide range of autonomous vehicle applications with context-appropriate strategies. |
- route
-
sequence of connected segments providing directions to travel between specific waypoints
|
Note
|
This definition doesn’t use the definition from ISO 19134:2007 because of use of terms such as "links" and "network". |
- waypoint
-
location that plays a role in choosing candidate routes potentially satisfying a routing request [ISO 19133:2005]
- Web API
-
API using an architectural style that is founded on the technologies of the Web [OGC API - Features - Part 1: Core]
5. Conventions
This section provides details and examples for any conventions used in the document.
5.1. Identifiers
The normative provisions in this Standard are denoted by the URI
http://www.opengis.net/spec/rem/1.0.0-draft.1
All requirements and conformance tests that appear in this document are denoted by partial URIs which are relative to this base.
|
Note
|
The URI is temporary during the development of this specification. The final URI in the published standard will be http://www.opengis.net/spec/rem/1.0.
|
5.2. JSON schema
This document uses JSON Schema to document the syntax of the Route Exchange Model.
The complete schema is available in JSON schema of the Route Exchange Model in GeoJSON.
5.3. Units of measure
The Route Exchange Model uses fixed units for properties with a unit of measure to avoid that all clients must be able to convert between various units. Examples are the length of a segment or route (meter), the expected duration to travel along a segment or route (seconds), or the weight (metric ton) or height (meter) restriction. An exception is speed where the information should match the information on the road signs and which are therefore either in kmph or mph.
A client can present the information to the user using the perferred units of the user.
6. Overview of the Route model
6.1. Scenarios
The Route model is driven by three routing scenarios. These were:
-
Online - fully connected with stability
-
Intermittent - unreliable connection
-
Offline - no connectivity
6.1.1. Online scenario
In the Online scenario, an operator uses a routing client to request a route from a Routing API provider, which in turn retrieves the route from an online routing engine. In this scenario all components have consistent connections between them and out to the wider internet.
This scenario uses OGC API Routes for all request and response handling between the client and the routing infrastructure.
6.1.2. Intermittent scenario
The intermittent scenario is where the components have connectivity, but it is not necessarily consistent, stable, reliable, or high-speed.
Therefore, the network cannot be relied upon to provide connectivity on demand and compensation actions are likely when connectivity is not available. Intermittent connectivity is unpredictable and it maybe that in the real-world, decisions are made to treat intermittent connectivity as no connectivity, as it is the only sensible course of action, especially if the scenario involves threat to life.
For example, only one of the clients had access to a routing engine. Therefore, the connected client had the ability to create routes, but other clients cannot. If the clients are able to communicate with each other via some other means (Bluetooth or some other peer-to-peer communication, for example), the clients could still share pre-defined routes, that is, the routing operation has been completed when a connection to the routing engine was established, but has now been lost.
Another approach to support in particular low-bandwidth situations is to not transmit the complete route definition to the client, but to return route information segment by segment as the vehicle moves along the route. This approach is not supported by this standard and might be added in a future extension or revision.
6.1.3. Offline scenario
The Offline scenario assumes that there is no connectivity outside of a device’s local network, this could be a desktop computer, mobile device or a mesh. In the real-world the scenario is modeling an instance where there is no connectivity and there is not going to be any connectivity for the duration of an operation.
An operator uses the routing functionality provided by the client to create a route. The operator then shares this route with other local clients using the route exchange model. To enable the required functionality, all of the capability has to be tightly coupled in a single location. Practically, this involves installing all of the components on the same machine to remove communication dependencies with the wider network.