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.