cartome.org

6 February 2002

Multi-Hazard Mapping Initiative (MMI)
Request for Quotation (RFQ): Released - 24 October 2001, Due - 21 November 2001

The Multihazard Mapping Initiative, Phase 1 (MMI-1), sponsored by the US Federal Emergency Management Agency (FEMA), will establish a standards-based framework of interoperable services to illustrate the advantages of using products with OGC interfaces to access, fuse and visualize critical spatial information in support of FEMA multi-hazard mitigation, response and recovery functions.

A multihazard advisory map is a map on which hazard data (flood, hurricane, severe winds, and seismic) is identified showing areas of overlap. These maps will be made available to the appropriate State and local governments for informing the general public about hazards and to support activities for mitigation purposes and other public uses. FEMA recognizes the critical need for standards-based frameworks to support multihazard advisory map publishing, dissemination and integration efforts. By implementing interoperable services based on OGC interfaces, FEMA will be able to operationally demonstrate an interoperable framework for publishing, finding and accessing hazard advisory maps from multiple sources and displaying them in a common environment.

The Multi-hazard Mapping Initiative is a multi-phase initiative mandated by section 203 (k) of the Disaster Mitigation Act of 2000. That statute requires that FEMA develop the initiative in conjunction with state and local governments and the appropriate Federal agencies.

Request For Quotation

And

Call For Participation

in the

Multi-hazard Mapping Initiative

Phase 1 (MMI � 1)

RFQ Issuance Date: October 24, 2001

Proposal Due Date: November 21, 2001

Table Of Contents

2 Context *

3 Your Role in the Testbed *

4 RFQ Submission Information *

5 RFQ Format and Content *

Annex A: MMI - 1 Requirements and Work Breakdown Structure

1. Introduction

1. Purpose

The purpose of this Request For Quotation (hereafter referred to as RFQ) is to solicit your proposal in response to a refined set of requirements for the OpenGIS Consortium (OGC) Multi-hazard Mapping Initiative, Phase 1 (MMI-1) Project. Please see Annex A and B of this RFQ (http://ip.opengis.org/mmi1) for details of the Project. This request is issued as an RFQ for two reasons. The first reason is that the OGC in collaboration with the Federal Emergency Management Agency (FEMA) is providing cost-sharing funds to partially offset expenses uniquely associated with the initiative. The second reason is that the OGC intends to involve multiple participants in the initiative and thus is soliciting contributory proposals that will enhance and/or make use of the MMI-1.

2. Background

FEMA and the OGC have successfully cooperated on the OGC Web Mapping Testbed, Phase 2 (WMT-2) resulting in new OGC standards for interoperability and prototype commercial capabilities that implement those standards. FEMA now wishes to conduct an OGC Interoperability Initiative designated the Multi-hazard Mapping Initiative, Phase 1 (MMI-1). This initiative will promote the collaborative development, testing, and demonstration of an interoperable, Web-based multi-source hazard information framework prototype based on OGC standards for interoperability. This framework will serve as the mechanism for the publication, access, and viewing of FEMA Multi-hazard map data to appropriate state and local agencies.

The Multi-hazard Mapping Initiative is mandated by section 203 (k) of the Disaster Mitigation Act of 2000. That statute requires that FEMA develop the initiative in conjunction with state and local governments and the appropriate Federal agencies. To that end, the participation of the Multi-hazard Mapping community is encouraged through the MMI-I Community Advisory Group (CAG). Participation in the CAG is open to state and local leaders as well as federal agency representatives who have�

• A working knowledge of their information systems architecture and applications of geospatial information within those systems;
• Experience in the use of GIS as a tool to facilitate planning and policy development;
• Interest in participating in the design of systems for delivering spatial hazards data via the Internet

If your organization is interested in participating in the CAG activities, but not in the technical specification and component development activities of this initiative, please do NOT submit a proposal to this RFQ. To indicate your interest in participating in CAG activities, please contact:

All others should submit a proposal to support this RFQ.

1. The RFQ Process

The MMI-1 Initiative Management team (consisting of OGC and the sponsors) has established an initial set of sponsor requirements. A Work Breakdown Structure intended to achieve the requirements is presented in Annex A. A Concept of Operations for the MMI-1 is attached as Annex C. This Concept of Operations describes the detail needed to understand the planned operation of the initiative for a suitable response to this RFQ.

This RFQ is being released to the OGC community. It requests support for broader OGC interoperability objectives on a voluntary basis. Specifically, any organization is invited to contribute to the design of the capability identified in the effort and explore architectural alternatives, performance characteristics, and ease of application development as direct input into the technology development activity of the OGC. Participants will also be asked to examine the probable direction of the industry, propose evolutionary (or revolutionary) models for multi-hazard mapping, and identify associated alternatives for study during the course of the initiative.

All organizations interested in participating in the Initiative effort shall respond with a proposal. Instructions for submitting proposals are provided in Section 4. Annex A provides requirements and the WBS to guide the development and structure of responses. Annex C contains the Concept of Operations, which describes how the proposals will be analyzed, how to revise the initiative, and other details associated with the process of determining participants in the initiative. All participants should recognize that this does not reflect a change in OGC philosophy relative to reimbursing members for their support of OGC initiatives. The limited cost-sharing funding available is intended to help partially offset engineering costs incurred by participants in support of this effort.

Each organization with a role in the initiative will sign a contract and statement of work or a statement of participation with OGC that outlines roles and responsibilities of each participant. By doing so, participants will agree to work together for the realization of the initiative goals and for the benefit of the industry.

2. Benefits to Participants

OGC perceives the Multi-Hazard Mapping Initiative as a prime opportunity for vendors, users, and other interested parties to mutually define services, interfaces and protocols (and thus candidate interoperability specifications) in the context of a hands-on engineering experience expected to shape the future of geospatial multi hazard mapping services software development. The sponsors are backing their belief in this vision with cost-sharing funds to partially offset development costs associated with this capability. This offers OGC members a unique opportunity to recoup a portion of their expenses related to the MMI-1. Another benefit is that this effort has well-defined objectives, while providing a significant opportunity to explore alternatives in a unique hand-on engineering context.

1. Context

The MMI-1 sponsor has worked with OGC to outline specific requirements for the project. These requirements are outlined in Annex A and B (http://ip.opengis.org/mmi1).

1. Open GIS Consortium

This RFQ assumes the recipient is not only familiar with the OGC mission, organization, and process, but is an OGC member. Furthermore, because this effort is a fielding of WMT-1, USL, WMT 2, GFST-1, MPP1, and OWS-1 technology, the recipient should have been a participant in one or more of these efforts. Non-member proposals will be considered only if a completed application for OGC membership accompanies or precedes the proposal. Non-WMT-1, USL, WMT 2, GFST-1, MPP1, or OWS-1 participant proposals will be considered only if a credible proposal for the development of appropriate technology is included. 

2. Your Role in the Testbed

There are several possible roles that organizations may play in the MMI-1. These are listed as tasks in the Annex A of this RFQ.

3. RFQ Submission Information

1. General Terms and Conditions

Documentation submitted in response to this RFQ will be distributed to members of OGC staff, the IP Team, and sponsor staffs. Submissions will remain in the control of this group and will not be used for other purposes without prior written consent of the proposing organization. Please note that you will be asked to release the content of your proposal (less financial details) once you agree to participate in the effort. Proprietary and confidential information must not be submitted under this request.

Participants will be selected to receive cost sharing funds on the basis of adherence to the requirements stipulated in this RFQ and the overall quality of their proposal. The primary objective of MMI-1 Sponsors is to use cost sharing funds to promote the development of a Standards-based framework for the publication and visualization of multihazard mapping data and Standards-based Commercial-Off-The-Shelf (SCOTS) components for demonstration purposes. Those proposing organizations not selected for cost sharing funds are encouraged to participate in MMI-1 on an in-kind basis.

Each participant will be required to enter into a contract with OGC. This agreement will define participant responsibilities, and by signing the contract all participants will agree to work together towards the common goals of the initiative. Further details on this issue are found in the Concept of Operations (Annex C).

2. Submission Instructions

Submissions to this request shall be "complete"; i.e., your submission must provide all information requested in section 5 to be considered further. PLEASE KEEP YOUR PROPOSAL TO LESS THAN TEN (10) PAGES TOTAL INCLUDING THE COVER PAGE.

3. How to Submit

Electronic responses to this RFQ should be sent to the OpenGIS Technology Desk (techdesk@opengis.org). Microsoft Word® 6.0 or higher format is preferred; however, Portable Document Format or Rich Text Format is acceptable.

Hardcopy responses to this RFQ (and other communication regarding this RFQ) should be sent to:

Regular mail OpenGIS Technology Desk

or Express packages: Open GIS Consortium, Inc.

4899 North Old SR 37

Bloomington, IN 47408-9239

USA

Proposals must be received at OGC no later than 1:00 PM EDT 21 November 2001. The subject of electronic mail submissions or any other communication regarding this RFQ should be clearly marked "OGC MMI-1 RFQ".

4. Questions and Clarifications

Questions and requests for clarification should be sent electronically to the MMI Initiative Manager, Charles Heazel, (cheazel@opengis.org), by mail to the address in section 4.3, or by facsimile transmission (+1 703-669-6763). All clarifications will be posted to the OGC WWW Site (http://ip.opengis.org/mmi1/index.html) and to the OGC Technical Committee electronic mail reflector.

5. Reimbursements

The OGC will not reimburse submitters for any costs incurred in connection with preparing proposals in response to this RFQ.

6. Schedule

The following table details the events and activities associated with this RFQ (more details can be found in Annex C):

RFQ Issued	24 October, 2001
RFQ Responses Due	21 November, 2001
Selected Participants Notified	5 December, 2001
MMI Kickoff	10-11 December, 2001
MMI CAG Kickoff	10 January, 2002
MMI-1 Initial Capability Demonstration	15 February, 2002
MMI-1 Final Capability Demonstration	29 March, 2002

4. RFQ Format and Content

1. Proposal Outline

As part of this RFQ archive you will find several templates: the response template, the cost sharing request spreadsheet template, and the in-kind contribution spreadsheet template. Proposing organizations shall use these templates in preparing their proposals. The proposal should follow the outline:

• Cover page
• Overview
• Proposed contribution
• Proposed contribution cross referenced to WBS
• Level of Effort
• Cost sharing request (Excel template for reporting costs is archived with the RFQ)
• In Kind contributions (Excel template for reporting in-kind contributions is archived with the RFQ)

Each of these Sections is described below.

1. Cover Page

Provide the name(s) of the proposal submitter(s) and point of contact information. Teams should list all teammates and point of contact information for each. When submitting point of contact information, please provide both a business/financial and technical point of contact.

2. Overview

Provide an introduction to the contents of your proposal and its benefits.

3. Proposed Contribution

Describe your proposed contribution to the initiative based on the tasks outlined in Annex A. Your description of your contribution should take into account the architecture described in Annex B and the requirements listed in Annex A section 2.

1. Specification Development

If you are proposing to contribute to the development or support of the development of interoperability specifications for interfaces, operations, encodings, messages, or other relevant technologies, please indicate your views on the Architecture and the modifications/additions you would recommend MMI-1 pursue during the course of the initiative. Also indicate what personnel you would assign to these tasks and what background experiences qualify them to support this key activity.

2. Component Development

If you are proposing to contribute to the development of components within the Architecture, please include in your proposal as much detail as possible concerning the operating system, hardware, programming language, and proprietary software requirements or constraints that relate to your proposed development effort. Please provide the SCOTS migration path for proposed components.

 

Please also address the method of deploying the MMI-1 created component. This will include posting software solutions on the OGC web site or on one of the sponsors site. The posted solution will be available for use by participants, sponsors, and properly certified observers.

3. Demonstration or Test Development

If you are proposing to develop demonstrations or tests, please provide as much detail as possible concerning your proposed effort. Delineate aspects of the sponsor scenarios to which you believe you can contribute. In particular explain how your work will show the sponsor's desired level of interoperability.

Do not assume a single vendor demonstration; rather the demonstration will be showing how your technology can interoperate with other participant�s technology.

4. Data

If you are proposing to contribute data to the effort, please indicate the format of the data (if applicable) and any proprietary software access requirements (if applicable). Please include the geographic coverage of the data, a thematic description of the data, geodetic context of the data and any other relevant metadata. Please also indicate alternate formats or access capabilities that you are willing to support, if necessary. Match your data contribution with Annex B.

Please also address the method of deploying the MMI-1 data. This will include posting data on the OGC web site or on one of the sponsors site. The posted data will be available for use by participants, sponsors, and properly certified observers.

5. Personnel

If you are proposing to contribute personnel to the initiative, please indicate the capabilities and experience of the personnel, location and mobility information (in other words, will the personnel need to remain at their present location? Will you support travel?). Indicate which personnel would be able to participate in kickoff activities and other site activities.

6. Facilities

If you are proposing facilities, please include as much detail about the configuration of hardware and software at the facility, the network access and restrictions (if any), and the level of operational support in place at the facility. Please provide information about your organizational approach to configuration management.

7. Hardware

If you are proposing to contribute hardware to the effort, please include a complete description of the hardware.

8. Software

If you are proposing to contribute software to the effort, please include a complete description of the software. You must include information about the operating environments that you intend to support in the context of the testbed.

4. Proposed Contribution Cross Referenced To WBS

Review the WBS found in Annex A and map your proposed contribution to the task categories and items found there. Indicate which requirements are being met with your contributions in the descriptions of activities that your organization proposes to undertake. This cross reference should include a description of your contribution (or a descriptive name).

5. Level of Effort Estimate

Please provide an estimate of the value of your proposed contribution, including engineering, management, communications, travel, and so forth. Please begin this section on a new page so that it can be separated from the main body of your proposal.

6. Cost-Sharing Request

This section is required only from proposing organizations requesting cost sharing funds. Please provide a requested amount of cost-sharing funds (in US Dollars) and provide details of the costs that are being offset (e.g., labor category, number of hours, and hourly rate). Note that the sponsors intend to provide cost-sharing funds for only those activities uniquely attributable to initiative participation; e.g., a recipient should not request funds to offset costs that would have otherwise been incurred and funded through some other source such as internal research and development funding. This section must include a certification that the proposed reimbursable costs would not be otherwise incurred in support of non-initiative activities. Use the attached cost-sharing template to itemize the costs being offset. This should be included in the section beginning with Level of Effort Estimate.

7. In-Kind Contributions

Please provide an indication of the in-kind contributions that your organization will make to the MMI-1 initiative. This should reflect such contributions as labor, equipment, software, or data. Use the attached in-kind contribution template to itemize the contributions being provided. The sponsors and OGC will use this information in the development of future initiatives. This should be included in the section beginning with Level of Effort Estimate.

Annex A�MMI-1 Requirements and

Work Breakdown Structure

RFQ Issuance Date: October 24, 2001

Proposal Due Date: November 21, 2001

Table Of Contents

Annex A: MMI-1 Requirements and Work Breakdown Structure *

1 Introduction *

2 Sponsor Requirement Priorities by Tier *

3 Interoperability Initiative Process Framework *

4 MMI-1 Work Breakdown Structure (WBS) *

Annex A: MMI-1 Requirements and Work Breakdown Structure

1. Introduction

This document describes the MMI-1 Requirements segregated by sponsor priorities and the Work Breakdown Structure for Multi-hazard Mapping Initiative.

2. Sponsor Requirement Priorities by Tier

The requirements for the MMI-1 framework are a subset of the requirements being addressed in the OGC Web Services, Phase 1 (OWS-1) initiative. For more information on the OWS-1 initiative, go to http://ip.opengis.org/ows1. Participants are expected to leverage the work being done under OWS-1 to develop an open framework supporting the publication, discovery, and visualization of Multi-hazard map data. The following table shows the OWS-1 Requirements segregated by sponsor priorities. Those that have a Tier 1 priority are the only requirements that will be funded by the sponsors for this Multi-hazard Mapping Initiative Request for Quotation. Those requirements having a Tier 2 priority, while not funded in this RFQ, may be funded in a subsequent RFQ. Those having a Tier 3 priority have not been selected for funding by any sponsor at this time.

Prospective participants should propose for cost sharing funds only against Tier 1 requirements. Only submissions (or relevant sections thereof) that address Tier 1 requirements will be considered for cost sharing funds. Any submission (or relevant section thereof) that addresses Tier 2 or Tier 3 requirements will be viewed and treated as proposed in-kind contributions by the proposing organization.

I. Common Architecture
Multi-hazard Mapping Initiative Model
1. Basic Services Model/ General Services Model	Tier 1
2. Service chaining	Tier 2
Common Encodings - GML and 4D
3. GML - Temporal	Tier 2
4. GML - Topology	Tier 2
5. GML - Compound Geometry	Tier 2
6. GML - 2D/3D curves and surfaces	Tier 2
7. GML - Arc interpolations and conics	Tier 2
8. GML - Polynomial splines	Tier 2
9. GML - Solids	Tier 2
10. GML - convergence with G-XML, from Japan	Tier 2
Common Encodings - Location Organizer Folder
11. LOF	Tier 3
Common Encodings - Annotations
12. XIMA - graphic/text overlays (e.g. for imagery)	Tier 3
Encodings - Coverages
13. XML for imagery (GML Coverages)	Tier 3
General Registries Model
14. Service registries - for service discovery	Tier 1
15. Type registries - for data sharing, information communities	Tier 2
16. Schema registries - for data sharing, information communities	Tier 2
17. Information community registries - for data sharing, information communities	Tier 2
18. Data registries - for data discovery	Tier 1
Other
19. Security	Tier 2
20. Ground coordinate transformation services	Tier 2
II. Web Mapping
Data Servers
21. Web Map Server	Tier 1
22. Web Feature Server	Tier 1
23. Web Coverage Server	Tier 2
Display related (including Viewers/Interacters)
24. Perspective viewer	Tier 2
25. Styled Layer Descriptors (SLD)	Tier 1
26. Symbol Management	Tier 3
27. XSLT Translators to support variable symbolization reqmts; stylized graphics	Tier 3
GML Tools
28. Conformance tools	Tier 2
29. Thin Client Editor API	Tier 2
III. Web-based Imagery Exploitation
30. Imagery Clients	Tier 1
31. Image chains - service chaining	Tier 3
32. Change detection	Tier 3
33. Triangulation service (analytical block adjustment)	Tier 3
34. Ortho production service and Position Integrity	Tier 3
35. Image catalog service - related to Data Registry	Tier 3
36. Image archive service - related to WCS	Tier 3
37. Image section retrieval service - chipping	Tier 3
38. Image mosaic service and Position Integrity	Tier 3
39. Image, Image-Ground Coordinate Transformation Services	Tier 3
IV. Sensor Web Enablement
40. Sensor Registry	Tier 2
41. Sensor Markup Language	Tier 2
42. Sensor Collection Service - collecting real-time readings from distributed sensors	Tier 2
43. Sensor Tasking/ Scheduling - the tasking function for distributed sensors	Tier 2
44. Real-time Sensor Control and Management Clients	Tier 3
45. Sensor Geolocation Service - real-time time target geolocation service; determine the coord of a mobile target	Tier 2
46. Collection opportunity access generation - given one or more ground target positions that one wishes to collect against, predict the access/collection opportunities for a sensor with a predictable flight path (e.g. orbit or planned UAV route)	Tier 2
47. Post collection attitude and position predictor - given an archived image and image support data, calculate the footprint for the image; proposed by CSC	Tier 3
48. Tracking service - store and access tracks for mobile targets, proposed by Position Integrity	Tier 3
V. Decision Support
49. Decision Support Clients	Tier 3
50. Workflow Manager Clients	Tier 3
51. Model Builder-Editor Clients	Tier 3
52. Modeling Language	Tier 3
53. Situation Objects - creating, managing and using temporarily-sensitive features	Tier 3
54. Event registries - handling real-time events	Tier 3

3. Interoperability Initiative Process Framework

This section describes a flexible framework of standard, repeatable processes, which can be combined and adapted as necessary to address the requirements of each Interoperability Initiative. These tasks are executed with a Virtual Team Infrastructure. This Process Framework forms the basis for the Multi-hazard Mapping Initiative Work Breakdown Structure.

Figure 3: Interoperability Initiative Process Framework.

Tasks

Coordination

Enables overall Initiative coordination between OGC Staff, OGC IP Team, Sponsors, Participants, and other TC/PC Members as required. Initiative Coordination includes the following Subtasks:

• Collaborative Environment - OGC IP Team provides synchronous and asynchronous collaboration environments for cross organizational, globally distributed, virtual teams working interdependently to execute Initiative
• Activities under this subtask include reading email and engaging in collaborative discussions including teleconferences.
• Initiative Plan Development � Support development of Project Plans, Project Schedules and Work Breakdown Structures (Work Package). May include Technical and Project Management Approach, Tasks/Schedules, Communications Plans, Resource Plans, Risk and Mitigation Strategies, and definition of the Specification and/or Component Development and Integration tasks necessary to realize the Technical, Operational and Systems Architectures.
• Management - Services ensuring Initiative Order participants are staying within designated budgets, that the work is progressing according to the agreed schedule, and that the tasks identified in the Statement of Work are executed. Including status reporting.
• Communication � Includes communicating ongoing and planned Initiative and Work Item Status to OGC and other organizations such as ISO. This task does not include IP Business Development functions.

Assessment and Analysis

This task analyzes and documents an organization�s or domains existing capabilities and assesses requirements for OGC compliant technology. This task is implemented during Planning Studies.

Concept Development

This task conducts a Feasibility Study that assesses emerging technologies and architectures capable of supporting eventual Interoperability Initiatives (ex. Testbed). Part of the concept development process is the use of a Request for Technology (RFT) to gain a better understanding of the current state of a potential technology thrust and the architecture(s) used in support of that technology. The feasibility study examines alternative prototype mechanisms that enable commercial web-services technology to interoperate. The study may also assess the costs and benefits of the architectural approaches, technologies, and candidate components to be utilized in a testbed and potential demonstration. This task also collates Sponsor requirements and assesses the applicability of current specifications.

Architecture Development

This task defines the architectural views for any given Initiative. In the context of the Open GIS Interoperability Program, there are potentially three�and perhaps more - architectural views for any given effort. These views are the Operational Architecture, Technical Architecture, and System Architecture. Part of the Architecture Development task may be the use of an RFQ/CFP to industry to enable organizations interested in participating in an Interoperability Initiative to respond with a proposal. This task may also be implemented during Planning Studies.

Initiative Preparation

This task defines the participant budget (if any) and defines and executes agreements and contracts that outline roles and responsibilities of each participant. This task may refine the Work Package.

Specification Development

This task defines and develops models, schemas, encodings, and interfaces necessary to realize required Architectures. Includes specification Pre-design and Design tasks. This task may include activities to coordinate ongoing Initiatives with Specification Program activities.

Component Development

This task develops prototype interoperable commercial software components based on draft candidate implementation specifications or adopted specifications necessary to realize the required Architecture.

Testing and Integration

This task integrates, documents and tests functioning interoperable components and infrastructures that execute operational elements, assigned tasks, and information flows required to fulfill a set of user requirements. Includes Technology Integration Experiments (TIEs).

Solution Deployment

This task prepares prototypical interoperable components so that they can be assembled at required sites.

Demonstration

This task defines, develops and deploys functioning interoperable components and infrastructures that execute operational elements, assigned tasks, and information flows required to fulfill a set of user requirements.

Documentation

This Task ensures development and maintenance of the pre-specification, pre-conformant interoperable OpenGIS technologies (including Draft Interoperability Program Reports and Interoperability Program Reports) and the systems level documentation (example user documentation, etc.) necessary to execute the Initiative. This task may include coordination with OGC Specification Program activities including the Documentation Team.

1. MMI-1 Work Breakdown Structure (WBS)

The following Work Breakdown Structure (WBS) is derived from the OGC Interoperability Initiative Process Framework. This WBS should be interpreted in the following manner:

• Items that are grayed out are either IP Team tasks, have already been completed, or are not required for the MMI-1.
• Bold text is a task grouping or subtask grouping.
• Plain text indicates tasks against which proposing organizations should respond.
• Italic text indicates the task explanation (These task explanations are valid only for MMI-1; subsequent initiatives will issue appropriate task explanations).

A proposing organization does not have to respond to all tasks below. However bold italic text in the task explanation indicates which tasks are mandatory or conditional. Conditional tasks are those that are mandatory if a proposing organization takes on certain non-mandatory tasks. All responses shall use this WBS to structure their responses. Evaluations of responses will be based on whether a proposal addresses the WBS task items. So a company anticipating working on a particular task that fails to indicate their intent by using the WBS structure below will not be considered for the desired task. The MMI-1 project plan and schedule will use this WBS as a template as well.

In this section, "Deploy" means to place a component tested during OGC Interoperability Initiatives on a system and make it function within the MMI-1 framework (as an unrestricted access part of OGC Network or at a FEMA site), and conduct Technology Integration Experiments to ensure that prototypical components function as required in the MMI-1 Project Plan. "Demonstrate" means to highlight the utility and effectiveness of these new technologies during an interactive demonstration event. "Document" means to develop system models for each component in MMI-1, generating at least one logical-view class for each component that identifies classes and associations and one sequence diagram for each component. It also means to prepare a system model for each component that includes an architectural overview and system dependencies. "Primary Responsible" indicates the market specialization of the targeted commercial technology vendors designated by the Project Management Team to execute the task. "Skills" designate the required evidence of technology implementation necessary to qualify as primary responsible task executors.

1. Coordination

1.1. Collaborative Environment

1.1.1. Routine and ad hoc telecons as assigned (Task Explanation-The proposing organization shall provide a technical representative and an alternate to participate in regularly scheduled telecons. If a participant organization has a representative that is requested or volunteers to participate in an ad hoc telecon, then that representative or a reasonable alternative shall join the ad hoc telecon if at all possible. This item is mandatory for all proposing organizations.)

1.1.2. E-mail review and comment (Task Explanation-The proposing organization shall provide technical representatives to participate in specification and prototypical component development discussions via the MMI-1 mail list. This item is mandatory for all proposing organizations.)

1.1.3. Action Item status reporting (Task Explanation-Proposing organizations' representatives shall report the status of their work in response to any action item accepted by them in whole or part. Action Items will be assigned to relevant work groups with an identified work group leader. Action item status shall be reported to the relevant work group leader. This item is mandatory for all proposing organizations.)

1.2. Initiative Plan Development

1.2.1. Project Plan Development

1.2.2. Project Schedule Development

1.2.3. WBS Development

1.2.4. Concept of Operations Development

1.3. Management

1.3.1. Status Reporting (Task Explanation-Proposing organizations' business representatives shall report the status of their work as assigned to and accepted by them in their SOW following the structure of this WBS. Status reports will reflect the WBS item number and name, the "health" of the effort with green indicating optimal; yellow indicating issues have arisen that appear resolvable; and red indicating that issues have arisen that require immediate resolution or the effort will not succeed, and finally the report will describe the work done to fulfill the WBS item. Reports will be submitted to the MMI-1 Manager and Operations Manager on a Monthly basis. The first status report will be due on 17 December 2001 COB with all subsequent reports being due on the seventeenth of the month or the first Monday thereafter by COB. This item is mandatory for all proposing organizations. Additionally all proposing organizations shall submit an initial status report indicating personnel assigned to support the MMI-1. This initial status report will use a form to be supplied to proposing organizations that have been invited to participate in the MMI-1. These initial status reports shall be submitted to MMI-1 Operations lead no later than the first day of the MMI-1 kickoff in soft copy format only.)

1.3.2. Initiative Accounting (Task Explanation-Proposing organizations' business representatives shall submit an invoice to Marilyn Gallant of OGC. The invoice shall include the OGC Accounting Job Code. This Job Code will be provided to contracted participants by OGC via the contract. The invoice shall be submitted monthly for work completed during the prior month. Deliverables shall be itemized. The invoice shall include the budgetary not to exceed figure. This item is mandatory for all proposing organizations. )

1.4. Communication

1.4.1. OGC Internal IP Status Briefings

1.4.2. OGC External IP Status Briefings

2. Assessments and Analysis

2.1. Organizational Capability Review

2.2. Organizational OGC Requirements Review

3. Concept Development

3.1. Sponsor Feasibility Study Review

3.2. RFT Development

3.2.1 RFT Document Development

3.2.2 RFT Document Sponsor Review

3.2.3 RFT Response Document Development

3.3. RFT Response Analysis

3.4. RFT Response Review

4. Architecture Development

4.1. Operational Architecture Development

4.2. System Architecture Development

4.3. Technical Architecture Development

5. Initiative Preparation

5.1. Sponsor Planning TEMs

5.2. RFQ Development

5.2.1 RFQ Document Development

5.2.2 RFQ Document Sponsor Review

5.2.3 RFQ Response Document Development

5.2.4 RFQ Response Analysis

5.2.5 RFQ Response Review

5.3. Participant Budget Development

5.4. Contract Development

5.5. SOW/SOP Development

6. Specification Development (Task Explanation-Proposing organizations with an interest in providing software components for this initiative should minimally respond to this task and its associated subtasks (or a subset thereof) OR to task 7 Component Development. Proposing Organizations with an interest in providing integration services should minimally respond to this task and its associated subtasks (or a subset thereof) OR to task 8 Testing and Integration. To support this responding organizations shall send a technical representative to the MMI-1 Kickoff; this kickoff attendance is mandatory for all proposing organizations. Since specification development is the goal of OGC, this general task and relevant subtasks are mandatory for all organizations proposing to provide or develop prototypical components. Proposing integration organizations are strongly encouraged to participate in these activities.)

MMI Framework Definition:

The MMI-1 seeks to facilitate and promote the use of georeferenced hazard information from multiple sources over the Internet. This requires interoperability ("working together") among the software systems that provide hazard data, maps, services, and user applications. For the MMI, this interoperability is based on shared agreements governing essential geospatial concepts and their embodiment in communications and message protocols, information models, software interfaces, and data formats. This set of shared agreements is designated the MMI-1 Framework.

The MMI-1 Framework is a virtual set of documents (perhaps maintained on OGCNetwork) defining a set of agreements within a structured Model of geoprocessing, as they apply to the design and deployment of web-based geoprocessing software and services. This Model guides the scope and growth of the Multi-hazard Mapping Initiative, defining how geospatial software and services can plug into an "interoperability infrastructure" to draw on multiple sources of hazard data and services and support diverse communities of collaborating users.

6.1. Model Development (Task Explanation-Proposing organizations' technical representatives shall develop or support the development of models that illustrate the MMI-1 Framework Architecture. These models will be developed in UML or another appropriate methodology. A proposing organization may propose an individual to lead modeling efforts.)

6.2. Schema Development (Task Explanation-Proposing organizations' technical representatives shall develop or support the development of schemas that specify an interface that is being enhanced for the MMI-1 Framework. These schemas will be written in XML Schema or some other appropriate language. A proposing organization may propose an individual to lead schema development efforts for a particular interface or set thereof.)

6.3. Encoding Development

6.4. Interface Development (Task Explanation-Proposing organizations' technical representatives shall develop or support the development of interfaces that specify operations, encodings or messages that are being enhanced for the MMI-1 Framework. These interfaces will be specified in XML Schema or some other appropriate language. A proposing organization may propose an individual to lead development efforts for a particular interface or set thereof.)

6.5. Specification Coordination (Task Explanation-Proposing organizations' technical representatives shall participate in initiative working groups. Those representatives shall work with OWS-1 and MPP-1.1 to resolve issues that the members may raise with regard to the IPR and the interface(s) described therein.)

7. Component Development (Task Explanation-Proposing organizations with an interest in providing software components for this initiative should minimally respond to this task and its associated subtasks (or a subset thereof) OR to task 6 Specification Development. Proposing Organizations with an interest in providing integration services should minimally respond to this task and its associated subtasks (or a subset thereof) OR to task 8 Testing and Integration. Since the proof of the viability of a specification is the existence of software that exercises said specification, this task is mandatory for all organizations proposing to demonstrate software components in this initiative.)

7.1. Prototypical Interoperable Software Development

7.1.1. Server software development (Task Explanation-Proposing organizations' technical representatives shall develop server software or modify existing product server software to exercise the interfaces considered or enhanced under the Specification Development tasks of MMI-1. The proposing organizations will make this server software available for sponsor review and input during the course of the MMI-1.)

7.1.1.1 Legacy Map Server Integration (Task Explanation-Proposing organizations' technical representatives shall update or wrap existing servers developed by Harvard Design and Mapping to a WMS 1.1 compliant server and deploy in this initiative. This system is built on ArcIMS 3.1. Proposing organizations are expected to make use of the existing ArcIMS WMS connector in their solution.)

7.1.2. Client software development (Task Explanation-Proposing organizations' technical representatives shall develop a Web Based Client Generator to access multiple on-line services. This component shall be robust enough for public use. Proposing organizations may also develop client software or modify existing product client software to exercise the servers developed under the Component Development tasks of MMI-1. The proposing organizations will make this client software available for sponsor review and input during the course of the MMI-1.

7.2. Special Adaptation Development

8. Testing and Integration

8.1. Configuration Management

8.1.1. CM Plan Development (Task Explanation-In order to achieve success in this initiative, it is essential that the implementation environment is under configuration management. Controlled items shall include the specifications to be built to and tracking of the current status of components. The Proposing organization shall provide a representative to develop a configuration management plan for interfaces and components used and/or developed during the MMI-1. The individual companies are responsible for the configuration management of their own products.)

8.1.2. Initiative CM (Task Explanation-The Proposing organization shall provide a representative to exercise the configuration management plan for interfaces and components developed during the MMI-1.)

8.2. Infrastructure Setup (Task Explanation-The Proposing integration organization shall support the integration of MMI-1 related technologies in the sponsor's environment or a sponsor designated environment. This may require site visits.)

8.2.1. Operating Systems

8.2.2. Networks

8.2.3. Web Server (Task Explanation-The Proposing integration organization shall provide a technical representative to install, update, and/or enhance web server software in the sponsor's environment or a sponsor designated environment. This may require site visits.)

8.2.4. Database Server (Task Explanation-The Proposing integration organization shall provide a technical representative to install, update, and/or enhance database server software in the sponsor's environment or a sponsor designated environment. This may require site visits.)

8.2.5. Web Browsers (Task Explanation-The Proposing integration organization shall provide a technical representative to install, update, and/or enhance web browser software in the sponsor's environment or a sponsor designated environment. This may require site visits.)

8.2.6. SW Installation & Integration (Task Explanation-The Proposing integration organization shall provide a technical representative to install and integrate participant MMI-1 component software in the sponsor's environment or a sponsor designated environment. This may require site visits.)

8.2.7. Data Loading (Task Explanation-The Proposing integration organization shall provide a technical representative to load data to the MMI-1 servers in the sponsor's environment or a sponsor designated environment. This may require site visits.)

8.3. Technology Integration Experiments

8.3.1. Iterations 1-N

8.3.1.1. Component Interface Test (Task Explanation-The Proposing organization shall provide a technical representative to conduct formal Technology Integration experiments that exercise server and/or client component software's ability to properly implement the interfaces, operations, encodings, and messages developed during MMI-1. There will be multiple TIEs during the course of MMI-1 that will exercise various interfaces, operations, encodings, and messages developed during MMI-1. There may also be multiple iterations of a particular TIE or set thereof. This item is mandatory for all organizations proposing to develop software components for MMI-1.)

8.3.1.2. Test Result Analysis (Task Explanation-The Proposing organization shall provide a technical representative to report the outcome and relevant software reporting messages from TIEs in which the proposing organization participates. These TIE reports shall be submitted to the MMI-1 email list and within Monthly Status Report to be courtesy copied to the initiative architect. This item is mandatory for all organizations proposing to develop software components for MMI-1.)

8.3.1.3 Testing Coordination (Task Explanation-The Proposing integration organization shall provide a technical representative to coordinate TIEs, TIE reports, and outcome recommendations.)

8.4. System Tests (Task Explanation-The Proposing integration organization shall perform and support the conduct of system tests of the MMI-1 system at the sponsor's location or a sponsor designated location. This may require site visits.)

8.4.1. Functional Test (Task Explanation-The Proposing integration organization shall provide a technical representative to perform and support the conduct of tests of the functionality of the MMI-1 system at the sponsor's location or a sponsor designated location. This may require site visits.)

8.4.2. Interface Test (Task Explanation-The Proposing integration organization shall provide a technical representative to perform and support the conduct of tests of the ability of the MMI-1 system to pass information across the prototypical and infrastructural software interfaces at the sponsor's location or a sponsor designated location. This may require site visits.)

8.4.3. Performance Test (Task Explanation-The Proposing integration organization shall provide a technical representative to perform and support the conduct of tests of the performance of the MMI-1 system at the sponsor's location or a sponsor designated location. These tests shall benchmark such variables as speed of response of prototypical components, volume of data that the prototypical system can effectively process, as well as, other variables. This may require site visits.)

9. Solution Deployment

9.1. Software Installation (Task Explanation- Proposing organizations shall install Web Based Client Generators and the ArcIMS WMS Connector on sponsors� systems. The Proposing organizations shall also provide a licensed copy of MMI-1 relevant software components for installation/integration onto the OGC Network. This may take the form of the proposing organization making the software component(s) available from an open site on their network OR by installing it on a sponsor or other host machine on the OGC Network. If the latter option is taken, then the proposing organization shall provide a technical representative to install the software component(s). This item is mandatory for all organizations proposing to develop software components for MMI-1.)

9.2. Software Integration (Task Explanation-The Proposing integration organization shall provide a technical representative to integrate the required server or client software and the prototypical components provided by the vendor on the MMI-1 servers in the sponsor's environment or a sponsor designated environment. This may require site visits.)

9.3. Data Loading (Task Explanation-The Proposing organization shall provide a technical representative to load data to any server components the proposing organization may develop. This task includes data loading to OGC Network based servers. This item is mandatory for all organizations proposing to develop server components for MMI-1.)

10. Demonstration

10.1. Use Case Development (Task Explanation-The Proposing organization shall provide a technical representative to develop or support the development of use cases that define and explain the utility of the interfaces enhanced during MMI-1. These use cases shall be used to provide a basis for demonstration storyboards and the demonstration itself.)

10.2. Storyboard Development (Task Explanation-The Proposing organization shall provide a technical or business representative to develop or support the development of the demonstration storyboards that will define the structure and content of the demonstration.)

10.3. Venue Access (Task Explanation-The Proposing integration organization shall provide a technical or business representative to coordinate demonstration venue options with the sponsor and to make arrangements for the use of the venue during the course of the preparation for the demonstration and the demonstration itself.)

10.4. Data Requirements Assessment (Task Explanation-The Proposing integration organization shall provide a technical or business representative to assess the data requirements for the demonstration. This task will be done in coordination with the sponsor.)

10.5. Data Acquisition and Distribution (Task Explanation-The Proposing integration organization shall provide a technical or business representative to acquire data to support the demonstration. Additionally the representative shall distribute said data to the appropriate participants.)

10.6. Demonstration Preparation and Delivery (Task Explanation-The Proposing organization shall provide a technical and/or business representative to develop or support the development of demonstration that will exercise the functionality of the interfaces developed during MMI-1. The representative(s) will also support the demonstration event(s) as required. The proposing organization will maintain server and client software for a period of no less than six months after the completion of the MMI-1 demonstration. This item is mandatory for all organizations proposing to develop software components for MMI-1.)

11. Documentation

11.1. IPR Development

11.2. System Documentation Development

11.2.1. Functional Specification

11.2.1.1. Architectural Overview

11.2.1.2. Use Cases (Task Explanation-The Proposing organization shall provide a technical representative to develop use cases to show the functionality of their software components in the context of the MMI-1 architecture. This item is mandatory for all organizations proposing to develop software components for MMI-1. . The Proposing integration organization shall compile the participant use cases into a set of MMI-1 System use cases. This item is mandatory for all integration organizations proposing for MMI-1.)

11.2.1.3. UML System Models

11.2.1.4. System Configuration (Task Explanation-The Proposing organization shall provide a technical representative to develop a detailed document describing the combined environment of hardware and software component(s) that compose their contribution to MMI-1. This item is mandatory for all organizations proposing to develop software components for MMI-1 to be installed at sponsor or other host sites connected to the OGC Network. . The Proposing integration organization shall compile the participant architectural overviews into a MMI-1 System Configuration Overview. This item is mandatory for all integration organizations proposing for MMI-1.)

11.2.2. Installation Guide (Task Explanation-The Proposing organization shall provide a technical representative to develop an installation guide for their software component(s). This item is mandatory for all organizations proposing to develop software components for MMI-1 to be installed at sponsor or other host sites connected to the OGC Network. . The Proposing integration organization shall compile the participant installation guides into a MMI-1 System Installation Guide. This item is mandatory for all integration organizations proposing for MMI-1.)

11.2.3. Training Material & Users Guide (Task Explanation-The Proposing organization shall provide a technical representative to develop a short User's Guide pertaining to their software component(s) developed or modified for MMI-1. The documents shall be provided to sponsors and IP Team to support their ability to demonstrate the proposing organization's contributions to the MMI-1. This item is mandatory for all organizations proposing to develop software components for MMI-1. The Proposing integration organization shall compile the participant training material and user guides into a MMI-1 System Training Document and Users Guide . This item is mandatory for all integration organizations proposing for MMI-1.)

11.3. Planning Study Report

Annex B - MMI-1 Architecture

RFQ Issuance Date: October 24, 2001

Proposal Due Date: November 21, 2001

Table of Contents

1 Introduction *

1.1 Background and Overview *

1.2 Purpose *

2 Operational Architecture *

3 MMI-1 Components (System Architecture) *

4 MMI-1 Technical Architecture *

5 Specification Baseline *

2. Introduction

In the United States, recent disasters, regardless of scale, have focused attention on the economic and human costs of environmental hazards. With each new event, it becomes more apparent that a unified, concerted approach for sharing advisory information about environmental hazards is essential to save lives, infrastructure, and money. Success in dealing with these hazards will require a wider range of technology interoperability between federal, state, local, multinational, interagency, and non-governmental partners.

The US Federal Emergency Management Agency (FEMA) has the national mission to reduce loss of life and to protect critical infrastructure from hazards. FEMA recognizes the critical need for geospatial information infrastructures based on open standards for interoperability to support multi-hazard advisory efforts. In addition, Section 203 (k) of the amendments to the Robert T. Stafford Relief and Emergency Assistance Act require that multi-hazard advisory maps for not fewer than five states be developed in consultation with the states, local governments and appropriate federal agencies. A multi-hazard advisory map is a map on which hazard data (flood, hurricane, severe winds, and seismic) is identified showing areas of overlap. These maps will be made available to the appropriate State and local governments for informing the general public about hazards and to support activities for mitigation purposes and other public uses.

FEMA realizes that these multi-hazard advisory maps should be developed using the most cost-effective and efficient technology available. FEMA also recognizes the critical need for standards-based frameworks to support multi-hazard advisory map publishing, dissemination and integration efforts. FEMA realizes that these frameworks will use web-based services implementing OGC Specifications to support multi-organizational collaboration and communication. By implementing interoperable services based on OGC interfaces, FEMA will be able to operationally demonstrate an interoperable framework for publishing, finding and accessing hazard advisory maps from multiple sources and displaying them in a common environment.

1. Background and Overview

FEMA and the OGC have successfully cooperated on the OGC Web Mapping Testbed, Phase 2 (WMT-2) resulting in new OGC standards for interoperability and prototypical commercial software components that implement those standards. FEMA now wishes to conduct an OGC Interoperability Initiative designated the Multi-hazard Mapping Initiative, Phase 1 (MMI-1) to promote collaborative development, testing, and demonstration of prototypical interoperable, Web-based multi-source hazard information frameworks based on OGC standards for interoperability.

2. Purpose

The purpose of the OGC Multi-hazard Mapping Initiative, Phase 1 (MMI-1) Project is to be able to make use of the unique talents of OGC and the vendors who comprise the OGC. This Interoperability Initiative will demonstrate the application of developed web technologies in data sharing between FEMA, state, and local emergency management agencies and to provide feedback into the OGC Specification Development process.

3. Operational Architecture

The current status of the MI-1 operational architecture is captured in version 0.4 of the MMI-1 conceptual architecture (http://ip.opengis.org/mmi1/conceptual).

4. MMI-1 Components (System Architecture)

The MMI-1 architecture will provide a Web based framework to integrate new and existing Multi-hazard Mapping technologies deployed by FEMA, state, and local emergency management agencies. The foundation of this framework lies in the globally dispersed data exchange technologies provided by the Internet and World Wide Web. Standards-based Commercial-off-the-shelf (SCOTS) components will provide geospatial services over this Web foundation. Legacy systems participate in the framework through a SCOTS proxy (such as a Web Map Server) or through a SCOTS wrapper for the application (such as the WMS Connector for ArcIMS). A conceptual representation of the MMI-1 system architecture can be found in figure 3.1



Figure 3.1 � Conceptual System Architecture

SCOTS components are classified in a 3-tier model that includes client, middle, and repository tier services. The disposition of these software components for MMI-1 is illustrated in figure 3.2.



Figure 3.2 � 3 Tier OGC Web Services Model

The SCOTS software components to be used in the MMI-1 will be supplied from multiple vendors after Sponsor review and selection of responses to the RFQ. The MMI-1 System Architecture and associated MMI-1 Demonstration shall include the following components:

Component Type	Description
Services Registry	A middle tier component that contains a list of services, the metadata that describes the services and the parameters and attributes that are required for invoking or directly accessing the services across common interfaces.
Catalog Server	A middle tier component that can communicate with any client across a common interface and has been interfaced into a services metadata repository providing the capability to directly access multiple repository tier services across common interfaces.
Viewer Client (s)	A client tier set of Web pages transferred across a network for displaying multi-source Advisory Map views.
Web Map Server (WMS)	A component that delivers multi-hazard Advisory Maps (as layers of symbolized graphics) across a common interface (WMS).
Cascading Map Server (part of WMS)	A component that dynamically transforms information from other WMS-compliant servers (map and data). Can transform map layers from third-party map servers into a number of different projections and image formats, even if those map servers cannot serve those projections and formats themselves.
Web Feature Server (WFS)	A component that delivers feature collections across a common interface (typically as the result of a query).
Register Services Client	A user interaction tier set of Web pages with input fields for collecting and submitting service identifiers (among other possible information) across a common interface.
Discovery Client	A Client tier set of Web pages transferred across a network, software modules transferred across a network and executed on a local system, or classes (executable code) residing on a local system for collecting and submitting user input for querying metadata across a common interface, selecting a service, and adding the service to any Client tier service as appropriate. The query screen may have three parts in which text, keyword, and geographic constraints can be defined by the analyst.
Web Client Generator	A component that provides server-side processing of client-generated requests and returns responses as Web Pages.

 

5. MMI-1 Technical Architecture

The software components of the MMI-1 will implement open protocols and interfaces to communicate and provide services to users (MMI-1 Framework).   The baseline set of protocols and interfaces are being developed under the OGC Web Services, Phase 1 (OWS-1) Initiative. A subset of those protocols and standards will be implemented by the SCOTS components, applied against the operational needs of the sponsors, and enhanced where necessary.

The current set of specifications for the MMI-1 Technical Architecture may include, but is not limited to:

• Web Map Server
• Web Feature Server
• Geography Markup Language
• XML for Imagery and Map Annotation (XIMA)

• Filter
• Stateless Catalog

• Basic Services Model
• OGC Catalog Services
• Web Registry Server

• Styled Layer Descriptor

• Web Feature Server - transactional

Some of these OGC technologies are currently under development by the OGC Military Pilot Project, Phase 1 (MPP-1) and the OGC Web Services, Phase 1 (OWS-1) Initiative. The MMI-1 will be coordinated with the MPP-1 and the OWS-1 and may develop modified versions (as required) of these specifications based on ongoing consensus-based interface specification development activities.

1. Specification Baseline

The software components of the MMI-1 implement open protocols and interfaces to communicate and provide services to users.   A current baseline set of specifications for the MMI-1 includes, but is not limited to:

Annex C�MMI-1 Concept of Operations

RFQ Issuance Date: October 24, 2001

Proposal Due Date: November 21, 2001

Table Of Contents

1 Introduction *

2 Proposal Development *

3 Initiative Design *

4 MMI-1 Execution *

5 Integrated Initiatives *

6 MMI-1 Resource Plan *

7 Assignment of Week Numbers *

Introduction

1. Introduction

This Annex describes the Concept of Operations for the OGC Multi-hazard Mapping Initiative (MMI-1). This document is organized around eight particular time frames or phases. The phases are:

• Proposal Development (10/24/2001-11/21/2001:20 days: Week 1-4)�the time during which RFQ respondent proposals will be developed. This time will also be used by the OGC to develop a draft management plan for the initiative operational phases.
• Initiative Design (11/21/2001-12/7/2001:13 days: Week 5-7)�the time that responses will be analysed, the initiative design will be solidified, the initiative architecture will be refined, the initial System Architecture will be revised and a demonstration concept will be determined. This time will also be used to communicate with RFQ respondents concerning their proposals, to negotiate with them on their initiative participation, and to communicate the status of the MMI-1 to the OGC Technical and Management Committees. During this time, purchase orders for targeted participants and Memoranda of Understanding will be signed.
• Initiative Kickoff (12/10/2001-12/11/2001:2 days: Week 8)�the time that starts the initiative operation. This meeting will be held in the Washington DC area and will last two days. During the Kickoff, the participants will 1) finalize the initial System Architecture, 2) identify interfaces and protocols to be used as the starting place for software components, and 3) refine the Demonstration Concept. This phase is covered specifically by this RFQ.
• Interface Development (12/10/2001-2/15/2002:48 days: Week 8-17)�the time of developing interface components into an initial Initiative implementation and to integrate selected components of that capability to form prototypes that adhere to the demonstration concept. During this phase (and all subsequent phases), the Operational, Technical, and System Architectures are expected to evolve. This phase is covered specifically by this RFQ. Interface Development will cumulate in an initial demonstration of the MMI-1 capabilities on February 15, 2002.
• Demonstration Development (2/18/2002-3/29/2002:30 days: Week 18-23)�the time when the MMI-1 products developed during the initiative will be demonstrated to OGC, sponsors, and the sponsor�s communities. This phase is covered specifically by this RFQ.
• OGC Network Integration (TBD at Kickoff )�the time of when the interfaces and demonstrations developed during the Interface Development and Demonstration Development are integrated into the OpenGIS.net testbed infrastructure. This activity will result in configuration-controlled components that are considered stable enough to use in ongoing demonstrations, pilots, and further testbed activity.

The weeks are numbered according to the Table 2 provided at the end of Annex C. The details of each phase are fully detailed in this Annex.

2. Proposal Development

The RFQ and Responses�The primary activity during this period is the development of proposals. Proposals should reflect an understanding of the following:

• Proposing organizations not already members of OGC will be expected to become members if their proposals are selected for funding.
• The OpenGIS Abstract Specification, the OpenGIS Interface Specifications as well as ongoing work with the OGC Web Services (OWS-1) initiative cover many of the technology areas under consideration in the RFQ. The relationship between the content of the proposal and the relevant OpenGIS specifications or initiatives should be noted by the proposing organizations.
• Proposals with some basis on emerging International Standards being developed by ISO TC/211 should reference the relevant standard and sections thereof.
• Proposing organizations should plan on performing all development work at their own facilities. These facilities should include a server (where applicable) which is accessible to other Initiative participants via the Internet. TIEs will be carried out among the participants based on these Internet-accessible servers.
• Proposing organizations should plan on either migrating their components to a server (where applicable) which is part of OGC Network, or participants should consider making their server part of OGC Network during the OGC Network Integration phase.
• The desired outcome of the MMI-1 Initiative includes the refinement of OpenGIS specifications as well as implementations of those specifications that themselves become part of the OGC Network infrastructure. Proposals covering technologies that require licensing should indicate how these technologies can be made available as a (permanent) part of OGC Network. Proposals covering technologies requiring specific hardware or software environments should indicate what these are.
• Proposals need not address the full spectrum of the MMI-1 architecture as outlined in Annex B. Proposals can focus on specific portions of that architecture.
• Proposing organizations should be prepared to build interoperable components and thus should be prepared to cooperate with all selected development teams, regardless of whether individual proposals covered the full MMI-1 architecture or portions of it.
• Proposal selection and funding may be on the basis of portions of the proposal deemed most likely to lead to a successful MMI-1 implementation.
• Proposing organizations should feel free to provide alternatives to the MMI-1 architecture. However, it should be noted that proposals will be selected on the basis of how successfully the various components of all the selected responses interoperate. Radically different architectures that would require intensive rework on the part of a majority of the participants would have to be supported by very persuasive arguments!
• Proposing organizations should be familiar with the existing OGC Network infrastructure. OGC Network provides a set of services, datasets, components, toolkits, and reference materials that can and should be used to leverage the MMI-1.
• Proposing organizations shall use the supplied template and forms to complete to their proposals.

The primary activity during this period is the development of proposals by potential participants. Those organizations or companies choosing to respond should plan to send at least one engineer to the Kickoff meeting on December 10-11, 2001.

1. Management Plan

The OGC IP Team will develop a draft management plan during the period between the release of the RFQ and the submission of the responses. This plan will provide guidance to the OGC IP Team and participants for the conduct of the MMI-1.

The Management Plan will detail the roles and responsibilities of individuals providing management support to the MMI-1. The following roles (at least) will be detailed in this plan:

1. Sponsor Team�representatives from the organizations that have provided sponsorship for the MMI-1 initiative.
2. OGC Initiative Manager�the OGC staff person responsible for the overall management of the MMI-1 initiative.
3. Operations�the individual responsible for the day-to-day operation of the MMI-1 initiative.
4. Architecture�the individuals responsible for the overall initiative architecture during the course of the MMI-1 initiative.
5. Marketing�the individual responsible for the marketing aspects of the MMI-1 initiative.
6. Interface Team�a team of individuals representing all of the participants that are engaged in component development and representing sponsor organizations. The primary task of this team is to develop component interface and protocol definitions, implement components, revise interface and protocol definitions, and evolve the Initiative Architecture.
7. Operation Team�a team of individuals representing all of the participant and sponsoring organizations that are engaged in demonstration, testing, or data provision. The primary task of this team is to prepare scenarios for demonstrations, design tests that exercise the components, perform data development in support of these scenarios, build demonstrations and tests, and evolve the Demonstration Concept.
8. OGC IP Team�a group composed of the OGC Initiative Manager, Architecture, Operations, and Marketing.

Figure 2: OGC Multi-hazard Mapping Initiative Organization Chart

The fundamental basis of the Management Plan is a Contract that will be signed by each participant and OGC. The Management Plan will be presented to the responding organizations and companies as part of the contract package. The contract will contain common vision and goal statements and will be an agreement to work toward common goals and will define the roles and responsibilities of the participants.

Included in this RFQ is a Communications Plan for reporting and exchanging information with participants, relevant SIGs and WGs, TC, MC, and sponsors. This plan will incorporate a Web page with appropriate documents and regular updates to MMI-1 information. Interim interface and protocol decisions will be provided in a monthly progress report, which will be posted to this web site. Likewise the ongoing status of interface designs will be included in the monthly progress report. OGC IP Team will provide a list server for participants to exchange project relevant e-mail. A teleconferencing plan will be developed to further support inter-participant communications.

The Management Plan will be presented to the sponsors at Decision TEM I. The final version will be presented to the sponsors at Decision TEM II and to the participants, TC, and PC at the December OGC TC meetings.

2. Initiative Design

Figure 3 depicts the processes involved in the Initiative Design phase. Each of these processes, their inputs and outputs, and others aspects are detailed in this section.



Figure 3: Processes Leading up to the MMI-1 Initiative Kickoff Meeting

1. Initial Response Analysis

The OGC IP Team and Sponsors will review the RFQ responses beginning immediately after the deadline for submission on November 21, 2001. During the analysis process (November 21-December 7, 2001) the OGC IP Team may need to contact respondents for clarification, thus respondents should prepare for this eventuality. Time permitting, OGC may also dialog with RFQ respondents about details of the recommended Initiative Design and Demonstration Concept.

1. Component and Requirement Analysis

The review team will accomplish three tasks:

1. Analyze the components proposed in the RFQ responses in the context of the MMI-1 WBS found in Annex A.
2. Compare the proposed efforts with the requirements of the initiative and determine viability.
3. Assess the feasibility of the RFQ responses against the use cases.

1. Initiative (System) Architecture Recommendation

The proposal review team will then draft a recommended system architecture to include the set of proposed components for development within the initiative and relate them to the hardware and software available. Any candidate interface and protocol specifications received during the RFQ process will be included with the draft initiative architecture as annexes.

2. Demonstration Concept Recommendation

The preliminary analyses of responses will be used to develop a demonstration concept. The concept will contain a discussion of the proposed components with respect to their ability to work together in a demonstration context. Gaps will be identified.

In the case of proposals for demonstration and database development tasks, proposed databases (where applicable in the Initiative) and the details of their contents will be listed. The ability of the proposed databases to support a demonstration (in the context of existing scenarios) and an estimate of the effort required to develop metadata for the proposed data will be evaluated. A listing of database compatibility (accuracy, scale, coordinate system, and data type) issues will also be constructed to inform the scenario development process. Early recommendations regarding the applicability of the databases with respect to demonstration scenario support will be developed.

The demonstration concept will include references to existing and emerging resources (including the resources under development in this Initiative) on OGC Network. The MMI-1 initiative will culminate in a sponsor demonstration, tentatively scheduled for late March, 2002. The current intent is for this demonstration to be at least partially virtual. While some subset of the sponsors will be present for the demonstration, it is expected that some sponsors will be operating the demonstration at mirror sites, using the same servers and clients as are being used at the central site.

1. Decision TEM I

At Decision Technical Evaluation Meeting I, OGC IP Team will present to the sponsors (with the Component and Database Analyses as background):

• The Initiative (System) Architecture Recommendation, and
• The Demonstration Concept Recommendation.

This presentation will be made in the context of first drafts of the plans described above:

• Management Plan
• Communications Plan
• Tiered sponsor requirements

The primary decisions to be made by the sponsors at this TEM are:

• Is the recommended Initiative Architecture workable? If not, how to make it workable.
• Which RFQ responses, or subset thereof, should be provided cost-sharing funds and at what level given all inputs?
• Is the Demonstration Concept workable? If not, how to make it workable.
• Are the Management and Communications Plans reasonable and complete?

Immediately following Decision TEM I, MMI-1 Initiative staff will begin to evaluate sponsor recommendations to the various plans and will revise the plans and concepts accordingly. It will also make budgetary adjustments based on sponsor inputs.

1. Decision TEM II

At Decision Technical Evaluation Meeting II, the OGC IP Team will present to the sponsors:

• The Initiative (System) Architecture Revision, and
• The Demonstration Concept Revision.
• The Participant Recommendation

The primary decisions to be made by the sponsors at this TEM are:

• Is the revised Initiative Architecture workable? If not, how to make it workable.
• Is the Participant Recommendation correct and affordable?
• Is the Demonstration Concept workable? If not, how to make it workable.
• Are the Management and Communications Plans reasonable and complete?

Immediately following Decision TEM II, the OGC IP Team will 1) finalize the Initiative Architecture and Concept of Operation (now including the Demonstration Concept), 2) begin to insert specific information into the existing purchase order template for each targeted participant organization, and 3) make the insertions of specifics for all participants into a contract template. Each targeted respondent POC should be available or make arrangements for alternates during this period (November 28 - December 10, 2001). The output of Decision TEM II will be a final Initiative Architecture and Demonstration Concept. Proposing organizations who have been selected for funding will be notified after the completion of Decision TEM II.

1. Presentation of Design at OGC TC

At the meetings of the OGC Technical and Planning Committees following the Decision TEMs, the IP Team will present the MMI-1 design to the participants, the TC, and the PC. This presentation will include:

1. The "final" Initiative Architecture
2. The "final" Concept of Operations
3. The initially selected participants.

1. Initiative Kickoff

The MMI-1 will be launched officially with a Kickoff meeting in the Washington DC area (exact location to be announced). Prior to the Kickoff meeting all the participants will sign a Contract that includes a description pertaining to the aspect of the MMI-1 in which they will participate.

The Kickoff meeting will address two development activities in the MMI-1 process: 1) component interface and protocol definitions and 2) demonstration scenario development (or more properly vignettes, a term applied to separable scenario elements). The scenario vignettes that will be used in the MMI-1 will be derived from those developed for OWS-1, the MMI-1 RFQ, and other candidates provided by OGC and the sponsors. Both of these activities interact and affect each other. The interaction is iterative. During the Kickoff, both activities will be jump-started using assets that participants bring to the MMI-1. Each of these activities should use tools such as clumping analysis, interface identification, state of the art assessments (or resources at hand), and shortfall analysis to build consensus regarding the nature of the MMI-1 work. Participants will be asked to volunteer to address any perceived shortfalls. However, the process that will be used during the Kickoff will allow each of the activities to interact with the other. Plenaries will be held for the exchange of information chaired by the Initiative Manager or the Initiative Lead Engineer. The OGC IP Team will provide facilitators and "scribes" to help with these efforts.

An additional product of the Kickoff meeting will be a development schedule that defines specific milestones in the Interface Development and Demonstration Development phases. These milestones will cover component-to-component interactions via the interfaces under development as well as component insertions into demonstration scenarios. Among these milestones will be Technology Integration Experiments. These TIEs will be conducted on a planned basis during the Specification Development activities (See Annex A WBS task items 6 and 8.3. Participants providing software components based upon draft specifications developed during the course of the MMI-1 initiative shall participate in relevant TIEs (See WBS task item 8.3 and related sub-tasks for details).

Simultaneously, there will be technical breakouts at the Kickoff meeting to begin scenario vignette design and creation. This activity will involve the development of use cases to explore the implications of the scenario vignettes to the MMI-1. The participants in this activity should understand that various databases will be proposed as solutions to the RFQ. This group will apply the use cases to the development of storyboards based on the proposed databases. To facilitate this activity a presentation will be created which maps, physically and systematically, the component databases being used in the scenario. The scenario design must account for the requirements and dependencies of the overall MMI-1 system, including any Client designs, any Server designs, and service interfaces.

There will be technical plenary sessions conducted during the course of the Kickoff meeting. These are intended to allow the participants working of interface and protocol definitions to interact with those participants working on scenario vignettes and demonstration development. These plenaries will use UML use case and UML sequence diagrams to assess the interaction of the scenario and demonstration development and the interface definition effort.

2. MMI-1 Execution

This section defines an initial concept of the MMI-1. Figure 4 lays out a notional schedule to impart the intended plan for development. The actual schedule and further information will be provided at the Initiative Kickoff.

Figure 4: MMI-1 Notional Thread Set Schedule

MMI-1 consists of activities to develop elements of Common Architecture and Web Mapping. Common Architecture includes those interfaces and protocols that can be shared by multiple OGC services. Web Mapping includes refinements to the existing specifications pertaining to web mapping, and additional new specifications that extend the suite of OGC web mapping services.

During the initiative, the Technical Architecture (System Architecture) will be refined while groups of participants work on specific component development. The work being carried out will be shaped by the Scenario/Vignette and Data Development tasks. Demonstration scenarios will, by this time, have been broken into "vignettes" which isolate key actions and behaviors of users of the scenarios. This methodology is expected to provide clear, measurable, and short-term goals for the technical development teams to pursue. There will be a strong feedback component between the technical implementation teams and the demonstration scenario and data preparation teams. Rather than wait until Demonstration Integration and Testing time to perform initial interoperability experiments, this allows problems and successes to surface early. Demonstration Integration and Testing then becomes a matter of integrating already tested interfaces into a larger, cohesive unit capable of supporting the end-to-end nature of the scenarios.

1. Interface Development

This section defines the phase called Interface Development (ID) Phase. The schedule and further information will be developed and provided at the Initiative Kickoff. This phase corresponds with WBS Tasks 6, 7, and 8 and their related sub-tasks.

During the ID phase, the Technical Architecture (System Architecture) will be refined while groups of participants work on specific component development. The work being carried out will be shaped by the Scenario/Vignette and Data Development tasks. Demonstration scenarios will, by this time, have been broken into "vignettes" which isolate key actions and behaviors of users of the scenarios. This methodology is expected to provide clear, measurable, and short-term goals for the technical development teams to pursue. There will be a strong feedback component between the technical implementation teams and the demonstration scenario and data preparation teams. Rather than wait until Demonstration Integration and Testing time to perform initial Technology Integration Experiments (TIEs), this allows problems and successes to surface early (See WBS task item 8.3 and related sub-tasks). Demonstration Integration and Testing then becomes a matter of integrating already tested interfaces into a larger, cohesive unit capable of supporting the end-to-end nature of the scenarios.

TIEs will be conducted on a regular basis in an iterative manner (on the order of every two weeks). Participants that are developing components within the Initiative Architecture shall provide access to those components for testing by the MMI-1. The intent is to test interfaces for component accessibility, behavior, and interoperability. The component shall have data loaded to allow third party access and exercise of the then existing functionality. The probable chain of events associated with a TIE will be interface design followed by construction of the interface. The participants will then create the component by connecting it to application logic. A test harness will then be built, and then the component will be tested. Participants working behind firewalls shall take any necessary steps to allow the test to be conducted through the firewall or outside of the firewall. All participants are expected to provide appropriate documentation to allow the successful conduct of these experiments. The IP Team will develop a TIE matrix defining the nature of TIEs that shall be conducted and their scheduled occurrence within the initiative. In order for the TIEs to be meaningful, participants must provide clients in addition to servers. Participants shall report the outcome of TIEs to the MMI-1 list and the Initiative Architecture Team.

Annex B, the Technical Architecture, describes an initial set of services and interface mechanisms. It also contains a notional System Architecture. Individual items in that notional System Architecture are to be refined during the Kickoff meeting and will be further refined during the ID phase. It is intended that there be periods of development followed by periods of synchronization between the various component developers. This will allow for issues to be resolved and documented before divergence begins to occur between individual component developers (i.e., two server developers) and between dependent component developers (i.e., server and client developers).

2. Community Advisory Group

As was stated in the RFQ main body, the Multi-hazard Mapping Initiative is mandated by section 203 (k) of the Disaster Mitigation Act of 2000 which requires that FEMA develop the initiative in conjunction with state and local governments and the appropriate Federal agencies. To accomplish that goal a Community Advisory Group (CAG) is being formed for MMI-1 which would be composed of state and local leaders as well leaders as well as federal agency representatives. These advisors should have:

• A working knowledge of their information systems architecture and applications of geospatial information within those systems;
• Experience in the use of GIS as a tool to facilitate planning and policy development;
• Interest in participating in the design of systems for delivering spatial hazards data via the Internet.

The CAG will kickoff its activities on January 10, 2002. The CAG will be asked to review developments within MMI-1 such as clients exercising servers adhering to MMI-1 specifications. Advisors will join various ad hoc and regularly scheduled teleconferences in support of these efforts. The CAG's input will be sought with regard to whether the MMI-1 technology addresses their needs, whether the user interfaces help achieve their missions, and whether or not MMI-1 technology enhances geospatial interoperability within their environment and with their peer agencies. Advisors may be asked to provide demonstrations of MMI-1 technologies to their constituents.

1. Demonstrations

This section builds upon the initiative characteristics developed during the Kickoff scenario vignette design and creation discussions. To be successful, participants must execute four activities�designing a demonstration, building a demonstration, testing the demonstration, and packaging the demonstration on portable media.

Capitalizing on the Use Case and UML work performed at the Kickoff, participants need to expand these initiatives in four design areas�completing vignette storyboards, finalizing specification considerations, identifying data providers, and incorporating support databases.

• Review and Finalize Vignette Storyboards�participants identify the interfaces between the data, sponsor scenarios, and the components.
• Finalize Interface Definition Considerations�since issues may exist between specifications and interfaces, participants must expose these conflicts and develop the appropriate solutions.
• Survey Supporting Database Providers�access to the appropriate data is essential to exercising the initiative architecture and capturing a representative demonstration. Participants clearly must assure that the appropriate data exists and are available.
• Determine Nature and Extent of Holdings�As mentioned previously this effort would like to demonstrate OGC Implementation Specification conformant data. However, the most important issues are the quality, availability, and interoperability of the datasets.
• Manage Supporting Data�On-line supporting data require that the participants identify the data stores, availability, throughput limitations, and ingestion process. Successful execution of data pre-staging will require the participants to have a data plan, so valuable time is not lost due to poor planning and preparation.
• Incorporate Supporting Databases�Based on the data plan participants must identify how data will migrate into initiative database components to be exercised for the demonstration.

The design activities will be used by the participants to build and implement prototypes, which clearly demonstrate the capabilities of the components through exercising the sponsors' scenarios. As a core requirement of the Initiative effort, the sponsors have requested that all demonstrations be made available via the Internet for either presentation purposes or use in their internal labs (See WBS task items 9, 10, and 11.2 and their related sub-tasks). The component elements of the demonstrations include but are not limited to the following:

1. All Executables
2. All Necessary Links and Datasets
3. Supporting Documentation, Installation Instructions, Scripts, etc.

1. Progress Reporting

The OGC IP Team will provide regular (monthly) progress reports pertaining to progress of the MMI-1 to the sponsors (See WBS task item 1.3.1). The OGC IP Team and the sponsors intend to provide regular status reports about the program to the OGC Technical Committee, and the OGC Management committee. Currently the TS1 lead up activities and development phase will coincide with one OGC Technical Committee and Planning Committee meeting. At that time the participants will present interface designs to the TC and MC. Demonstration scenarios and the architecture to support those demonstrations will be included in the presentation.

1. Integrated Initiatives

Several ongoing IP activities will support MMI-1 and be coordinated with the activities within MMI-1. These include, but are not limited to MPP-2, OGC Web Services Initiative, and GeoFusion Infrastructure. These activities will be integrated with those of MMI-1 in order to take advantage of economies of scale plus innovations coming from MMI-1. In that light, MMI-1 can be considered a subset of OWS-1 in that a common set of web services will be addressed in both initiatives. For a fuller understanding of this overall OGC context please review the OWS-1 Threadset 1 RFQ Annexes A (which details requirements and tasks) and B (which contains the OWS-1 architecture) available at http://ip.opengis.org/ows/rfq/010725_OWS_RFQ.zip.

To accomplish this integration there will be "bridges" between MMI-1 and the Integrated Initiatives. These bridges will occur when the sponsors and IP Team determine a significant milestone in the process of either MMI-1 or the relevant pilot has occurred. A TEM will be conducted between the relevant Integrated Initiative participants and sponsors and those of MMI-1 to determine the maturity and desirability of incorporating the candidate interface into the associated Integrated Initiative.

3. MMI-1 Resource Plan

The MMI-1 Resource Plan refines Sponsor requirements defined in Annex A into three Tiers and outlines a phased approach for developing the MMI-1 Initiative via a series of RFQs. This RFQ represents the current state of sponsor requirements and funding support for MMI-1 activities. However, Sponsors are identifying resources to apply to MMI-1 and when that identification is complete a follow-up RFQ(s) will be released documenting the change in the state of the requirements. Annex A is intended to accommodate the anticipated set of requirements that will be shown in any further RFQs. This Tier structure is subject to change as Sponsor funding becomes available. Such changes will be reflected in the operational activities by shifting, when appropriate from Tier 1 to Tier 2 and so forth.

Tier 1 Requirements are those that are identified by the Sponsors as important and have associated funding at levels adequate to provide cost-share funding to Participants. MMI-1 funding will address Tier 1. Annexes A and B will define these requirements in detail. Only proposed activities that address Tier 1 requirements will be considered for cost sharing funds.

Tier 2 Requirements are those that are identified by the Sponsors as important and may have associated funding at levels adequate to provide cost-share funding to Participants at some near-future time. Sponsors in the process of defining resources have reviewed these requirements and are anticipated to bring funding online when their fiscal cycle permits.

Tier 3 requirements constitute the remainder of the requirements in Annex A. At this point in time these requirements are not identified as receiving specific funding. However, OGC is identifying new sponsors and they will be given the opportunity to review the Tier 3 requirements and make appropriate funding decisions.

The Common Architecture is acknowledges a required technology for MMI-1 across the three tiers. Elements of the Common Architecture are understood to be those that can be redundantly used by more than one OGC Web Service. The Sponsors and the Architecture Team have reviewed the suite of requirements to determine which services from all Tiers fall into this category. The Sponsors have agreed to joint funding of this cross cutting suite of services.

1. MMI-1 RFQ Scope

The purpose of this Request For Quotation is to solicit your proposal in response to a refined set of requirements for the OpenGIS Consortium (OGC) Multi-hazard Mapping Initiative (MMI-1). Using the attached template and forms, please submit your technical proposal, your cost sharing request, and your in-kind contribution declaration. Please limit your response to only those elements defined as and associated with MMI-1. Table 1 describes the high level requirements associated with this initiative.

Table 1�High Level MMI-1 Requirements and Associated Elements\

MMI-1 Requirements	Elements
Common Architecture	Basic Services Model/General Services Model Service Registries Data Registries
Web Mapping	Web Mapping Service 1.2.x Web Feature Service 1.x
Web Imagery Enablement	Imagery Clients

 

5. Assignment of Week Numbers

The following calendar shows the assignment of Week Numbers for purposes of MMI-1 activity reporting. Yellow highlighting indicates key milestone dates and red text indicates OGC TC Weeks.

Table 2-MMI-1 Calendar

1 Overview *

2 Communications Plan *

1. Overview

This document describes the Communications Plan for the Multi-hazard Mapping Initiative Phase 1 (MMI-1) program. It defines the approach, including policies and procedures, which OGC will use in providing for effective communications between and among initiative Participants, Sponsors, and the Interoperability Program (IP) Staff.

Each participating organization, regardless of any teaming arrangement, shall provide a designated Point of Contact (POC) who will be available for scheduled communications about MMI-1 status. That POC shall provide backups or alternatives for ad hoc discussions of IP issues that may arise. They will provide various means for contacting either themselves or their alternates. Participants shall provide documentation of their understanding, acceptance, and handling of the communications plan with their proposal.

Various Team Leads will be designated to assist with the conduct of MMI-1 operations. Those Team Leads shall ensure that IP Operations, responsible parties, and the leads themselves have a mutual understanding of MMI-1 tasks that are assigned during the course of the initiative. Team leads will also work to ensure that tasks stay on schedule and any issues are communicated and worked rapidly with management.

2. Communications Plan

1. OWS Email Reflector

Electronic mail communications should be sent to the single email reflector for the MMI-1. This email reflector is mmi1@opengis.org. There will be heavy traffic on this e-mail reflector, so to make it easier to follow pertinent threads and to avoid back channel communications, please follow the guidelines listed below. Reminders will be issued if the guidelines are not used.

Participants should carefully consider the subject of email. All email to this list should contain the Prefix in the Subject line of each message: [MMI1]

If your email is primarily of interest to a particular thread, for example, Web Map Servers, make the subject:

[MMI1] WebMapServer - the rest of the subject

Several focused working groups (WGs) will be formed during the kickoff week. The exact nature and naming conventions for those WGs will be decided at that time. Email that is pertinent only to the members of the WG should have subject lines like this hypothetical "abc" WG team:

[MMI1] abc- the rest of the subject

If your email is administrative in nature, make the subject either:

[MMI1] ADMIN- the rest of the subject

Finally, if your email is a general announcement email to all Participants, make the subject:

[MMI1] ALL- the rest of the subject

It is important to remember that the list server software is very good about managing email threads, but only as good as we make it. If you are replying to a message, please do not change the subject line unless you intend to start a new subject thread. On the contrary, if you are starting a new thought or discussion, please create a new message and send it to the list.

The OGC IP lists get heavy traffic. In order to facilitate efficient handling of that traffic and to reduce redundancy, all replies will go to the list not the sender. As long as the list addresses are set in the To: field, if a message is sent to multiple lists and you are on those multiple lists, you will receive only one copy of the message. Therefore, we recommend the use of the following protocol:

To: the relevant lists

Cc: to individuals you would like to receive redundant copies or whom you know not to be on the list

PLEASE NOTE: the email reflector is not intended for exchanging files with other participants. A procedure for uploading files to the project web sites is described below. That procedure will automatically alert all participants of file uploads.

 

3. MMI-1 Participant Web Site

• MMI-1 Interoperability Program Page�Links to archived, current and future IP Initiatives (http://ip.opengis.org)
• MMI-1 Participant Home Page�the home page for the Multi-hazard Mapping Initiative (http://ip.opengis.org/mmi1)
• Action Items�database reports on action items and their weekly status
• Contact Information�a listing of the participants, their roles and responsibilities
• Demonstration Information�a growing list of requirements, resources and details regarding Initiative Demonstrations
• Document Archives�links to the Document Uploader (see next section) and the Archive of documentation of interest to the Initiative, including the MMI-1 architecture, concept of operations, etc.
• Email & Communications�detailed help on email reflectors and how to use communications effectively, also provides links to email archives, this document and updates to it.
• Geospatial Data Repository�datasets for testing and demonstration of interfaces and components
• Schedule�items relating to the program schedule, including telecon and face-to-face meetings.
• Technical Architecture�initial and updated versions of the technical architecture
• Tie Descriptions�Technology Integration Experiments
• Work Breakdown Structure�Plan for what each organization is scheduled and contracted to produce
• Working Group Home Pages�home pages for specific working groups supporting interface and/or protocol definition activities or related activities will be added as needed.

1. Web-Based Upload Mechanism

1. The following web pages at the site shall have the Web-based upload mechanism available as a hyperlink: any of the Working Group Home Pages and the Document Archives web page. If upload access to other pages is required, make that requirement known to the Operations Manager, Jim Stephens, and access will be set up for the particular page. The participant shall connect via a personal log-on (using a common password) using a web browser.
2. The participant shall load the desired web page.
3. The participant shall put a single file using the naming convention described below. File submissions may be packaged (even if only a single file) using a) Winzip (for Windows-based submissions) or b) tar and gzip or c) tar and compress for (Unix-based submissions).
4. The naming convention shall be [date]_[org]_[short title]_[vX].[ext] where:

• date is the date of submission in the format ccyymmdd (e.g., for 19 June, 2001 use 20010619),
• org is the submitting organizations name or acronym without spaces or any other punctuation (e.g., for the Open GIS Consortium use ogc),
• short title is a shortened title for the content of the submission (e.g., for this document one might choose commplan or communicationsplan), and
• version if necessary
• ext is a typical three letter extension indicating the program required to process the file such as ZIP for WinZip DOC for Microsoft Word, PPT for Microsoft PowerPoint or MDL for Rational Rose.

1. The participant shall in the upload process provide certain metadata for tracking and recognizing the files on-line.

1. The participant shall click "Submit". The system will dynamically generate an email forwarded to the mmi1@opengis.org list containing the URL where the submitted file can be obtained and the metadata associated with that file.

1. Virtual Workplace

The OGC Interoperability Program has a TeamWave Server, with access to free client software. The Virtual Workplace can provide online virtual sharing of information to be used in conjunction with Teleconferences. More details will be provided in the Communications area of the website.

2. Teleconference Procedure

There are three phases in the execution of a MMI-1 Telecon. These phases are initiation, planning, and execution. The procedure for each phase is defined below.

1. Teleconference Initiation

Due to the need to carefully manage the scarce resources of the IP effort a telecon must be appropriately planned and approved by the IP Operations or Program Manager.

An authorized discussion leader must lead a telecon. A list of authorized discussion leaders will be made available on the MMI-1 Participant Web Site.

Any participant may initiate a telecon by first contacting an authorized discussion leader to pre-plan the telecon.

The authorized discussion leader must then obtain approval from the IP Operations Manager or the IP Program Manager.

This approval is made by sending an email with the subject line "IP Telecon Request" to MMI1_telecon@opengis.org with the following format and content.

Proposed Date and Time: the proposed date and time

Purpose: a description of the purpose of the telecon

Designated Discussion Leader: the name, organization, and email of the designated discussion leader (must have been authorized to act in this role previously and must be available for the proposed telecon)

Participants: a list of participants (name, organization, and email required) that should be involved

Expected Duration: an estimate of the expected duration of the telecon

Agenda: a detailed agenda, including the time to be spent on each topic

Approval must be sought at least one business day prior to the proposed telecon date. It would be desirable for telecons involving Australian, European, Japanese, and North American participants to be scheduled and announced at least two days in advance.

If the request is approved the IP Operations Manager will then take over the initiation of the telecon by forwarding the request to the appropriate OGC Staff member for planning.

If the request is denied, the IP Operations Manager will work with the requesting individual, organization, or group to reach a satisfactory solution to all.

2. Telecon Planning

The appropriate OGC Staff will arrange the teleconference and notify all of the listed participants by electronic mail of the teleconference details. The details will also be posted in an area of the MMI-1 Participant Web Site (NOTE: This means that gbuehler@opengis.org must be included in all email notifications). The details will include:

Date and Time: the date and time of the teleconference (all times are Eastern, unless otherwise specified)

Access Number: the access number used by participants to call into the conference center

Passcode: the passcode number used to access the appropriate telecon, once connected to the conference center

Purpose: the purpose as stated in the approved request

Designated Discussion Leader: the name, organization, and email of the designated discussion leader

Participants: a list of participants (name, organization, and email required) that should be involved

Expected Duration: an estimate of the expected duration of the telecon

Agenda: a detailed agenda, including the time to be spent on each topic

3. Telecon Execution

All participants calling into the telecon at the appointed date and time will execute the telecon.

Telecons should not be extended. This requires that the designated discussion leader keep the telecon on schedule with the agenda. Obviously, this means that vital agenda items should be covered first in the agenda and, if agenda items run over the time allotted, the discussion leader will need to adjust the agenda by deleting or shortening later topics.

The designated discussion leader must keep notes of the telecon and forward a summary to the IP Program Manager. The notes should contain documentation of decisions reached, action items (including a description and action item holder), and issues for resolution by IP Staff.

3. Progress Reporting

Inkind and Funding [ .xls ]
Request for Quotation (RFQ) Complete Package [ .zip ]

Supporting Documentation:
Conceptual Architecture [ .html ] [ .ppt ]