Corrigenda

The following table identifies all corrections that have been applied to this CFP compared to the original release. Minor editorial changes (spelling, grammar, etc.) are not included.

Section Description

no entries

Clarifications

The following table identifies all clarifications that have been provided in response to questions received from organizations interested in this CFP.

Question Clarification

no entries

Abbreviations

The following table lists all abbreviations used in this CFP.

CFP

Call for Participation

CR

Change Request

DER

Draft Engineering Report

DWG

Domain Working Group

ER

Engineering Report

GPKG

GeoPackage

IP

Innovation Program

OGC

Open Geospatial Consortium

ORM

OGC Reference Model

OWS

OGC Web Services

PA

Participation Agreement

POC

Point of Contact

Q&A

Questions and Answers

RM-ODP

Reference Model for Open Distributed Processing

SOW

Statement of Work

SWG

Standards Working Group

TBD

To Be Determined

TC

OGC Technical Committee

TEM

Technical Evaluation Meeting

TIE

Technology Integration / Technical Interoperability Experiment

URL

Uniform Resource Locator

WFS

Web Feature Service

WPS

Web Processing Service

WG

Working Group (SWG or DWG)

1. Introduction

The Open Geospatial Consortium (OGC®) is releasing this Call for Participation ("CFP") to solicit proposals for the OGC Open Routing API Pilot 2019 Initiative ("Initiative", "Pilot", or "Routing Pilot"). The goal of the pilot is to create an Open Routing API.

The pilot will assess an abstract baseline suite of functions, capabilities, and encodings to address a common standard interface for network routing functionality. This includes guidance for extending the Routing API to account for various routing data models and support for network routing engine configuration via the Routing API.

The pilot shall apply multiple routing engines to multiple data schemas, and allow the dynamic adaptation of routes based on alternative inputs, route characteristics, and constraints. Featuring multiple clients, the pilot shall identify and describe optimal routing processes and workflows within standards-based infrastructures.

1.1. Background

Significant progress towards more Web-oriented interfaces has been made in OGC with the emerging APIs WFS 3.0 and WPS 3.0, both using OpenAPI. These successes shall now be applied to the challenge of routing. The pilot will develop an API that allows a WPS or a mobile application to calculate and serve routes based on a user defined set of conditions. Routes will be exchanged according to a well-defined route model. These two elements together will create an abstraction layer on top of routing data sources. Considering online and offline situations, it is expected that this initiative promotes interoperability among route consumers, route calculation engines, and corresponding services.

1.2. OGC Innovation Program Initiative

This Initiative is being conducted under the OGC Innovation Program. The OGC Innovation Program provides a collaborative agile process for solving geospatial challenges. Organizations (sponsors and technology implementers) come together to solve problems, produce prototypes, develop demonstrations, provide best practices, and advance the future of standards. Since 1999 more than 100 initiatives have been taking place.

1.3. Benefits of Participation

This Initiative provides a unique opportunity to influence the Routing API definition and by this shape future product landscape. It allows to create new business opportunities while the provided cost sharing boosts your R&D budget. The pilot has the potential for academic recognition and by meeting our sponsors, you gain insight into client needs and market shifts.

The outcomes are expected to shape the future of geospatial software development and data publication. The sponsorship supports this vision with cost-sharing funds to partially offset the costs associated with development, engineering, and demonstration of these outcomes. This offers selected Participants a unique opportunity to recoup a portion of their Initiative expenses.

2. Pilot Organization and Execution

2.1. Initiative Policies and Procedures

This initiative will be conducted under the following OGC Policies and Procedures:

2.2. Initiative Roles

The roles generally played in any OGC Innovation Program initiative include Sponsors, Bidders, Participants, Observers, and the Innovation Program Team ("IP Team"). Explanations of the roles are provided in Annex: Tips for New Bidders.

The IP Team for this Initiative will include an Initiative Director and an Initiative Architect. Unless otherwise stated, the Initiative Director will serve as the primary point of contact (POC) for the OGC.

The Initiative Architect will work with Participants and Sponsors to ensure that Initiative activities and deliverables are properly assigned and performed. They are responsible for scope and schedule control, and will provide timely escalation to the Initiative Director regarding any severe issues or risks that happen to arise.

2.3. Types of Deliverables

All activities in this pilot will result in a Deliverable. These Deliverables can take the form of Documents or Implementations.

2.3.1. Documents

Engineering Reports (ER) and Change Requests (CR) will be prepared in accordance with OGC published templates. Engineering Reports will be delivered by posting on the (members-only) OGC Pending directory when complete and the document has achieved a satisfactory level of consensus among interested participants, contributors and editors. Engineering Reports are the formal mechanism used to deliver results of the Innovation Program to Sponsors and to the OGC Standards Program for consideration by way of Standards Working Groups and Domain Working Groups. NOTE: Participants delivering Engineering Reports should also deliver Change Requests that arise from the documented work.

2.3.2. Implementations

Services, Clients, Datasets and Tools will be provided by methods suitable to its type and stated requirements. For example, services and components (e.g. a WPS instance) are delivered by deployment of the service or component for use in the Initiative via an accessible URL. A Client software application or component may be used during the Initiative to exercise services and components to test and demonstrate interoperability; however, it is most often not delivered as a license for follow-on usage. Implementations of services, clients and data instances will be developed and deployed in all threads for integration and interoperability testing in support of the agreed-up thread scenario(s) and technical architecture. The services, clients, and tools may be invoked for cross-thread scenarios in demonstration events.

2.4. Proposals & Proposal Evaluation

Proposals are expected to be short and precisely addressing the work items a bidder is interested in. A proposal template will be made available. The proposal, including technical and financial details, has a page limit as defined in Appendix A. Details on the proposal submission process are provided in Appendix A: Proposal Submission Guidelines. The proposal evaluation process and criteria are described below.

2.4.1. Evaluation Process

Proposals will be evaluated according to criteria based on three areas: Technical, management, and cost. Each review will commence by analyzing the proposed deliverables in the context of the Sponsor priorities, examining viability in light of the requirements and assessing feasibility against the use cases.

The review team will then create a draft Initiative System Architecture from tentatively selected proposals. This architecture will include the proposed components and relate them to available hardware, software, and data. Any candidate interface and protocol specification received from a Bidder will be included.

At the Technical Evaluation Meeting (TEM), the IP Team will present Sponsors with draft versions of the initiative system architecture and program management approach. The team will also present draft recommendations regarding which parts of which proposals should be offered cost-sharing funding (and at what level). Sponsors will decide whether and how draft recommendations in all these areas should be modified.

Immediately following TEM, the IP Team will begin to notify Bidders of their selection to enter negotiations for potentially becoming initiative Participants. The IP Team will develop for each selected bidder a Participant Agreement (PA) and a Statement of Work (SOW).

2.4.2. Management Criteria

  • Adequate, concise descriptions of all proposed activities, including how each activity contributes to achievement of particular requirements and deliverables. To the extent possible, it is recommended that Bidders utilize the language from the CFP itself to help trace these descriptions back to requirements and deliverables.

  • Willingness to share information and work in a collaborative environment

  • Contribution toward Sponsor goals of enhancing availability of standards-based offerings in the marketplace

2.4.3. Technical Criteria

  • How well applicable requirements in this CFP are addressed by the proposed solution

  • Proposed solutions can be executed within available resources

  • Proposed solutions support and promote the initiative system architecture and demonstration concept

  • Where applicable, proposed solutions are OGC-compliant

2.4.4. Cost Criteria

  • Cost-share compensation request is reasonable for proposed effort

  • All Participants are required to provide at least some level of in-kind contribution (i.e., activities or deliverables offered that do not request cost-share compensation). As a rough guideline, a proposal should include at least one dollar of in-kind contribution for every dollar of cost-sharing compensation requested. All else being equal, higher levels of in-kind contributions will be considered more favorably during evaluation. Participation may be fully in-kind.

2.5. Reporting

Initiative participant business/contract representatives are required (per the terms in the Participation Agreement contract) to report the progress and status of the participant’s work. Detailed requirements for this reporting will be provided during contract negotiation. Initiative accounting requirements (e.g., invoicing) will also be described in the contract.

The IP Team will provide monthly progress reports to Sponsors. Ad hoc notifications may also occasionally be provided for urgent matters. To support this reporting, each Pilot participant must submit (1) a Monthly Technical Progress Report and (2) a Monthly Business Progress Report by the first working day on or after the 10th of each month. Templates for both of these report types will be provided and must be followed.

The purpose of the Monthly Business Progress Report is to provide initiative management with a quick indicator of project health from the perspective of each Pilot participant. The IP Team will review action item status on a weekly basis with the Initiative participants assigned to complete those actions. Initiative participants must be available for these contacts to be made.

3. Master Schedule

The following table details the major Initiative milestones and events. Dates are subject to change.

Table 1. Master schedule
Milestone Date  Event

M01

25 February 2019

Release of Call for Participation (CFP)

M02

29 March April, 2019

Proposals due

M03

10 April 2019

Participant selection and agreements

M04

25 April 2019

Virtual Kick-off meeting (Go-To-Meeting)

M05

06 June 2019

WPS API and Route Exchange Model defined

M06

18 July 2019

Start TIEs

M07

30 August 2019

End of TIEs

M08

8 September 2019

Final videos due

M08

9 September 2019

Presentation of videos and results at TC meeting

M09

20 September 2019

Engineering Reports due

M10

30 September 2019

Participants Summary Reports due

3.1. Miscellaneous

Call for Participation

The CFP consists of stakeholder role descriptions, proposal submission instructions and evaluation criteria, a master schedule and other project management artifacts, Sponsor requirements, and a initiative architecture. The responses should include the proposing organization’s technical solution, its cost-sharing requests for funding, and its proposed in-kind contributions to the initiative.

Once the original CFP has been published, ongoing authoritative updates and answers to questions can be tracked by monitoring the CFP Corrigenda Table and the CFP Clarifications Table.

Participant Selection and Agreements:

Bidders may submit questions via timely submission of email(s) to the OGC Technology Desk. Question submitters will remain anonymous, and answers will be regularly compiled and published in the CFP Clarifications page.

OGC may also choose to conduct a Bidder’s question-and-answer webinar to review the clarifications and invite follow-on questions.

Following the closing date for submission of proposals, OGC will evaluate received proposals, review recommendations with the Sponsor, and negotiate Participation Agreement (PA) contracts, including statements of work (SOWs), with selected Bidders. Participant selection will be complete once PA contracts have been signed with all Participants.

Kick-off: The Kickoff is a virtual meeting (using GoToMeeting) where Participants, guided by the Initiative Architect, will refine the Initiative architecture and settle upon specific use cases and interface models to be used as a baseline for prototype component interoperability. Participants will be required to attend the Kickoff, including breakout sessions, and will be expected to use these breakouts to collaborate with other Participants and confirm intended Component Interface Designs.

Regular Teleconference and Interim Meetings After the Kickoff, participants will meet on a frequent basis remotely via web meetings and teleconferences.

Development of Engineering Reports, Change Requests, and Other Document Deliverables: Development of Engineering Reports (ERs), Change Requests (CRs) and other document deliverables will commence during or immediately after Kickoff.

Under the Participation Agreement (PA) contracts to be formed with selected Bidders, ALL Participants will be responsible for contributing content to the ERs. But the ER Editor role will assume the duty of being the primary ER author.

Final Summary Reports, Demonstration Event and Other Stakeholder Meetings: Participant Final Summary Reports will constitute the close of funded activity. Further development work might take place to prepare and refine assets to be shown at the Demonstration Event and other stakeholder meetings.

Assurance of Service Availability: Participants selected to implement service components must maintain availability for a period of no less than six months after the Participant Final Summary Reports milestone. OGC might be willing to entertain exceptions to this requirement on a case-by-case basis.

4. Deliverables

The following table summarizes the full set of Initiative deliverables. Technical details can be found in the Appendix B: Technical Architecture.

Table 2. CFP Deliverables and Funding Status
ID Document / Component Funding Status

D001

ER

funded

D002

ER

pending funding - contract is in work

D003

ER

pending funding - contract is in work

D100

Component

funded

D101

Component

funded

D102

Component

funded

D103

Component

funded

D104

Component

funded

D105

Component

funded

D106

Component

funded

D108

Component

pending funding - contract is in work

D109

Component

pending funding - contract is in work

D110

Component

pending funding - contract is in work

D111

Component

pending funding - contract is in work

D112

Component

pending funding - contract is in work

D113

Component

pending funding - contract is in work

Appendix A: Proposal Submission Guidelines

A.1. General Requirements

The following requirements apply to the proposal development process and activities.

  • Proposals must be submitted before the appropriate response due date indicated in the Master Schedule.

  • Proposing organizations must be an OGC member and familiar with the OGC Mission, Vision, and Goals. Proposals from non-members will be considered, if a completed application for OGC membership or a letter of intent to become a member if selected for funding is submitted prior to or along with the proposal. If you are in doubt about membership, please contact OGC at techdesk@opengeospatial.org.

  • Proposals may address selected portions of the initiative requirements as long as the solution ultimately fits into the overall initiative architecture. A single proposal may address multiple requirements and deliverables. To ensure that Sponsor priorities are met, the OGC may negotiate with individual Bidders to drop, add, or change some of the proposed work.

  • Participants selected to implement component deliverables will be expected to participate in the full course of interface and component development, Technical Interoperability Experiments, and demonstration support activities throughout Initiative execution.

  • In general, a proposed component deliverable based on a product that has earned OGC Certification will be evaluated more favorably than one which has not.

  • Participants selected as Editors will also be expected to participate in the full course of activities throughout the Initiative, documenting implementation findings and recommendations and ensuring document delivery.

  • Participants should remain aware of the fact that the Initiative components will be developed across many organizations. To maintain interoperability, each Participant should diligently adhere to the latest technical specifications so that other Participants may rely on the anticipated interfaces during the TIEs.

  • All Selected Participants (both cost-share and pure in-kind) must attend with at least one technical representative to the Kickoff. Participants are also encouraged to attend at least with one technical representative the Demonstration Event.

  • No work facilities will be provided by OGC. Each Participant will be required to perform its PA obligations at its own provided facilities and to interact remotely with other Initiative stakeholders.

  • Information submitted in response to this CFP will be accessible to OGC staff members and to Sponsor representatives. This information will remain in the control of these stakeholders and will not be used for other purposes without prior written consent of the Bidder. Once a Bidder has agreed to become an Initiative Participant, it will be required to release proposal content (excluding financial information) to all Initiative stakeholders. Commercial confidential information should not be submitted in any proposal (and, in general, should not be disclosed during Initiative execution).

  • Bidders will be selected to receive cost sharing funds on the basis of adherence to the requirements (as stated in the CFP Appendix B Technical Architecture) and the overall quality of their proposal. The general Initiative objective is for the work to inform future OGC standards development with findings and recommendations surrounding potential new specifications. Bidders are asked to formulate a path for producing executable interoperable prototype implementations that meet the stated CFP requirements, and for documenting the findings and recommendations arising from those implementations. Bidders not selected for cost sharing funds may still be able to participate by addressing the stated CFP requirements on a purely in-kind basis.

  • Bidders are advised to avoid attempts to use the Initiative as a platform for introducing new requirements not included in the Appendix B Technical Architecture. Any additional in-kind scope should be offered outside the formal bidding process, where an independent determination can be made as to whether it should be included in Initiative scope or not. Items deemed out-of-scope might still be appropriate for inclusion in a later OGC Innovation Program initiative.

  • Each Participant (including pure in-kind Participants) that is assigned to make a deliverable will be required to enter into a Participation Agreement contract ("PA") with the OGC. The reason this requirement applies to pure in-kind Participants is that other Participants will be relying upon their delivery to show component interoperability. Each PA will include a statement of work ("SOW") identifying Participant roles and responsibilities.

A.2. What to Submit

The two documents that shall be submitted, with their respective templates are as follows: 1. Technical Proposal: https://portal.opengeospatial.org/files/?artifact_id=82493 2. Cost Proposal: https://portal.opengeospatial.org/files/?artifact_id=82494

A Technical Proposal should be based on the Response Template and must include the following:

  • Cover page

  • Overview (Not to exceed one page)

  • Proposed contribution (Basis for Technical Evaluation; not to exceed 1 page per work item)

  • Understanding of interoperability issues, understanding of technical requirements and architecture, and potential enhancements to OGC and related industry architectures and standards

  • Recommendations to enhance Information Interoperability through industry-proven best practices, or modifications to the software architecture defined in Appendix B: Technical Architecture

  • If applicable, knowledge of and access to geospatial data sets by providing references to data sets or data services

The Cost Proposal should be based on the two worksheets contained in the Cost Proposal Template and must include the following:

  • Completed Pilot Cost-Sharing Funds Request Form

  • Completed Pilot In-Kind Contribution Declaration Form

Additional instructions are contained in the templates themselves.

A.3. How to Transmit the Response

Guidelines:

  • Proposals shall be submitted to the OGC Technology Desk (techdesk@opengeospatial.org).

  • The format of the technical proposal shall be Microsoft Word or Portable Document Format (PDF).

  • The format of the cost proposal is a Microsoft Excel Spreadsheet.

  • Proposals must be submitted before the appropriate response due date indicated in the Master Schedule.

A.4. Questions and Clarifications

Once the original CFP has been published, ongoing authoritative updates and answers to questions can be tracked by monitoring this CFP.

Bidders may submit questions via timely submission of email(s) to the OGC Technology Desk. Question submitters will remain anonymous, and answers will be regularly compiled and published in the CFP clarifications table.

OGC may also choose to conduct a Bidder’s question-and-answer webinar to review the clarifications and invite follow-on questions.

Update to this CFP including questions and clarifications will be posted to the original URL of this CFP.

Appendix B: Technical Architecture

This appendix provides the technical architecture, which includes descriptions of the OGC baseline and identifies all requirements and corresponding work items.

B.1. Baseline Architecture

B.1.1. OGC Reference Model

The OGC Reference Model (ORM) version 2.1, provides an architecture framework for the ongoing work of the OGC. Further, the ORM provides a framework for the OGC Standards Baseline. The OGC Standards Baseline consists of the member-approved Implementation/Abstract Specifications as well as for a number of candidate specifications that are currently in progress.

The structure of the ORM is based on the Reference Model for Open Distributed Processing (RM-ODP), also identified as ISO 10746. This is a multi-dimensional approach well suited to describing complex information systems.

The ORM is a living document that is revised on a regular basis to continually and accurately reflect the ongoing work of the Consortium. Bidders are encouraged to learn and understand the concepts that are presented in the ORM.

This appendix refers to the RM-ODP approach and will provide information on some of the viewpoints, in particular the Enterprise Viewpoint, which is used here to provide the general characterization of work items in the context of the OGC Standards portfolio and standardization process, i.e. the enterprise perspective from an OGC insider.

The Information Viewpoint considers the information models and encodings that will make up the content of the services and exchanges to be extended or developed to support this initiative. Here, we mainly refer to the OGC Standards Baseline, see section Standards Baseline.

The Computational Viewpoint is concerned with the functional decomposition of the system into a set of objects that interact at interfaces – enabling system distribution. It captures component and interface details without regard to distribution and describes an interaction framework including application objects, service support objects and infrastructure objects. The development of the computational viewpoint models is one of the first tasks of the Pilot, usually addressed at the Kickoff.

refModel
Figure 1. Reference Model for Open Distributed Computing

The Engineering Viewpoint is concerned with the infrastructure required to support system distribution. It focuses on the mechanisms and functions required to:

  1. support distributed interaction between objects in the system, and

  2. hides the complexities of those interactions.

It exposes the distributed nature of the system, describing the infrastructure, mechanisms and functions for object distribution, distribution transparency and constraints, bindings and interactions. The engineering viewpoint will be developed during the Initiative, usually in the form of TIEs, where Participants define the communication infrastructure and assign elements from the computational viewpoint to physical machines used for demonstrating Initiative results.

B.1.2. OGC Standards Baseline

The OCG Standards Baseline is the complete set of member approved Abstract Specifications, Standards including Profiles and Extensions, and Community Standards.

OGC standards are technical documents that detail interfaces or encodings. Software developers use these documents to build open interfaces and encodings into their products and services. These standards are the main "products" of the Open Geospatial Consortium and have been developed by the membership to address specific interoperability challenges. Ideally, when OGC standards are implemented in products or online services by two different software engineers working independently, the resulting components plug and play, that is, they work together without further debugging. OGC standards and supporting documents are available to the public at no cost. OGC Web Services (OWS) are OGC standards created for use in World Wide Web applications.

Any Schemas (xsd, xslt, etc.) that support an approved OGC standard can be found in the official OGC Schema Repository.

The OGC Testing Facility Web page provides online executable tests for some OGC standards. The facility helps organizations to better implement service interfaces, encodings and clients that adhere to OGC standards.

B.1.3. OGC Best Practices and Discussion Papers

OGC also maintains other documents relevant to Innovation Program initiatives, including Engineering Reports, Best Practice Documents, Discussion Papers, and White Papers.

B.2. Pilot Architecture

pilotSigns

The goal of the pilot is to create an Open Routing API and a Route Exchange Model. The pilot will assess an abstract baseline suite of functions, capabilities, and encodings to address a common standard interface for network routing functionality. This includes guidance for extending the Routing API to account for various routing data models and support for network routing engine configuration via the Routing API.

The pilot shall apply multiple routing engines to multiple data schemas, and allow the dynamic adaptation of routes based on alternative inputs, route characteristics, and constraints. Featuring multiple clients, the pilot shall identify and describe optimal routing processes and workflows within standards-based infrastructures. The implementation scenarios include both online and offline situations. In online scenarios, the clients interact with WPS instances that calculate routes, whereas in offline scenarios, apps on mobile devices interact with GeoPackages stored on the mobile device. Both types include sharing of routes. Routes shall be visualized in clients, but focus is not on portrayal as such!

B.2.2. Scenario & Requirements

The scenario shall demonstrate the processing of different routing requests in online and offline situations as well as the exchange of routes between route consumers. Routes shall be returned in GeoJSON format. The pilot shall define a route exchange model that allows sharing of routes. The following figure illustrates the scenario with its various components and interaction steps.

scenario
Figure 2. Routing Pilot main scenario

Consumers (1-3) use different types of desktop, browser, or mobile application to calculate routes based on user input. The different types of apps, depending on online/offline situation, either request routes at WPS interfaces (1), use locally stored GeoPackage data and routing engines (3), or a hybrid solution that uses remote WPS instances as well as local resources for route calculation and analysis.

Overall, the pilot shall:

  1. Define a Route Exchange Model in GeoJSON (it is not envisioned to develop a conceptual, i.e. format independent route model in this initiative)

  2. Define a Routing API to define routing tasks and receive routing outputs

  3. Demonstration of both Routing API and Route Exchange Model with different clients, various WPS instances and GeoPackage containers

    1. Apply routing engines to multiple data sets following different data schemas

    2. Demonstrate that routing engines can adapt to alternative inputs, requirements, and constraints

    3. Assess routing processes and workflows with routing engines directly accessible and available behind RESTful WPS interfaces

    4. Demonstrate online and offline route calculation scenarios

threeItems
Figure 3. Routing Pilot main activities
Route Exchange Model

One of the first activities in this initiative is the definition of a route exchange model. The model shall be developed in GeoJSON. Participants shall make recommendations for route validation and develop the necessary tools.

The following figure shows some exemplary route serializations. Detailed requirements on the route model will be discussed at the kick-off meeting.

routeExamples
Figure 4. Route examples
Routing API

Routing requests start with simple settings that only include a start- and endpoint. They continue with gradually more complex requests including additional waypoints, specific constraints on road characteristics, or temporal constraints (e.g. best/fastest route for a specific time of the day). To allow cost efficient implementations, the pilot shall develop a Routing API core model with extensions. The content of the core needs to be defined first. The following split is a first suggestion:

  • Core: API that allows selecting the routing engine and produces route output for on-road driving for shortest and fastest route with limited constraint parameters (e.g. observe one-way)

  • Extension: API that allows additional constraints (e.g. obstructions, loads) and outputs (Traveling Salesman Problem, catchment definition), complex route tasks

The Routing API shall be made available as a WPS 3.0 profile.

Routing Demonstration

The main scenario, illustrated in figure above, consists of three parts that are further outlined in the following paragraphs:

Common to all scenarios are some base requirements and considerations:

  1. All route calculating components shall return routes according to the Route Exchange Model.

  2. All consumers can share routes with other consumers. The technical details of route sharing are subject of discussion and need to be agreed between all participants at the kick-off meeting. It is foreseen that routes can be shared in their native GeoJSON format. Routes are shared with all other clients in this initiative.

  3. Though not in focus of this initiative, all clients or mobile apps shall be able to portray different route types on a map and support at minimum simple route analytics such as lengths analysis and local persistent storage of routes.

Requirements specific to the various components of the demonstration scenario are defined below:

Online Scenario

In the Online Scenario, the consumer (1) uses a desktop or browser based client (2a-b) to interact with a WPS 3.0 instance that provides the Routing API (3). The WPS instance (4) communicates with different routing engines. For this pilot, it is planned to develop three routing engines to support Open Streetmap data, HERE data, and NSG based routable datasets (5a-c). The communication between the routing engines and the routing source data is out of scope for this pilot (6). The WPS returns routes (7) that consumers can share with other consumers (8).

scenario1
Figure 5. Routing Pilot Online Scenario
Offline Scenario

In the Offline Scenario, the consumer (1) uses a mobile device such as a mobile phone or a tablet computer (2). A routing app (3) is installed on the mobile device. The consumer interacts with the routing app. The routing app supports reading routing source data from GeoPackage files (4). For this pilot, it is planned to develop three routing apps to support Open Streetmap data, HERE data, and NSG based routable datasets. The routing app return routes that consumers can share with other consumers (5). Ideally, route app and route engine are decoupled and made available as separate elements on the mobile device. This approach would allow rapid change of routing engines and allow some interesting experimentation with interoperability settings on mobile devices.

scenario2
Figure 6. Routing Pilot Offline Scenario
Hybrid Scenario

In the Hybrid Scenario, the consumer (1) uses a mobile device such as a mobile phone or a tablet computer (2). A routing app (3) is installed on the mobile device. The consumer interacts with the routing app, which interacts with online WPS as well as locally stored GeoPackages. The online workflow (4-5) is similar to the online scenario, the GeoPackage workflow (6) similar to the offline scenario. The routing app return routes that consumers can share with other consumers (7).

scenario3
Figure 7. Routing Pilot Hybrid Scenario
Routing Engine Requirements

The following specific requirements have been identified:

  • Each routing engine shall be made available as part of a WPS. This requires close cooperation with the WPS providers, as the interface between the engine and the WPS provider needs to be designed. In addition, each routing engine shall support a simple testing API that can be used with curl.

  • As a minimum, each route engine must support one data schema and one graph solving algorithm to provide one output product

    • More robust engines are desired (support multiple schema with multiple algorithms to provide multiple products)

  • Each routing engine shall support at least one of the following data schemas:

    • HERE

    • OSM

    • NSG (NSG based routable dataset prototype)

  • Participants are free to implement their favorite routing algorithm, such as e.g. Dikjstra, Floyd Marshall, Astar, etc.

  • Each routing engine shall at least produce products of type "Route". The other two product types are optional:

    • Route(s) - series of nodes and edges that form the route with attributes (speed, road class, street name, etc.; details subject to the pilot)

    • Traveling Salesman Problem (TSP) - optimized route (series of nodes and edges) for a given set of nodes and graph conditions (optional)

    • Catchment/ Distance Area - Surface area representing the distance one can travel given graph conditions (optional)

  • Each routing engine shall support route assessment. That is, a route product from a different engine or data source can be assessed for comparison (roughly same distance or time, feasible solution, etc)

WPS Requirements

The following WPS-specific requirements have been identified:

  • Accelerate the development of WPS 3.0 as a RESTful service interface with OpenAPI support, following the guidelines and model of WFS 3.0

  • Define a WPS 3.0 core and extension model

  • Demonstrate client ability to invoke WPS that accesses data set(s), executes routing engine(s), and returns result to client

  • Allow optional use of WPS 2.0 façades to WPS 3.0 instances exposed by externally provided routing engines

  • Allow optional use of chained services (WPS X receives task, identifies data and invokes WPS Y to execute routing engine)

Client/Mobile Application Requirements

In addition to the connectivity requirements illustrated above (connection to WPS (online scenario), to GeoPackages (offline scenario), or both (hybrid scenario)), clients shall be implemented as mobile applications, browser based applications, or desktop applications that support all route definition elements and the visualization of routes and complementing symbols, such as e.g. obstructions, special road conditions etc. The specific visualization requirements will be agreed upon at the kick-off meeting. It is emphasized that this initiative does not focus on portrayal, though.

Further on, each client shall support selection/settings to:

  • Start route calculation based on set of precompiled attributes (fastest route, shortest route), taking direction of travel along one-way streets into account

  • Augment routing parameters with user inputs (given that the dataset contains the necessary attributes) such as

    • Restrict passage through overhead obstructions (Bridges, overpasses, tunnels) less a certain height

    • Restrict passage along bridges with exceeds weight limits

    • Prefer routes with specified characteristics

  • Selection of transportation profiles for on-road routing

    • Driving

    • Walking

  • Define dynamic influences:

    • Create an object/obstacle (Map interface or uploaded source (JSON, Shapefile) point, line, or polygon to generate a route that avoids the obstacle

Each client shall support result validation:

  • Output is a valid file GeoJSON file

  • Output content can be verified to be compliant with routing model

  • Output route should reflect an expected outcome (start and end point and avoidance of obstacles)

There is no expectation that created routes by the various engines will be identical, given possible differences in the various data sources and applied routing algorithms. Though, it is expected that created routes will be identical when using the same data source and solving algorithm with or without a WPS being part of the communication. Ideally, clients allow the overlay of different routes to visualize differences and provide route characteristics, such as length, type of ratio of underground, etc.

B.2.3. Data Conditions

The Following information was derived from the data’s respective schema documentation

  • OSM: https://wiki.openstreetmap.org/

  • HERE: NAVTEQ’s NAVESTREETS Street Data Reference Manual v4.4 April 1, 2012

  • NSG: This is a prototyped NAS-Compliant Model for Military focused routing and is currently a conditional dataset. More information will be provided >>> WHEN? <<<.

B.2.4. Route Types and Elements

Shortest Route

Description: Shortest distance between a start and intermediate or end point

Schema Representation:

  • OSM: Geodesic or Euclidean Length of way

  • HERE: Geodesic or Euclidean Length of street geometries

  • NSG: LZN Attribute of network edge

Fastest Route

Description: Shortest estimated duration between a start and intermediate or end point

Schema Representation:

  • OSM:

    • Speed: maxspeed tag (if available), else a generic speed map assignment to the various highway classes (MPH,KPH)

    • Distance: Euclidean Length of way in either metric or imperial.

  • HERE:

    • Speed: From Reference Speed Limit or Towards Reference Speed Limit depending on the direction of travel

    • Distance: Geodesic or Euclidean Length of streets geometry

  • NSG: SPM Kilometers Per Hour (KPH), SPD Miles Per Hour(MPH)

Note
Speed attributes of commercial datasets are usually represented in metric system of the source country.
Direction of Travel

Description: Obey travel directions of all network edges

  • OSM: oneway tag:

    • yes or 1 restricts travel to the direction the way was digitized

    • -1 restricts travel to the reverse direction the way was digitized

    • Absence of tag indicates the way is bidirectional

  • HERE: 'Direction of Travel' attribute:

    • B: Bidirectional

    • F: From Reference Node

    • T: Toward Reference Node

  • NSG:

    • 1: restricts travel to the direction the edge was digitized

    • -1: restricts travel to the reverse direction the way was digitized

    • 2: Bidirectional

Overhead Obstruction

Description: Restrict passage where object (vehicle, equipment) exceeds height requirement

  • OSM: maxheight tag. Values can be represented as either imperial (e.g. 13"5') or Metric (4m)

  • HERE: A height restriction is represented as a "Transport Restriction" where a street link will have a condition type of 23 (Transport Access Restriction) and a condition modifier of 41 (height restriction). The Value of restriction is found in the cdnmod table and will be in either inches or centimeters (6.13.4)

  • NSG: Overhead Clearance (OHC) in meters

Maximum Load

Description: Restrict passage where object (vehicle, equipment) exceeds weight requirement

  • OSM: maxweight: Values can be represented in either metric tonnes or kilograms; see https://wiki.openstreetmap.org/wiki/Key:maxweight

  • HERE: A weight restriction is represented as a "Transport Restriction" where a street link will have a condition type of 23 (Transport Access Restriction) and a condition modifier of 42 (weight restriction). The Value of restriction is found in the cdnmod table and will be in either pounds or kilograms (6.13.4)

  • NSG: This model doesn’t support commercial and civil transportation weight limits. Rather it supports Military Load Classification (MLC) of bridges and military ferries per STANAG 2021

    • Load Class One LC1: One way travel for Wheeled Vehicles

    • Load Class Two LC2: Two way travel for Wheeled Vehicles

    • Load Class Three LC3: One way travel for Tracked Vehicles

    • Load Class Four LC4: Two way travel for Tracked Vehicles

B.2.5. Work Items & Deliverables

The following figure illustrates the work items and deliverables of this initiative.

deliverables

The following list identifies all deliverables that are part of this pilot. Detailed requirements are stated above. All participants are required to participate in all technical discussions.

Videos It is emphasized that each participant shall develop and deliver or participate in the production of a short video that can be used in outreach activities on a royalty-free basis. The video shall illustrate the initial challenge(s) and developed solutions. The video can be done using screen-capturing of clients or slides with voice over. Good examples for videos are available from previous initiatives, such as Arctic Spatial Data Pilot (video 1, video 2), Vector Tiles Pilot (video), or Testbed-13 (video 1, video 2).

Engineering Reports

  • D001 Routing Pilot Engineering Report - Engineering Report capturing all results and experiences from this initiative. The Engineering Report shall describe all rationale behind all design decisions taken and discarded, and provide a summary of the initiative for experts and non-experts. The Engineering Report editor is responsible for the overall demonstration scenario and corresponding video.

  • D002 Route Exchange Model Engineering Report - Engineering Report describing the route exchange model and the route exchange model validation tool in full detail. The Engineering Report editor is responsible for the design of the route exchange model.

  • D003 WPS Routing API Engineering Report - Engineering Report describing the WPS API as well as lessons learned during the implementation and demonstration scenario development in full detail. The Engineering Report editor is responsible for the precise definition of the WPS v3.0 model, a task that requires coordination with the WPS Standards Working Group (SWG).

Components

  • D100 Client 1 - Browser or desktop app client application interacting with all WPS instances (D102, D103, D110). Ideally, this component provides GeoPackage support and participates in hybrid and offline scenarios.

  • D101 Client 2 - Browser or desktop app client application interacting with all WPS instances (D102, D103, D110). Ideally, this component provides GeoPackage support and participates in hybrid and offline scenarios.

  • D102 WPS 1 - WPS 3.0 instance interfacing all routing engines (D104, D105, D106)

  • D103 WPS 2 - WPS 3.0 instance interfacing all routing engines (D104, D105, D106)

  • D104 Routing Engine OSM - Routing Engine with support for OSM data. Needs to be connected to all WPS instances (D102, D103, D110)

  • D105 Routing Engine HERE - Routing Engine with support for HERE data. Needs to be connected to all WPS instances (D102, D103, D110)

  • D106 Routing Engine NSG - Routing Engine with support for NSG data. Needs to be connected to all WPS instances (D102, D103, D110)

  • D108 Routing Application 1 - Android or iOS application interfacing with all WPS instances (D102, D103, D110) and all GeoPackages (D111, D112, D113). Supports the online, offline, and hybrid scenarios.

  • D109 Routing Application 2 - Android or iOS application interfacing with all WPS instances (D102, D103, D110) and all GeoPackages (D111, D112, D113). Supports the online, offline, and hybrid scenarios.

  • D110 WPS 3 - WPS 3.0 instance interfacing all routing engines (D104, D105, D106)

  • D111 GeoPackage OSM - GeoPackage with all routing source data type OSM. GeoPackage needs to be delivered to mobile application developers (D108, D109, D115)

  • D112 GeoPackage HERE - GeoPackage with all routing source data type OSM. GeoPackage needs to be delivered to mobile application developers (D108, D109, D115)

  • D113 GeoPackage NSG - GeoPackage with all routing source data type OSM. GeoPackage needs to be delivered to mobile application developers (D108, D109, D115)

Appendix C: Tips for new bidders

Bidders who are new to OGC initiatives are encouraged to review the following tips:

  • In general, the term "activity" is used as a verb describing work to be performed in an initiative, and the term "deliverable" is used as a noun describing artifacts to be developed and delivered for inspection and use.

  • The roles generally played in any OGC Innovation Program initiative are defined in the OGC Innovation Program Policies and Procedures, from which the following definitions are derived and extended:

    • Sponsors are OGC member organizations that contribute financial resources to steer Initiative requirements toward rapid development and delivery of proven candidate specifications to the OGC Standards Program. These requirements take the form of the deliverables described herein. Sponsors representatives help serve as "customers" during Initiative execution, helping ensure that requirements are being addressed and broader OGC interests are being served.

    • Bidders are organizations who submit proposals in response to this CFP. A Bidder selected to participate will become a Participant through the execution of a Participation Agreement contract with OGC. Most Bidders are expected to propose a combination of cost-sharing request and in-kind contribution (though solely in-kind contributions are also welcomed).

    • Participants are selected OGC member organizations that generate empirical information through the definition of interfaces, implementation of prototype components, and documentation of all related findings and recommendations in Engineering Reports, Change Requests and other artifacts. They might be receiving cost-share funding, but they can also make purely in-kind contributions. Participants assign business and technical representatives to represent their interests throughout Initiative execution.

    • Observers are individuals from OGC member organizations that have agreed to OGC intellectual property requirements in exchange for the privilege to access Initiative communications and intermediate work products. They may contribute recommendations and comments, but the IP Team has the authority to table any of these contributions if there’s a risk of interfering with any primary Initiative activities.

    • The Innovation Program Team (IP Team) is the management team that will oversee and coordinate the Initiative. This team is comprised of OGC staff, representatives from member organizations, and OGC consultants. The IP Team communicates with Participants and other stakeholders during Initiative execution, provides Initiative scope and schedule control, and assists stakeholders in understanding OGC policies and procedures.

    • The term Stakeholders is a generic label that encompasses all Initiative actors, including representatives of Sponsors, Participants, and Observers, as well as the IP Team. Initiative-wide email broadcasts will often be addressed to "Stakeholders".

    • Suppliers are organizations (not necessarily OGC members) who have offered to supply specialized resources such as capital or cloud credits. OGCs role is to assist in identifying an initial alignment of interests and performing introductions of potential consumers to these suppliers. Subsequent discussions would then take place directly between the parties.

  • Non-OGC member organizations must become members in order to be selected as Participants. Non-members are welcomed to submit proposals as long as the proposal is complemented by a letter of intent to become a member if selected for.

  • Any individual wishing to gain access to the Initiative’s intermediate work products in the restricted area of the Portal (or attend private working meetings / telecons) must be a member-approved user of the OGC Portal system. Intermediate work products that are intended to be shared publicly will be made available as draft ER content in a public GitHub repository.

  • Individuals from any OGC member organization that does not become an Initiative Sponsor or Participant may still (as a benefit of membership) quietly observe all Initiative activities by registering as an Observer.

  • Prior initiative participation is not a direct bid evaluation criterion. However, prior participation could accelerate and deepen a Bidder’s understanding of the information presented in the CFP.

  • All else being equal, preference will be given to proposals that include a larger proportion of in-kind contribution.

  • All else being equal, preference will be given to proposed components that are certified OGC-compliant.

  • All else being equal, a proposal addressing all of a deliverable’s requirements will be favored over one addressing only a subset. Each Bidder is at liberty to control its own proposal, of course. But if it does choose to propose only a subset for any particular deliverable, it might help if the Bidder prominently and unambiguously states precisely what subset of the deliverable requirements are being proposed.

  • The Sponsor(s) will be given an opportunity to review selection results and offer advice, but ultimately the Participation Agreement (PA) contracts will be formed bilaterally between OGC and each Participant organization. No multilateral contracts will be formed. Beyond this, there are no restrictions regarding how a Participant chooses to accomplish its deliverable obligations so long as the Participant’s obligations are met in a timely manner (e.g., with or without contributions from thirdparty subcontractors).

  • In general, only one organization will be selected to receive cost-share funding per deliverable, and that organization will become the Assigned Participant upon which other Participants will rely for delivery. Optional in-kind contributions may be made provided that they don’t disrupt delivery of the required, reliable contributions from Assigned Participants.

  • A Bidder may propose against any or all deliverables. Participants in past initiatives have often been assigned to make only a single deliverable. At the other extreme, it’s theoretically possible that a single organization could be selected to make all available deliverables.

  • In general, the Participant Agreements will not require delivery any component source code to OGC.

    • What is delivered instead is the behavior of the component installed on the Participant’s machine, and the corresponding documentation of findings, recommendations, and technical artifacts as contributions to the initiative’s Engineering Report(s).

    • In some instances, a Sponsor might expressly require a component to be developed under open-source licensing, in which case the source code would become publicly accessible outside the Initiative as a by-product of implementation.

  • Results of other recent OGC initiatives can be found in the OGC Public Engineering Report Repository.

  • A Bidders Q&A Webinar will likely be conducted soon after CFP issuance. The webinar will be open to the public, but prior registration will be required.