Emergency Mapping Symbology, Phase 1

Go Directly to the Request for Quotation Document
Go Directly to the Request for Quotation Clarifications
The Emergency Mapping Symbology Interoperability Program Initiative will be a testbed initiative focusing on maturing the Style Management Service (SMS) and the Styled Layer Descriptor (SLD) with application to Emergency Mapping Symbology. The project will test by enabling the use of multiple symbol sets with one set of feature data. The symbology used will likely come from the following: Emergency Response Map Symbology (ERMS) – a map symbology set being defined by the FGDC’s Homeland Security Work Group. See: http://www.fgdc.gov/publications/homeland.html Geospatial Symbols (GeoSym) for Digital Displays. The map symbology set defined by DOD to portray Vector Product Format (VPF)data. Reference TBD. SMS is a service that was first described and demonstrated in the Open Web Services Phase 1.2 (OWS-1.2) test bed initiative. While SMS can be thought of as a type of service, it is in actuality a logical composition of design-patterns, service interfaces and encodings. As such, SMS defines architecture for enabling scalable and interoperable management of symbols and styles in support of cartographic portrayal processes.
Emergency Mapping Symbology (EMS) Request For Quotation and Call For Participation This call seeks interested technology providers to make proposals in response to a defined set of requirements addressing interoperability needs for the use of symbology in emergency mapping. The EMS Initiative will mature OGC's specification framework for interoperable geographic symbolization while simultaneously testing emerging standard map symbol sets for emergency response developed by national-level agencies. Participants will be addressing sponsor requirements including the development of a client for publishing, managing, and previewing particular symbolization configurations, testing the assignment of symbols to particular feature types from a feature level data store, testing and enhancement of the Style Layer Descriptor (SLD)Implementation Specification and its use in Web Mapping Service implementations to support the portrayal specified symbol sets, and testing and enhancing the Style Management Services Specification (SMS). EMS is an opportunity for vendors, users, and other interested parties to mutually define services, interfaces and protocols in the context of a hands-on engineering experience, resulting in Interoperability Program Reports. This initiative is expected to help shape the future of interoperable technology to meet Emergency Management and Response requirements. Sponsors have provided cost-sharing funds to partially offset development costs associated with this initiative. Proposals are due by December 16, 2003. Click a link to download the .zip archive: Emergency Mapping Symbology, Phase 1 RFQ (doc format).zip Emergency Mapping Symbology, Phase 1 RFQ (pdf format).zip In-kind and Cost share worksheet
Emergency Mapping Symbology (EMS) RFQ Clarifications Question #1: Where is the Proposal Template? Clarification #1: The above ZIP Packages have been updated to include the Proposal Template. Question #2: Section 5.1 of the EMS-1 RFQ [Main Body] specifies a proposal page limit of 10 pages. Section 5.4 is at odds with that. Clarification #2: There is a 10 page limit for proposals in response to the EMS-1 RFQ. Section 5.4 should read: "Provide an introduction to the contents of your proposal and its benefits. There are no specific page limitations on the individual sections of the proposal response, although the proposal submission should be limited to 10 pages." Question #3: Section 5.4 of the EMS-1 RFQ [Main Body] refers to Section 5.5, Past Performance, which is actually Section 5.6. It also contains editorial comments. Clarification #3: Section 5.4 should refer to Section 5.6 for Past Performance, instead of Section 5.5. See clarification above for corrected text for Section 5.4. Question #4: This concerns the references in the EMS requirements to WOS for SMS Symbol and Style storage/retrieval. Is this a mandatory requirement? Note that any ebRIM Registry can support (and most do) a local Repository that can store XML and other content. Since the styles and symbols are also metadata it makes more sense in our view to simply store these in the associated local repository rather than invoke an additional service. This approach is also much more secure. Are we allowed to submit a WRS with local repository support (part of ebRIM anyways) to handle all symbology and symbol management or is provision of a separate WOS required? Clarification #4: As stated in the EMS-1 RFQ (Main body, Annex A, and Annex B), WOS is a mandatory interface of the SMS architecture as first developed and demonstrated in the OWS1.2 IP initiative and documented in OGC Discussion Paper 03-031. The WOS interface provides an OWS-compatible service interface for Web-accessible repositories of style (SLD) and symbol documents. While it may be true that "ebRIM Registry can support a local repository that can store XML and other content" it is out of scope for EMS-1 to implement ebRIM Reg/Rep interfaces in lieu of the OWS CS-W (registry) and WOS (repository) interfaces. The ebRIM Registry/Repostory specifications are not elements of the SMS as defined in 03-031 nor are they part of the current OGC technical baseline. Like all OWS interfaces, however, the WOS interface may be backed in implementation by any suitable technology (ebRIM Reg/Rep being one example). While submitters are encouraged to address security issues and solutions in their proposals, there are no security requirements stipulated in the RFQ. Submitters may propose CS-W (aka WRS) implementations supporting local repository functions implementing WOS interface. Submitters are encouraged to explain the rationale for this or any other proposed approach. Question #5: The subject RFQ states: "Proposals must be received at OGC no later than 1200 EDT December 16, 2003." Clarification #5: The RFQ incorrectly stated eastern daylight time. Proposals are due at 1200 (Noon) Eastern Standard Time on 16 December. The RFQ should have stated: "Proposals must be received at OGC no later than 1200 (Noon) EST December 16, 2003." Question #6: How would OGC like proposers to represent their cost share requests and in-kind contribution declarations? Clarification #6: Using the In-kind and Cost share worksheet. Question #7: "We understand that the prevision of a WOS for the storage of map styles and symbology is mandatory. Can we interpret the clarification to mean that the WRS can be provided with a WOS Connector that enables WRS client requests (insert, update etc.) for styles, symbology managed by an external WOS or does the architecture require that the WRS client request information about the style, symbology from the WRS and then separately request the instances from the WOS." Clarification #7: The latter case was assumed. The former case may be acceptable. Keep in mind the disclaimer found in Section 1 (Overview) of Annex B: "The architecture presented herein is intended to be a starting point. This document should be considered a draft and extensions and modifications to this architecture will be generated from lessons learned through the EMS-1 and other OGC initiatives." To the degree that WRS (CSW) and WOS interfaces may be redundant (e.g., only one interface, not both, is needed to implement full SMS capabilities) or there are clear benefits in simplicity, efficiency or reuse to be gained in alternative approaches, then your response should elaborate the usage scenarios and describe preferred alternatives. Alternatives should not, however, depart from the set of technical baseline documents listed in Section 6 (Technology Viewpoint) of the EMS-1 RFQ. Regardless of approach, if you are proposing to provide SMS capabilities, it remains a requirement (Annex A, 3.1.2) to provide a Web-accessible implementation of the WOS interface for style and symbol object repositories.