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.

Date Section Description

13 July

Appended to Corrigenda.

Not really a corrigendum, but rather just a summary of submission procedures.

15 July

Shortcuts for Interested Bidder.

Added Bidders Q&A Webinar registration link to list.

Summary of Procedures to Submit a CFP Response

Here are some shortcuts to help interested bidders respond to the CFP:

Abbreviations

The following table lists abbreviations used in this CFP.

3DPS

Three-Dimensional Portrayal Service or SWG

ADE

Application Domain Extension

CFP

Call for Participation

CR

Change Request

CSW

Catalog Service for the Web

DER

Draft Engineering Report

DWG

Domain Working Group

ER

Engineering Report

GML

Geography Markup Language

IER

Initial Engineering Report

IP

Innovation Program or Intellectual Property

ISO

International Organization for Standardization

LiDAR

LIght Detection And Ranging

NAPSG

National Alliance for Public Safety GIS

NIST

National Institute of Standards and Technology

OGC

Open Geospatial Consortium

ORM

OGC Reference Model

OWS

OGC Web Services

PA

Participation Agreement

POC

Point of Contact

PSCR

(NIST) Public Safety Communications Research Division

Q&A

Questions and Answers

RM-ODP

Reference Model for Open Distributed Processing

SOW

Statement of Work

SWG

Standards Working Group

TBD

To Be Determine (at a later date)

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)

-

-

Introduction

The Open Geospatial Consortium (OGC®) is releasing this Call for Participation ("CFP") to solicit proposals for the OGC Indoor Mapping and Navigation Pilot Initiative ("Initiative" or "Pilot"). The proposal submission deadline and other key dates can be found in the Master Schedule.

This Initiative will address key challenges related to indoor mapping and navigation for first responders. While the focus is on developing the capabilities and workflow required for preplanning operations, the intent is that future OGC initiatives will address the real-time, event-driven aspects of indoor mapping and navigation for first responders.

First responders typically survey high-risk facilities in their jurisdiction at least once per year as part of a preplanning process. Preplanning outputs are often in report form, and first responders may annotate available floor plans (e.g. from computer-aided design models) or generate their own hand-drawn maps during the process. Preplanning is time-consuming, inefficient, and inherently complex considering the information and level of detail that should or could be captured, the lack of automation, and the difficulty identifying notable changes to facilities and infrastructure during successive preplanning surveys.

Indoor LiDAR from youtube 6cwhPMAap8
Figure 1. Indoor LiDAR scene (source: youtube)

The National Institute of Standards and Technology (NIST) Communications Technology Laboratory (CTL), Public Safety Communications Research (PSCR) Division ("Sponsor") has identified mobile 3D light detection and ranging (LiDAR) as a potentially transformational technology for first responders. Using LiDAR and 360-degree cameras imagery, coupled with advanced software processing, first responders could efficiently capture 3D point clouds and a wealth of other information, both observed and derived, while walking through buildings as part of routine preplanning operations. The use of 3D LiDAR and imagery has many potential upsides beyond just creating point clouds for visualization and mapping, e.g., use in localization, object classification, integration with virtual/augmented reality solutions, change detection, etc. Though not widely used currently for surveying, especially outside the architectural, engineering, and construction (AEC) community, it is expected that investments by the automotive and unmanned aerial systems industries will drive the costs of 3D LiDAR down dramatically over the next five years, so that it will become a cost-effective tool for public safety, building owners/managers, and various service industries.

To accelerate research and development for this public-safety-driven scenario, this Initiative will conduct the following prototyping and demonstration activities:

  1. Create and convert 3D indoor LiDAR point cloud models and associated imagery to functional building and navigation models.

  2. Store and serve point cloud, building, and navigation models for visualization and navigation.

  3. Derive dynamic turn-by-turn indoor navigation instructions based on the navigation model.

  4. View and annotate point cloud data, imagery, and building models, along with navigation routes and instructions into, through, and out of buildings.

Under this CFP, the OGC will provide cost-sharing funds on behalf of the Sponsor to partially offset expenses uniquely associated with the Initiative. This CFP requests proposals (also referred to as "bids") from organizations ("Bidders") wishing to participate in delivery and, in some cases, to receive cost-sharing funds. Any Bidder interested in Initiative participation should respond by submitting a proposal per the instructions provided herein.

OGC intends to involve as many technology developers and providers ("Participants", to be selected from among the Bidders) as possible to the extent that each Participant can contribute to and benefit from Initiative outcomes. Not all proposals are required to request cost-sharing funds. While the majority are expected to include a combination of cost-sharing request and in-kind contribution, responses offering only in-kind contributions (i.e., requesting no cost-sharing funds whatsoever) are also welcomed.

The only offers that should be included in formal proposals are those directly addressing express CFP requirements. Proposals covering additional requirements should be submitted separately for independent consideration.

This Initiative is being conducted as part of the Indoor Mapping and Navigation Pilot project under the OGC Innovation Program. This Program provides global, hands-on, collaborative prototyping for rapid development and delivery of proven candidate specifications to the OGC Standards Program, where these candidates can then be considered for further action. In Innovation Program initiatives, Participants collaborate to examine specific geo-processing interoperability questions posed by initiative sponsors for the purpose of advancing the OGC Standards Baseline. These initiatives include testbeds, experiments, pilots, and plugfests – all designed to foster the rapid development and adoption of open, consensus-based standards. The OGC also maintains a list of candidate ideas for future initiatives.

Benefits of Participation

In general, Bidders should propose specifically against the list of deliverables described under the Summary of Deliverables.

This Initiative provides a business opportunity for stakeholders to mutually define, refine, and evolve service interfaces and protocols in the context of hands-on experience and feedback. 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.

Initiative Policies and Procedures

This CFP incorporates the following additional documents:

This Initiative will be conducted in accordance with OGC Innovation Program Policies and Procedures.

OGC Principles of Conduct will govern all personal and public Initiative interactions.

One Initiative objective is to support the OGC Standards Program in the development and publication of open standards. Each Participant will be required to allow OGC to copyright and publish documents based in whole or in part upon intellectual property contributed by the Participant during Initiative performance. Specific requirements are described under the "Copyrights" clauses of the OGC Intellectual Property Rights Policy.

Initiative Roles

The roles generally played in any OCG Innovation Program initiative are defined in the OGC Innovation Program Policies and Procedures, including Sponsors, Bidders, Participants, Observers, and the Innovation Program Team ("IP Team").

Additional explanations of the roles of Sponsors, Bidders, Participants, and Observers are provided in the 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.

1. General Proposal Submission Guidelines

This section presents general guidelines for submitting a CFP proposal. Detailed instructions for submitting a response proposal using the Bid Submission Form web page can be found in Appendix A Management Requirements.

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

Bidders responding to this CFP should be familiar with the OGC Mission, Vision, and Goals. Proposals from non-members will be considered provided that a completed application for OGC membership (or a letter of intent to become a member) is submitted prior to (or with) the proposal.

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 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.

However, to help maintain a manageable process, 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. The purpose of the PAs is to encourage and enable Participants to work together to realize Initiative goals for the benefit of the broader OGC community.

1.1. Questions and Clarifications

Once the original CFP has been published, ongoing authoritative updates and answers to questions can be tracked by monitoring the CFP Clarifications page. Instructions for accessing this page are included under Proposal Submission Procedures.

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 on 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.

2. Proposal Evaluation Criteria

Proposals will be evaluated according to criteria that can be divided into two areas: Management and Technical.

2.1. Management Criteria

  • Bidder willingness and ability to comply with Appendix A Management Requirements,

  • Feasibility of proposed solution utilizing proposed resources, and

  • Proposed in-kind contribution in relation to proposed cost-share funding request.

2.2. Technical Criteria

  • Understanding of and compliance with requirements as stated in Appendix B Technical Architecture,

  • Quality and suitability of proposed design, and

  • Where applicable, proposed solutions are OGC-compliant.

3. Master Schedule

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

Table 1. Milestone schedule
Milestone Date Event

M01

June 2018

CFP Release

M02

10 July 2018

Bidder Questions Due

M03

17 July 2018

Bidders Q&A Webinar

M04

25 July 2018

CFP Proposal Submission Deadline

M05

10 August 2018

First Round of Bidder Notifications Started

M06

24 August 2018

Second Round of Bidder Notifications Started

M07

30 September 2018

All Participation Agreements Signed

M08

16-17 October 2018

Kickoff Workshop Event

M09a

30 November 2018

Initial Engineering Reports (IERs)

M09b

30 November 2018

NIST002 Public Safety Features CityGML ADE ER

M10

31 December 2018

Component Implementation Designs

M11a

31 January 2019

IER-to-DER status check

M11b

31 January 2019

TIE Connectivity Test

M11c

31 January 2019

Early implementations of any component on which another component depends

M12

28 February 2019

TIE Readiness Review

M13a

31 March 2019

TIE-Tested Component Implementations completed

M13b

31 March 2019

Preliminary DERs complete & clean, ready for internal Initiative reviews

M14a

30 April 2019

Near-Final DERs posted to Pending & WG review requested

M14b

30 April 2019

Ad hoc TIE demonstrations (as requested during the month) & Demo Assets posted to Portal

M15

May 2019 [Date TBD]

Final DERs (incorporating WG feedback) posted to Pending to meet 3-week rule for vote at June TC Meeting

M16

15 May 2019

Demonstration Event

M17

31 May 2019

Participant Final Summary Reports

M18

June 2019 [Date TBD]

Annual Public Safety Broadband Stakeholder Meetings

3.1. Sequence of Events, Phases, and Milestones

The following diagram provides a notional schedule of major Initiative events and milestones, and their approximate sequence of occurrence. The Initiative will consider using rolling-wave project planning whereby more detailed scheduling might take place as each milestone draws near.

Milestones
Figure 2. Overview of events and milestones

Participant Selection and Agreements:

Once the original CFP has been published, ongoing authoritative updates and answers to questions can be tracked by monitoring the CFP Clarifications page. Instructions for accessing this page are included under Proposal Submission Procedures.

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.

Kickoff Workshop: A Kickoff Workshop ("Kickoff") is a face-to-face meeting 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.

After the face-to-face Kickoff, most Initiative activities will be conducted remotely via web meetings and teleconferences until the Demonstration Event and other stakeholder meetings near the end of Initiative execution.

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. Participants will deliver an Initial Engineering Report (IER) plus several iterations of a Draft Engineering Report (DER). Full process details can be found in the ER Development Process.

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.

Component Design, Development, and Preliminary Testing: Participants will continue documenting detailed and final Component Interface Designs using the testbed collaboration tool (e.g., GitHub). This documentation will allow task Participants to confirm a mutual understanding of each other’s interfaces so that subsequent interoperability testing can take place. A preliminary Technology Integration Experiment ("TIE", sometimes also referred to as a "Technical Interoperability Experiment") Connectivity Test milestone will be used to ensure that Initiative service endpoints can be reached by Initiative clients.

TIE Readiness Review: A TIE Readiness Review will be conducted with the Initiative Architect to confirm that each TIE Participant is prepared to start conducting TIE testing with counterpart Participants.

Component Interoperability Testing, and Acceptance: Participants should deliver completed and fully TIE-tested component implementations no later than the TIE-Tested Component Implementations milestone (unless an earlier milestone is required under the Appendix B Technical Architecture). The primary acceptance criterion for a component implementation deliverable is the conduct and recording of the TIE test. This test can also prove useful in accelerating the development of demonstration assets such as video recordings.

Draft Engineering Reports: Participants should also deliver complete and clean Draft Engineering Report (DERs) by the Preliminary DERs milestone. A complete DER is one for which all major clauses have been populated with meaningful content. A clean is one where all known editorial defects have been repaired. This milestone will impact ALL Initiative Participants, even component implementers, who will be responsible for making necessary documentation material available to the ER Editor for use in authoring the ER. The Sponsor and Initiative Architect will review these DERs in the weeks following delivery.

DER Rework and SWG/DWG Reviews: Participants will be required to perform rework based on the reviews from the Sponsor and the Initiative Architect. The ER editor will then make a request to the selected OGC SWG or DWG to perform its review and to consider making a request that the DER be voted on by the OGC Technical Committee (TC) for publication. The OGC 3-week rule must be followed if the DER is to receive a vote at a TC Meeting. The DER must be posted to the members-only OGC Pending Documents directory to enable this TC vote. Participants will likely have to perform one final round of rework based on SWG/DWG feedback. The further along the DER is when submitted to the WG, the less rework will be required.

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 one year after the Participant Final Summary Reports milestone. OGC might be willing to entertain exceptions to this requirement on a case-by-case basis.

Detailed requirements for meeting all these delivery milestones are provided in Appendix A Management Requirements.

4. Summary of Initiative Deliverables

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

All Participants are required to provide at least some level of in-kind contribution (i.e., activities requesting no 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.

Some participation may be fully in-kind. However, to help maintain a manageable process, 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 of 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-Initiative-scope might be more appropriate for inclusion in a later OGC Innovation Program initiative.

Any item proposed as a fully in-kind contribution to meet a requirement already included in Appendix B Technical Architecture will likely be accepted if it meets all the other evaluation criteria and does not create an added burden on other Participants.

4.1. Summary of Technical Deliverables

The following table summarizes the full set of technical deliverables for this Initiative. Additional details can be found under Technical Deliverables. Management deliverables are described in Appendix A Management Requirements.

Table 2. Technical Deliverables
ID Technical Deliverable

NIST001

Building Data

NIST002

Public Safety Features CityGML ADE ER (specification needed by the IER milestone for use by the Building Modeler Service)

NIST003-I

Building Modeler Service I (1st instance)

NIST003-II

Building Modeler Service II (2nd instance)

NIST004-I

Navigation Modeler Service I (1st instance)

NIST004-II

Navigation Modeler Service II (2nd instance)

NIST005-CSW

Building Model Repository CSW

NIST005-WFS-T

Building Model Repository WFS-T

NIST005-3DPS

Building Model Repository 3DPS

NIST006-I

Indoor Navigation Service I (1st instance)

NIST006-II

Indoor Navigation Service II (2nd instance)

NIST007-I

Preplanning Tool Client I (1st instance)

NIST007-II

Preplanning Tool Client II (2nd instance)

NIST008

Presentation at PSBSM Meetings (mandatory for all Participants)

NIST009

Indoor Mapping and Navigation ER (general-purpose)

NIST010

Demonstration Video Assets (mandatory for all component providers)

 — 

 — 

< end of main body >

Appendix A: Management Requirements

This appendix presents detailed CFP management requirements for submitting a bid. It also covers procedures for participation during Initiative execution. The Appendix B Technical Architecture presents the detailed CFP technical requirements.

All potential Bidders should read this appendix carefully from end-to-end (and notify OGC immediately if any defects are discovered). There are significant differences as compared to prior solicitations. Bidders who are new to OGC Testbeds are also encouraged to review the Tips for New Bidders.

The following sections describe the processes for a Bidder to submit a proposal and for a Participant (i.e., a selected Bidder) to perform against a Participation Agreement (PA) contract. The order of topics roughly parallels the sequence described in the Master Schedule.

A.1. Proposal Submission Procedures

The process for completing an Initiative proposal is essentially embodied in an online Bid Submission Form. A summary is provided here for the reader’s convenience.

Once an online account has been created, the user will be taken to a home page indicating the "Status of Your Proposal." If any defects in the form are discovered, this page includes a link for notifying OGC. The user can return to this page at any time by clicking the OGC logo in the upper left corner.

Important

Because the online Bid Submission Form is still relatively new, it might contain some areas that are still brittle or in need of repair. Please notify OGC of any discovered defects. Periodic version updates will be provided as needed.

Please consider making backup local copies of all inputs in case any of them need to be re-entered.

Please also note that this form will "go live" soon after the CFP release date. Any submitted bids will be treated as earnest submissions, even those submitted well before the response deadline. Be certain that you intend to submit your proposal before you click the Submit button on the Review page.

Clicking on the Clarifications link will navigate to the CFP clarifications page.

On the far right, the Review link navigates to a page summarizing all the deliverables the Bidder is proposing.

Tip

Consider regularly creating printed output copies of this Review page at various checkpoints during proposal creation in case an input error is made later.

Once the final version of the information for all the proposed deliverables has been entered, the Bidder can submit the completed proposal to OGC by clicking the Submit button at the bottom.

Tip

In general, up until the time that the user clicks this Submit button, the proposal may be edited as many times as the user wishes. There no "undo" capability, however, so please use caution in over-writing existing information.

The user is provided an opportunity under Attached Documentation at the bottom of this page to attach collateral documentation (one document per proposal). This document could conceivably contain any specialized information that wasn’t suitable for entry into a Proposed Contribution field under an individual deliverable. It should be noted, however, that this additional documentation will only be read on a best-effort basis. There is no guarantee it will be used during evaluation to make selection decisions; rather, it could optionally be examined if the evaluation team feels that it might help in understanding any specialized (and particularly promising) contributions.

The Propose link takes the user to the first page of the proposal entry form. This form contains fields to be completed once per proposal such as names and contact information.

It also contains an optional Organizational Background field where Bidders (particularly those with no experience participating in an OGC initiative) may provide a description of their organization. It also contains a click-through check box where each Bidder will required (before entering any data for individual deliverables) to acknowledge its understanding and acceptance of the requirements described in this appendix.

Clicking the Update and Continue button then navigates to the form for submitting deliverable-by-deliverable bids. On this page, existing deliverable bids can be modified or deleted by clicking the appropriate icon next to the deliverable name. Any attempt to delete a proposed deliverable will require scrolling down to click a Confirm Deletion button.

To add a new deliverable, the user would scroll down to the Add Deliverable section and click the Deliverable drop-down list to select the particular deliverable of interest. For each proposed deliverable, the user will see a form like the following.

AddDeliverable
Figure 3. Form to Add a New Deliverable

The user would then enter the required information for each of the following fields (for this deliverable only). Required fields are indicated by an asterisk ("*"):

  • Estimated Projected Labor Hours (for cost-share request only)* for this deliverable; for an in-kind offer, please enter zero (0).

  • Total Dollar Funding Request (may cover labor hours only)*: total U.S. dollar cost-share amount being requested for this deliverable (to cover burdened labor only); for an in-kind offer, please enter zero (0).

  • Estimated Inkind Labor Hours (in addition to Projected Labor Hours)* to be contributed for this deliverable.

  • Estimated InKind Contribution (across all cost categories, not just labor)*: total U.S. dollar estimate of the in-kind amount to be contributed for this deliverable; this estimate may include all cost categories, and the amount should be at least as large as the Total Dollar Funding Request above.

Cost-sharing funds may only be used for the purpose of offsetting burdened labor costs of development, engineering, and demonstration of Initiative outcomes related to the Participant’s assigned deliverables. By contrast, the costs used to formulate the Bidder’s in-kind contribution may be much broader, including supporting labor, travel, software licenses, data, IT infrastructure, etc.

The field Proposed Contribution (Please include any proposed datasets) should be used to provide a succinct description of what the Bidder intends to deliver for this work item to meet the requirements expressed in Appendix B Technical Architecture. This language should include a brief elaboration on how the proposed deliverable will contribute to advancing the OGC technical baseline. It could also include a description of how end-user experiences or developer productivity will be enhanced. It could also identify any of the Bidder’s own data that it proposes to contribute. Additional details can be found under Data Contributions.

However, to help maintain a manageable process, Bidders are advised to avoid attempts to use the Initiative as a platform for introducing new requirements not included in 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-Testbed-scope might be more appropriate for inclusion in a later OGC Innovation Program initiative.

The statements of work (SOWs) in the Participation Agreement (PA) contracts will ultimately require performance during testbed execution against the deliverables as described in Appendix B Technical Architecture plus any subsequent Corrigenda.

To ensure that the full set of sponsored deliverables are made, OGC might negotiate with individual Bidders to drop and/or add certain deliverables from their proposals.

A.2. Conditions for Participation

A selected Bidder will become an Initiative Participant by executing a Participation Agreement (PA) contract with OGC, which will require the following conditions:

  • Each Bidder should use the Bid Submission Form to make their proposal.

  • Proposals from non-OGC-members will be considered provided that a completed application for OGC membership (or a letter of intent to become a member) is submitted prior to (or with) the proposal.

  • 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.

  • 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.

  • Bidders proposing to build interoperable components should be prepared to test and demonstrate interoperability with components supplied by other Participants. In particular, server-endpoints must be accessible over the public Internet during Initiative TIEs.

  • Participants selected to implement component deliverables will be expected to participate in the full course of interface and component development, TIEs, and demonstration support activities throughout Initiative execution. 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 send at least one technical representative per assigned thread to the Kickoff Workshop. Participants are also encouraged to send at least one technical representative to the Demonstration Event tentatively scheduled for May, 2019.

A.3. Proposal Evaluation and Invitations to Selected Bidders

Specific proposal evaluation criteria were presented earlier. Several process steps to be conducted by the IP Team are presented below to aid readers in understanding the overall process.

Soon after the proposal submission deadline, the IP Team and Sponsors will begin reviewing proposals, examining suitability of the proposed deliverables in light of the CFP requirements. During this analysis, the IP Team might need to contact Bidders to obtain clarifications and better understand what is being proposed.

At the Decision Technical Evaluation Meeting I (TEM I), the IP Team will present the Sponsor with draft recommendations regarding which parts of which proposals should be offered cost-share funding. The Sponsor may use this opportunity to suggest modifications.

The IP Team will notify each Bidder of their selection, including a description of the particular deliverables being offered, and OGC’s intent to enter into a Participation Agreement (PA) with them. Selected Bidders must be available for these contacts to be made to enable confirmation of continued interest. Bidder acceptance of the offer essentially locks in the scope that will be used to form the SOW to be attached to the forthcoming PA. A Bidder may reject the offer (for example, if the offer is to deliver only a small subset of its proposed deliverables).

A Decision Technical Evaluation Meeting II (TEM II) meeting will be conducted to review the outcomes of initial offers to selected Bidders, and any modifications that were needed due to Bidder rejections.

Following TEM II, the IP Team will develop the formal SOW and attach it to the full PA for each selected Bidder. Selected Bidders must be available to enable finalization of their PA contract.

Each PA will include a final identification of all assigned deliverables. The specific requirements that these deliverables must meet will be those documented in Appendix B Technical Architecture (plus any subsequent corrigenda).

Since this Initiative will potentially deal with the lowest maturity level of OGC standards technology, it will operate under the principle that “interoperable running code wins” (based loosely on an IETF founding belief).

In contrast with ordinary commercial contracts, which often focus on delivering a single-customer solution, the Participation Agreement contracts will encourage Participants to work in the broader interests of the OGC community. These interests are generally represented in the OGC Standards Working Groups (SWGs) and Domain Working Groups (DWGs). Testbed sponsorship enables a selected subset of these interests to be brought to bear on the production of interoperable running code and the reporting back of findings and recommendations as Change Requests (CRs) and document deliverables under the ER Development Process.

In general, at least one Participant will be assigned for each client-server pair as an Engineering Report (ER) Editor, who will be responsible for authoring the ER, though there might be exceptions. See General Requirements for Proposing Deliverables for details. The OGC ER Template will assist in the breakdown of content into a summary chapter, multiple chapters describing specific findings and recommendations, and supporting chapters (terms and acronyms, revision history, etc.).

Important

As compared to the ER Editor role in other OGC initiatives (e.g., testbeds), the ER Editors in this Initiative must adopt a more proactive approach to consuming and documenting the knowledge being generated during component implementation. In other words, ER Editors will serve as primary authors in addition to their editor role. All participants are required to support the editors by making necessary documentation material available.

OGC members who who are not selected to make any deliverables may still observe all Initiative activities by visiting the (members-only) OGC Observer Agreements page and registering to become an Initiative Observer. The Observer Agreement will require that Observers follow the same intellectual property protection rules as apply to other Initiative stakeholders (e.g., to avoid sharing other stakeholder’s confidential information with individuals outside the Initiative).

Initiative stakeholders should also avoid making any representations that any of the intermediate technical decisions made internally during Initiative execution reflect any sort of endorsed position of the OGC. Formal Initiative recommendations will become "official" once the containing ER has received approval to be made public.

A.4. Kickoff Workshop

Initiative execution will commence with a Kickoff Workshop event ("Kickoff"). In general, the Kickoff ensures a common Participant understanding of the overall Initiative architecture and of all interfaces relevant to their assigned deliverables. Under the Initiative’s rapid pace, and guided by the Initiative Architect, periods of development will be followed by synchronization among component developers, so that the likelihood of interoperation is maximized at each iteration. To maintain interoperability, each Participant should diligently adhere to the latest agreed specifications so that other Participants may rely on the anticipated interfaces in subsequent TIE testing.

Since Participants will be relying on one another to deliver interoperable components, all Participation Agreement (PA) contracts should be settled by the start of Kickoff. Any Participant that has not yet executed a PA by start of Kickoff will be required to attest to its commitment to a PA Statement of Work (SOW). The full PA must then be executed with OGC no later than Kickoff completion.

The Kickoff will include both plenary and breakout sessions. During the breakout sessions, 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 subsequent development work. This will ensure a mutual understanding of the detailed interfaces that will support component interoperability. The Kickoff will also present an opportunity to finalize regularly scheduled teleconferences ("telecons").

All selected Participants must send at least one technical representative to the Kickoff Workshop, and a representative should be present at all the breakout sessions.

Important

In-person attendance at these breakout meetings has been found to be critical to later Initiative success. Remote attendance will not be an option.

These requirements will also apply to Participants not requesting any cost-share funding (i.e., purely in-kind contribution) since their deliverables are still being relied upon by other Participants.

A.5. Participant Communication and Reporting

A.5.1. Points of Contact

Each selected Participant should designate a primary point of contact ("Primary POC") who shall remain available throughout Initiative execution for communications regarding status. The POC should identify at least one alternative point of contact to support the Primary POC as needed. The POCs should provide contact information including their e-mail addresses and phone numbers.

All proposals should include a statement attesting to the POCs’ understanding and acceptance of the duties described herein. This statement will be enabled by a simple check-box in the Bid Submission Form.

A.5.2. Kickoff Status Report

Selected Participants should provide a one-time Kickoff Status Report that includes a list of personnel assigned to support the Initiative, and assurance that the Participant understands the schedule for all of its deliverables. This report should be submitted in electronic form to a designated email address no later than the last day of the Kickoff event.

A.5.3. Monthly Progress Reports

Participant Business and Technical POCs should provide, respectively, monthly business and technical progress and status reports due on the 3rd of each month (or the first working day thereafter) and covering the previous month.

Monthly Technical Reports will be accessible to all Testbed Stakeholders and should contain no confidential information (e.g., labor rates). Monthly Business Reports may contain confidential information and should be sent only to the specified email address.

Any Participant who has a reliable forecast of what will take place in the remaining days of any particular reported month may submit its report early and subsequently report any urgent, last-minute updates via a follow-on email.

Detailed monthly reporting requirements and procedures will be provided during PA contract negotiation. It is likely that the Portal-based Actions feature (used in several testbeds) will be used for monthly technical reporting.

The Initiative Architect will review action item status on a weekly basis with assigned Participants, who should be available for these contacts to be made. Additional details regarding project management activities during Initiative execution can be found at Project Monitoring and Control.

As a preview, monthly technical reports will likely require the following information for each deliverable:

  • Deliverable ID and Name

  • Health: G, Y, R (green, yellow, red)

  • %complete (0%-100%)

  • Work accomplished in reporting period (last month)

  • Work anticipated in reporting period+1 (current month)

  • Any known risks or issues (see definitions under Project Monitoring and Control)

  • Response to mitigate the risk or remedy the issue

A.5.4. Final Summary Report

Participants should provide a Final Summary Report near the end of Initiative execution. Detailed requirements and procedures will be provided during PA contract negotiation. These reports will likely require the following information:

  • Describe, in detail, the work completed to fulfill the PA SOW items,

  • Summarize Participant’s overall contribution to the project, and

  • Present recommendations for future OGC Innovation Program and Standards Program efforts.

Any timely Participant who is up-to-date with all the Monthly Technical Status Reports in the Portal will likely be permitted to optionally satisfy the first "in detail" requirement by merely referencing the detail already contained in the Monthly Technical Reports. Timely Participants may also be permitted choose to build their Final Summary Report in the body of an email if desired (or, alternatively, submitted as a document attachment).

A.5.5. Regular Teleconferences

At least one of Participant Technical POC should be available for regularly scheduled telecons. Records will be kept in meeting minutes and/or GoToMeeting recordings.

These telecons are intended to accelerate understanding and action regarding relevant Initiative activities, particularly status of any risks or issues that might block or are blocking progress toward timely delivery.

Participants assigned as ER Editors may, with permission from the Initiative Architect, lead the substantive discussions during any ad hoc or regularly scheduled telecons.

A.5.6. Correspondence and Collaboration

Participants should be able to utilize the following correspondence and collaboration tools:

A.6. General Requirements for Proposing Deliverables

In general, Participants will be required to make deliverables meeting the requirements stated in CFP Appendix B Technical Architecture.

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. As compared to the ER Editor role in other OGC initiatives (e.g., testbeds), the ER Editors in this Initiative must adopt a more proactive approach to consuming and documenting the knowledge being generated during component implementation. In other words, ER Editors serve as primary authors in addition to their editor role. All other participants are required to support the editors by making necessary documentation material available.

In addition, component implementers (Participants selected to deliver component implementations) will be responsible for contributing completed technical artifacts for inclusion as ER annexes. These include UML diagrams, XML schemas and instances, and abstract test suites, all of which have their own specialized clauses in the ER Template. Component implementers will also be required to contribute Demo Assets, video recordings of component operation.

ER Editors will be responsible for observing the component implementation work and documenting (in the assigned ER) all findings and recommendations (except the technical artifacts identified above). They will also be responsible for ensuring the document’s overall integrity, authoring summary material and ensuring that global sections (e.g., References, Terms, Revision History) have all been completed.

ER Editors will also be responsible for enabling all required ER reviews (and subsequent rework), including internal reviews by the Initiative Architect and the Sponsor, as well as requests for reviews by an appropriate OGC Standard Working Group (SWG) or Domain Working Group (DWG).

ER Editors will also be responsible for creating (and referencing) any Change Requests (CRs) arising from the work described in the assigned ER. CRs can be created using the OGC CR system.

A.7. Specific Requirements for Proposing Document Deliverables

The primary acceptance criterion for a document deliverable (i.e., an ER) will be approval from the Initiative Architect to post the document to an OGC (members-only) folder called the OGC Pending directory. Permission to post will not be granted until the full ER Development Process has been followed, including the step to request a review from an OGC SWG or DWG. All appropriate tooling should also have been utilized (ER Template, Asciidoc, GitHub), and the document should have achieved a satisfactory level of consensus among all assigned Participants.

A.8. Specific Requirements for Proposing Component Implementation Deliverables

In general, prototype component implementation deliverables (including services, clients, datasets, and tools) will be provided by methods suitable to its type and stated requirements. A service (e.g. a WFS instance or even an intermediary component) will be delivered by deployment for use in the Initiative via an accessible URL. A client will be used to exercise a service to test and demonstrate interoperability. Components will be developed and deployed for integration and interoperability testing in support of the agreed-upon scenario(s) and technical architecture. The Kickoff will provide the opportunity to establish many of the agreed-upon details.

More specifically, the first acceptance criterion for any component implementation deliverable will be a successful demonstration of capability in a Technology Integration Experiment ("TIE") test.

The next acceptance criterion will be assurance that the relevant ER Editor has access to sufficient documentation material to record all findings and recommendations in the ER and associated CRs.

Another criterion will be evidence that the implementer has directly authored full ER content for any relevant Abstract Test Suite (ER Template Annex A), XML Schema Document (ER Template Annex B), or UML Model (ER Template Annex C).

A Participant assigned to deliver a client component implementation must, in addition, record TIE test execution (as evidence of delivery) and must create Demonstration Video Assets.

A Participant assigned to deliver a service component implementation should, in addition, provide assurance that the service endpoint will remain available to OGC and the Sponsor for a period of no less than one year after Initiative execution. OGC might be willing to entertain exceptions to this requirement on a case-by-case basis.

Some requirements might request delivery of a packaged prototype component (e.g., using a virtual machine or container). Consult the specific language in the Appendix B Technical Architecture for details regarding these requirements.

A.8.1. Contributions of Additional Data

The Initiative itself will be providing Building Data as one of the deliverables. But a Bidder may also propose a contribution of another suitable dataset (or a reference to third-party data that could be freely acquired).

A.9. Project Monitoring and Control

Initiative execution monitoring and control will follow an encapsulation principle. As long as a Participant continues [1] supporting activities on which other Initiative stakeholders are relying (e.g., telecons, TIEs, ER inputs) and [2] making timely delivery of their own deliverables, the question of what’s "going on" inside the Participant organization will likely not be raised.

Otherwise, any issues (or risks) that block (or threaten to block) timely delivery will enter a remediation status requiring the following responses:

  • Development, implementation, and reporting of a credible mitigation or recovery response to get back on track,

  • Recording in the Monthly Participant Technical Status Report a "Red Flag" Action Status indicating that the deliverable is in remediation (plus either "Red" or "Yellow" health in the Action Description),

  • Notification of the Initiative Architect, who will review the recovery plan and report status to the Initiative Director and Sponsor.

The following definitions will be used to communicate and track deliverable status:

  • For purposes of this Initiative, a risk can be defined as any uncertain future event that has a sufficiently high exposure to threaten Participants' ability to make on-time delivery of the promised deliverable scope.

  • An issue is a risk that has actually occurred (no longer any uncertainty surrounding whether it will occur or not).

  • A mitigation response is one that reduces a risk’s exposure (e.g., finding an alternative source for meeting a data dependency).

  • A recovery response is one that remedies the damage caused by the issue (e.g., getting the deliverable back on schedule or being excused from delivery of some particular requirement).

  • A deliverable whose timely delivery is threatened should have an overall status of being in remediation and should reflect a Red or Yellow health.

  • A Red deliverable health is appropriate when the response has not yet been created and agreed, or it has been created and agreed but is not believed to be sufficient to make timely delivery.

  • A Yellow deliverable health is appropriate when the response has been created and agreed, and is in the process of execution (but not yet fully completed).

  • Once the response has been fully completed, the deliverable health should return to Green and the deliverable would no longer be considered in remediation.

In general, risks and issues will be monitored and managed by the Initiative Architect, who will report ongoing status to other stakeholders.

A.10. 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 memorialized and delivered for inspection and use.

  • The roles generally played in any OCG 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.

  • 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 a Testbed 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 third-party 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 PAs will not require delivery any component source code to OGC.

    • What is delivered instead is the behavior of the component in the TIEs, and the corresponding documentation of findings, recommendations, and technical artifacts in the related ER(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.

< end of appendix >

Appendix B: Technical Architecture

This appendix provides background information on the OGC baseline, describes the Pilot architecture, and identifies all requirements and corresponding work items. For Initiative administrative information, including deadlines, funding requirements and opportunities, please refer to the CFP Main Body.

B.1. Pilot Baseline Architecture

B.1.1. Types of Deliverables

The Pilot requires several types of deliverables, which are summarized in the CFP Main Body and described in detail below. Each assigned deliverable should also be made according to the Appendix A Management Requirements.

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.

Important

Participants delivering Engineering Reports should also deliver Change Requests that arise from the documented work.

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 WFS instance) are delivered by deployment of the service or component for use in the Testbed via an accessible URL. A Client software application or component may be used during the Testbed 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.

B.1.2. 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 Testbed. 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.

rmodp
Figure 4. 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.3. 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. For this Initiative, it is emphasized that all OGC members have access to the latest versions of all standards.

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.4. 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.1.5. Data and Cloud Services

Participants are encouraged to provide data that can used for the Initiative. An interested Participant should provide a detailed description of the offer in its proposal. Participants are also encouraged to provide data or services hosted in the cloud where appropriate.

B.2. Details of Technical Deliverables

The following subsections provide details surrounding the technical deliverables for this Initiative. Management deliverables are described in Appendix A Management Requirements.

1. Create and convert 3D indoor LiDAR point cloud models to functional building and navigation models.

NIST001: Building Data – Using a mobile 3D LiDAR survey instrument and 360 degree camera of sufficiently high quality, create a 3D point cloud model of the indoor and outdoor of a test building or buildings. The test building(s) shall be sufficiently large and complex to adequately test the dependent deliverables (e.g. airport, large apartment complex, manufacturing facility, etc.). The dataset should have a global accuracy of 5cm and be delivered in LAS file format.

NIST002: Public Safety Features CityGML ADE (special-purpose ER) – Define a Public Safety Features CityGML application domain extension (ADE) based on the reference preplan symbology created by the National Alliance for Public Safety GIS (NAPSG). The ADE should be documented as a CityGML 2.0 Schema and described in this ER. One or more corresponding Change Request(s) should be submitted to the CityGML SWG.

Important

The specification contained in this ER will be needed by the (early) M09Bb milestone for use by the Building Modeler Service.

NIST003: Building Modeler Service – Create a building modeler application that can convert point cloud models and associated images (such as those generated by the Building Data) into semantic 3D building models compliant with the most recent or stable version of CityGML (2.0). Models generated by this component will be notated with Public Safety Features from the CityGML ADE. The building modeler may be developed as a web processing service (WPS) compliant with the OGC WPS 2.0 Interface Standard (OGC14-065), though this is not a strict requirement.

NIST004:Navigation Modeler Service – Create a navigation modeler application that can convert output from the Building Modeler Service to IndoorGML usable for indoor navigation. The navigation modeler may be developed as a web processing service (WPS) compliant with the OGC WPS 2.0 Interface Standard (OGC14-065), though this is not a strict requirement.

2. Store and serve point cloud, building, and navigation models for visualization and navigation.

NIST005: Building Model Repository – Create a building model repository to store and serve point cloud, building, and navigation models (see Building Data, Building Modeler Service, and Navigation Modeler Service). The repository should expose a model catalog and provide authenticated access. The repository should be interoperable with application clients leveraging the OGC Web Feature Service (WFS) Interface Standard (OGC 09-025r2) and the OGC 3D Portrayal Service (3DPS) Standard.

3. Derive dynamic turn-by-turn indoor navigation instructions based on the navigation model.

NIST006: Indoor Navigation Service – Create an indoor navigation service that can derive ‘turn-by-turn’ instructions between any two points in a building, including exits, based on models created by the Navigation Modeler Service. The service should be able to integrate a variety of navigation algorithms, not necessarily developed in this Initiative, optimized for specific criteria (e.g. routes optimized based on time, distance, or risk) requested by the Preplanning Tool Client. While not a requirement for this Initiative, the solution should be developed keeping in mind the dynamic, real-time requirements that navigating during a real public safety response will impose upon the service. The service should use the OGC WFS Interface Standard. WFS should also be leveraged to request scenes from the model repository that can be provided via 3DPS format.

4.View and annotate point cloud and building models, along with navigation routes and instructions into, through, and out of buildings.

NIST007: Preplanning Tool Client – Create a visualization client application for users to request and view point cloud data and building models from the Building Model Repository, as well as navigation instructions and routes from the Indoor Navigation Service. The client should have a graphical user interface that enables public safety personnel to view and annotate models captured during preplanning. The client should seamlessly transition between 2D and 3D views and should allow users to visualize hypothetical routes into, through, and out of buildings along with the appropriate metrics (e.g. estimated time, distance, risk, etc.) based on additional input parameters considered by the navigation service. The client should use the OGC WFS Interface Standard and OGC 3DPS to request and receive models, scenes, and services.

5.Meetings, Demos, and Presentations.

NIST008: PSCR Presentation (mandatory for all Participants) – Participate in the 2019 PSCR (Sponsor) Annual Public Safety Broadband Stakeholder Meetings (PSBSM) to present Initiative results. The PSBSM meetings are held each June in the continental United States and are typically four days in length. The dates and venue for the 2019 PSBSM will be finalized at a later date.

NIST009: Indoor Mapping and Navigation ER (general-purpose ER) – This ER should describe the architecture, software, interfaces, and data formats developed during the Initiative.

NIST010: Demonstration Video Assets (mandatory for all component providers) – These videos should capture demonstrations of the individual deliverables and the end-to-end workflow developed for preplanning operations. They should be suitable for executive-level briefings to be shown at various demonstration events near the end of the Initiative.

The following figure illustrates a possible flow of requests and data among the components.

Indoor Overview
Figure 5. Possible data flow among components

Bidders are permitted to elaborate on these high-level flows to provide further detail in their proposals so long as the general nature of the CFP preplanning requirements is preserved.

Then during Kickoff breakout sessions, Participants (guided by the Initiative Architect) will refine this architecture and settle upon specific use cases and interface models to be used as a baseline for subsequent development work. This will ensure a mutual understanding of the detailed interfaces that will support component interoperability.

< end of appendix >