Indoor Mapping and Navigation Pilot Call for Participation (CFP)

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.

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.

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.

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.

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.

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.

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.

< end of main body >

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.

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.

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.

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.

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 ("*"):

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 selected Bidder will become an Initiative Participant by executing a Participation Agreement (PA) contract with OGC, which will require the following conditions:

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

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.

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.

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.

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.

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.

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.

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:

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

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

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

< end of appendix >

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.

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.

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 >