SOLICITATION NOTICE
T -- GeoEntity Extraction/Geocoding Systems
- Notice Date
- 6/26/2008
- Notice Type
- Modification/Amendment
- NAICS
- 541370
— Surveying and Mapping (except Geophysical) Services
- Contracting Office
- Office of the Chief Procurement Officer, Washington, District of Columbia, 20528, United States
- ZIP Code
- 20528
- Solicitation Number
- HSHQDC-08-Q-00219
- Response Due
- 7/15/2008 10:00:00 AM
- Archive Date
- 7/16/2008
- Point of Contact
- Carrie A Herndon,, Phone: 202-447-5559
- E-Mail Address
-
carrie.a.herndon@dhs.gov
- Small Business Set-Aside
- N/A
- Description
- 1. OBJECTIVE & SCOPE 1.1 INTRODUCTION As part of its ongoing mission to align information technology investments and improve geospatial service delivery across the Department of Homeland Security (DHS), the Geospatial Management Office (GMO), under the direction of the DHS Office of the Chief Information Officer (CIO) is investigating the development of a centralized geocoding platform (service and/or system) which will best serve the broad geocoding needs of the Department and its component agencies. The objective of this request for information (RFI) is to solicit innovative and efficient geocoding methodologies that provide the GMO with insight into the current ‘state of the art’ both from a data content and system perspective. The information collected will help to establish a common framework from which to plan for any enterprise geocoding solution the Department may wish to develop in the future. 1.2 BACKGROUND The GMO works in a technical advisory capacity to maximize DHS’s return on geospatial technology investments, strengthen cross-mission information sharing, and assists DHS component programs in developing collaborative technology that supports their mission domain while conforming to interoperable standards and the IT policies of the Department. With this mission in mind, the GMO has developed a geospatial solutions architecture, the Geospatial Information Infrastructure (GII), which is the technology target for the Department and its components. As part of this architecture development, the GMO has identified the need for a centralized geocoding solution that can offer the scalability and agility to meet the diverse needs of the Department’s enforcement, preparedness, response, recovery mission areas. 1.3 CURRENT STATE OF OPERATIONS At present there are approximately 15 known geocoding engines servicing various system requirements within DHS. In this current environment, each geocoding engine and their associated reference layers are maintained by a variety of technology, data, staff and other ongoing operations and maintenance infrastructure. Additionally the amount and availability of geocoding functionality from these various geocoding services is largely inaccessible to the broader end users. These current disparate configurations also hinder the ability for remote staff to access geocoding services in a manner that is timely and efficient. 1.4 FUTURE STATE OF OPERATIONS The future geocoding environment for DHS will be consolidated to a single solution that supports Department-wide geocoding operations. This fully integrated solution, will help to minimize overall levels of IT investment, enhance overall service delivery, and will be implemented in one of DHS’s two data warehouses. Although this more centralized environment will likely exist within an infrastructure controlled and managed by the government, it should also be able to leverage distributed services for certain aspects of desired functionality and/or take advantage of a vendor supplied service delivery that might be cost prohibitive for the government to implement or would offer the desired levels of dynamic failover to a redundant service. Centralizing DHS’s geocoding requirements also meets the intent of DHS Management Objective 4030, and the Department’s Investment Portfolio Management Program. This future geocoding solution will support DHS business processes in the areas of: •‘Ad hoc’ street address matching to include validation, standardization, and geocoding, •Batch processing of street addresses to include validation, standardization, and geocoding, •Address validation, certification, correction, and other interpolative capabilities •Methods of determining and matching the location of landmarks, cities, towns, and other commonly-used geographic references (i.e. ‘Gazetteer’ level functionality) •Proximal intelligence or supplemental detail on environs of geocoded results beyond simple latitude and longitude returns (i.e. demographics, political boundaries, census designation, Congressional Districts etc…) •Ability to load and manage custom taxonomies, data dictionaries and GIS datasets. •Reverse geocoding capabilities to translate incoming coordinate data and dimensionalize that geo-location data to a local street address, nearest populated place etc... While serving the businesses processes described above are of immediate interest to the Department and the majority of its mission owners and operators, it is conceivable that a future state of operations may also optionally contain a capability to search text documents using various geographic keywords and display that information geographically on a map interface. This future geocoding environment will be implemented in such a way as to support the broadest end users possible, the following DHS components are specifically in scope for this desired implementation given known requirements and existing mission needs: •Immigration Customs Enforcement (ICE) •Intelligence & Analysis (I&A) •Federal Emergency Management Agency (FEMA) •U.S. Secret Service (USSS) •National Operations Center (NOC) •U.S. Coast Guard (USCG) Anticipated volume/usage metrics: •The estimated monthly volume of ‘ad hoc’ geocoding requests………. …. 500,000 •The estimated monthly volume of batch geocoding requests……………... 1,000,000 •The estimated monthly volume of unstructured (gazetteer) requests……. 20,000,000 Characteristics of the future solution may include but are not necessarily limited to the following: •Systems provisioned via service oriented architectures/automation interfaces, •Systems hosted and maintained by solution provider outside DHS firewalls, •Systems hosted and maintained by DHS within its firewalls, •Systems that provide graphical user interfaces 2. RESPONSE GUIDELINES & REQUIRED FORMAT 2.1 RESPONSE GUIDELINES Respondents shall provide a technical capabilities statement not to exceed ten (10) pages in length, not including the Scenarios. Each Scenario shall be 2 pages in length. All page limitations are based on single sided pages, 8.5 x 11 inch paper, single spaced, Arial or Times New Roman typeface no smaller than 12-point (smaller fonts of no less than 8-point are acceptable for graphics, figures, tables, footnotes and legends), and 1-inch margins. Respondents should ensure that their submittals are complete and address all items outlined within this RFI. In the event that a particular respondent is unable to outline a total solution, DHS encourages the respondent to submit in the role of a ‘primary supplier’ and propose the use of any third party products as needed to develop or compliment their proposed total solution. Respondents may provide additional promotional literature in addition to their response as long as the literature conforms with the response format. 2.2 COST MODELS/ROUGH ORDER OF MAGNITUDE While a specific cost proposal is not expected, respondents should outline any cost models, a rough order of magnitude, or summary of advantages in total cost of ownership believed to be associated with their proposed solution. The cost model/rough order of magnitude may be in Excel format. 2.3 RESPONSE FORMAT Responses to this RFI shall use the format outlined below. The document format shall be either Microsoft Word [.doc], Adobe Acrobat [.pdf] formats, or Excel for the cost model only. In order to better assist in the evaluation of submittals to this RFI, respondents are encouraged to prepare a technical capabilities statement which closely adheres to the following format. i. Respondent(s) Background/Experience Respondents should briefly describe their company’s background and experience in providing geocoding solutions of similar size and scope. ii. Client References As an attachment, respondents should provide a minimum of three detailed references that are comparable to DHS’s future operating environment, configuration, complexity, and/or type of geocoding services requested. Minimally any references provided should include the following information: * Reference name * Title * Contact information * Industry * Application/Functional Modules Implemented * Release Number * Technology Platform iii. Overview of Proposed Solution(s) Respondents should outline how their proposed solution(s) meets the geocoding needs of DHS and describe any summary of benefits as proposed. iv. Technical Respondents should describe in detail the proposed feature/functionality of their geocoding solution(s). Responses should outline any special considerations with regard to system installation, application set up, environment configuration, and ongoing maintenance. All technical responses should specifically address: • A solution that will support the “future state” envisioned by DHS • Application Programming Interfaces (APIs) • Software Development Kits (SDKs) • Desktop or Graphical User Interfaces (GUIs) • Data Source and Quality / Address Correction Functionality Differentiated by Geographical Areas • Latency of Data and Available Data Updates Differentiated by Geographical Areas • Response to address validation, address matching, and geocoding request (contents, precision, indicators) • Handling of Units, Apartments, Sub-addresses • Gazetteer Capacity (Support for landmarks, aliases, etc.) • Custom/Supplemental Address Dictionaries or Taxonomies for Gazetteer Functionality • Ability to Geocode an Intersection and the Methodology Used for Intersection Matching • Business Rules, Heuristic ‘Fallback’ Options, Sensitivity, Conflict Resolution • Ability to ‘Toggle’ Between Exact Match, Best Match, or Multiple Matches • Alternative Lat/Long’s (Parcel Centroid, Front Door, Rooftop) • Description of Proposed Hosted Services (reliability, transaction models etc…) • Hardware Appliances/Configuration (for use behind DHS firewall) • Compliance with Federal Enterprise Architecture (FEA) • Adaptability/Compliance with Existing DHS IT Policy/Systems • Performance Metrics • Scalability Options • Geographic Coverage (International, U.S., and Territories) • Supported Operating System (OS) Platforms • Support for Virtualization or Blade Server Environment(s) • Other Hardware Requirements or Known Limitations Optionally, respondents should also use this section to describe further the extensibility of their technical solution which may address a capability to search text documents using geographic keywords and parse that information in an organized way so that it can be easily referenced and viewed by a DHS end user with a map display. Technical responses to this optional desired functionality should at a minimum specifically address: • Recognize, identify, tag, and extract place names (geographic feature names, place names, locations, coordinates) in unstructured text (documents, messages, etc.) • Recognize, identify, tag, and extract coordinates (geographic feature names, place names, locations, coordinates) in unstructured text (documents, messages, etc.) • Perform place name disambiguation through the use of local context found within unstructured content. (For example, Manhattan mentioned in the same paragraph or context as Kansas is likely not to refer to Manhattan, NY) • Operate bi-directionally (place name to location and location to place name) v. Training & Documentation Respondents should detail any needed training required to achieve and maintain their proposed geocoding solution. vi. System Stability & Support Product Support Levels / Service Level Agreement Product Warranty Maintenance, Upgrades & Miscellaneous Support vii. Cost Models Proposed Solution / Application Modules User/Developer Technical Support Perceived Total Cost of Ownership viii. DHS Use Case Scenarios In addition to describing the system/architectural elements of their solution(s), respondents should also outline how end users would specifically interact with their proposed solution(s) in the following use case scenarios: • Batch Geocoding Use Case: A program analyst has recently received a comma delimited export file from an existing DHS mission critical application. This file contains several hundred thousand to several million addresses which needs to be geocoded in a batch process to support follow on analysis. Some of these records share a single street address (i.e. commercial office or high rise apartment building). Any address which is not directly matched to a particular reference data set should be re-geocoded using multiple reference data sources to reconcile address mismatches. Assuming this analyst has access to the DHS intranet as well as the outside internet, please describe how this end user would interact with the proposed solution to achieve a geocoding match rate above 85% • ‘Gazetteer’ Level Functionality: A variety of DHS mission domains require access to a rapid map display functionality based on simple keyword searches for purposes of geolocation and to better orient themselves to a particular area of interest quickly. Typical keyword searches used might include: • Exact/Partial Street Address • City/Neighborhood/County Name • Landmark Alias (i.e Empire State Building, Golden Gate Bridge etc…) For example, a good Samaritan observes a signal flare from the 3rd floor of his beach front hotel and telephones in to a local US Coast Guard (USCG) Search and Rescue (SAR) operations center. During the call the SAR controller must rapidly translate that observer and observed information to a corresponding Latitude/Longitude, in order to best vector USCG assets to aid those in distress. Please describe how the proposed geocoding solution(s) might support this potential ‘call center’ application and provide a flexible ‘gazetteer’ level functionality to both DHS end users with and without outside internet connectivity. • ‘Ad-hoc’ Interactive Geocoding from a GIS Enabled Desktop Workstation Describe how the proposed solution(s) could support a geospatial analyst using Commercial Off-the-Shelf (COTS) Geographic Information System (GIS) software application to support geocoding in an ‘ad hoc’ or interactive way. Respondents should describe in detail how the proposed solution leverages both existing COTS GIS functionality and any proposed ‘plug-ins’, additional applications, and/or toolbar(s) to support accurate and efficient geocoding. Respondents may assume the geospatial analyst has access to both the DHS intranet and the wider internet. • ‘Geo’-Entity Extraction from a Structured/Unstructured Text Please describe how the proposed solution(s) might support a geographic keyword search across a variety of text based documents, messages, and/or reports and then display the results in a geographic context on a map display to better inform analysis and/or decision making. 3.0 RESPONSE DEADLINE AND POINT OF CONTACT INFORMATION 3.1 Response Deadline Technical Capabilities Statements, Cost Models, and all supporting documentation are due via e-mail to the Contract Specialist by 10:00 am EDT July 15, 2008. The cutoff date for receipt of all questions regarding this RFI is June 23, 2008. Questions shall be submitted to the Contract Specialist via e-mail no later than 2:00 pm, EDT on this date. The government will make its best efforts to respond to all questions within 24 hours. 3.1 Point of Contact The point of contact for responses and questions is Carrie Herndon, Contract Specialist. Please submit all questions and responses to carrie.a.herndon@dhs.gov. Respondents should note that this RFI is being issued solely for information and planning purposes and does not constitute an Invitation for Bids (IFB), a request for Proposals (RFP), a Request for Quotation or an indication that the Government will contract for any items and/or services contained in this notice. All information received in response to this notice that is marked ‘Proprietary’ will be handled accordingly. Responses to this notice will not be returned. In submitting a response, you are solely responsible and accountable for all of the expenses associated with your response. The following provision(s) is applicable to this notice and is hereby incorporated by reference: FAR 52.215-3 Request for Information or Solicitation for Planning Purposes (Oct 1997) The full text of this clause is available at: http://www.aqcuisition. gov/far/index.html 4.0 Questions Received 4.1 Questions Received as of 06/02/08 Question 1: If possible could you put me in contact with a POC and the subject office? I would like to learn more about the GMO and determine if there's anything we can do to assist. Response 1: All questions are to be directed to the contracting officer. All questions will be adjudicated and responses will be posted as amendments/modifications to the RFI to be viewed by all solution providers. Question 2: Do we need to be listed on the GSA to participate in this project? IS there any registration required for SRC to do to qualify as a participant on this project? Response 2: No. There is no registration or prequalification needed to reply to an RFI, responses are welcome from any interested solution provider. This is a RFI and the Government strongly desires the broadest responses possible. 4.2 Questions Received as of 6/12/08 Question 3: I would like clarification on several requirements listed in the RFI: Custom/Supplemental Address Dictionaries or Taxonomies for Gazetteer Functionality – Clarification of the meaning of this requirement Response 3: Certain DHS components may have individual requirements to leverage customized or colloquial address dictionaries as supplemental resources to also reference a particular location, sector, neighborhood, and/or place of interest. These data reference sources are expected to be in addition to more known reference data to support a geocoding system(s), such as those developed toward postal addressing standards. Respondents should describe if (and how) additional address/location dictionaries could be supported by their proposed solution. Question 4: I would like clarification on several requirements listed in the RFI: Business Rules, Heuristic ‘Fallback’ Options, Sensitivity, Conflict Resolution - Clarification of the meaning of this requirement Response 4: Respondents should describe how their proposed solution manages address/location verification and what rule(s) base is used to determine an exact geocode. In the event location matches are not exact, respondents should further describe the heuristic methodology by which alternate match candidates can be determined. Where applicable, respondents should also describe how the heuristic methodology used for determining alternate match candidate(s) can be further refined or ‘tuned’. Question 5: I would like clarification on several requirements listed in the RFI: Adaptability/Compliance with Existing DHS IT Policy/Systems – Can the IT Policy/System be downloaded? Response 5: DHS is electing to remove “DHS IT Policy/Systems”. This sentence should now read: “Adaptability/Compliance with existing industry best practices” 4.3 Questions Received as of 6/23/08 Question 6: Client References - As an attachment, respondents should provide a minimum of three detailed references…. (a) Is this part of the 10 page limit? Response 6: This is not part of the 10 page limit. It is a separate attachment. Question 7: Cost Models - Proposed Solution / Application Modules, User/Developer Technical Support, Perceived Total Cost of Ownership – Is this part of the 10 page limit? This is not part of the 10 page limit. It is a separate attachment. Question 8: If we include a Title Page and Table of Contents, will they be counted within the 10 page limit? Response 8: A title page and Table of Contents will not be counted towards the 10 page limit. Question 9: There are approximately 15 known geocoding engines currently in use within DHS. Can you please provide a list of the 15 geocoding engines? Response 9: There are a variety of single-use licenses currently in use across the DHS enterprise. Components also utilize available web services for ad-hoc requirements. It is DHS’ strategy to develop an enterprise solution. Question 10: Can you please describe the underlying sources of geospatial data presently in use and the frequency of updates to this data? For example, does the data provider update the data weekly, monthly, quarterly, etc? Response 10: DHS components develop an array of mission-specific data sets. The update frequency for these mission-specific data sets varies tremendously. For example, the DHS Common Operating Data that includes the HSIP Gold data set is currently updated on an annual basis. Question 11: Related to the above, who owns the current data? Is the majority of data commercially provided? Are there any restrictions on release of the data to end-users in the field due to licensing or source of the data? Response 11: DHS utilizes federal data as well as licensed data sets. Some commercial data sets are restricted to a single DHS Component. DHS desires to develop uniform data and licensing policies to the maximum extent that is practical. Question 12: What level of interface, if any, currently exists between the systems and data sources in use? Response 12: Some DHS programs such as the FEMA Map Modernization Program and programs for the USCG have robust interfaces to underlying data. Many smaller programs do not. It is DHS’ desire to create a solution that can be consumed across the enterprise. Question 13: DHS desires a fully integrated solution to address challenges with the current state of operations. Potential solutions can range from interfaces to existing systems, full data migration to a single solution set, or a combination. Does DHS have a preferred approach? Response 13: Vendors and encouraged to provide what they consider is the best technical solution for DHS. Question 14: Due to the diversity of the systems supporting current operations and the desire to migrate toward a single geocoding solution, is there a specific standard for geocoding data DHS prefers? Response 14: DHS does not have any specific standards for geocoding. Question 15: There are no references to security requirements for the future state of operations. Are different levels of classification anticipated? Will there be unique handling requirements surrounding all or some of the data? Response 15: It is anticipated that any technical solution will operate at all classification levels. Question 16: Gazetteer Level Functionality: Does DHS currently use a Gazetteer and, if so, what Gazetteer is used? Response 16: DHS has single-use licenses from a variety of solution providers; users also access currently available web services. Question 17: There is a requirement to address recognition, identification and tagging of data in unstructured documents. Does DHS have a standard for metadata tagging of geospatial data? Response 17: DHS uses metadata standards developed by the Federal Geographic Data Committee http://www.fgdc.gov/metadata/geospatial-metadata-standards. As well as existing standards by the International Standards Organization http://metadata-standards.org/11179/. Question 18: Compliance with Federal Enterprise Architecture (FEA) – Please supply weblink or general information pertaining to FEA, so we may gain an understanding of how the technology and services in our proposal complies. Response 18: Compliance with Federal Enterprise Architecture (FEA) – Please supply weblink or general information pertaining to FEA, so we may gain an understanding of how the technology and services in our proposal complies. The following link pertains to the geospatial profile of the Federal Enterprise Architecture and may provide more focused insight than the FEA. http://www.fgdc.gov/fgdc-news/geoprofile20050131 Question 19: Adaptability/Compliance with Existing DHS IT Policy/Systems -- Please supply weblink or general information pertaining to existing DHS IT Policy/Systems, so we may gain an understanding of how the technology and services in our proposal complies. Response 19: DHS is electing to remove “DHS IT Policy/Systems.” This sentence should now read: “Adaptability/Compliance with existing industry best practices.” Question 20: WHAT CURRENT LEGACY DATASET(S) WILL A NEW GEOCODING SOLUTION BE REQUIRED TO LEVERAGE? Response 20: DHS HAS NOT IDENTIFIED SPECIFIC DATA SETS AT THIS TIME. Question 21: Latency of Data and Available Data Updates Differentiated by Geographical Areas – Is it DHS’ intent to have a new solution update the reference databases on a per-country basis? Frequency? Response 21: Data providers are encouraged to make recommendations on the currency and update frequency needed in order to achieve optimal performance for an enterprise solution for DHS. Question 22: DHS Management Objective 4030 -Please supply information pertaining to the stated objective. Response 22: The DHS Spatial Data Infrastructure (SDI), a subset of the Enterprise Architecture, consists of geographic information systems software and hardware, geospatial applications, data, standards, policies, programs, and the human resources necessary to acquire, process, analyze, store, maintain, distribute, and otherwise use geospatial data as a strategic asset for the Department of Homeland Security and the nation. The basis for an SDI is to identify and organize core capabilities that have common applications and to ensure the transport of data, via compatible formatting, across DHS. Completing and maintaining an SDI with integrated applications and systems will provide the level of geospatial preparedness required to protect the nation’s critical infrastructure, strategic assets, the economic base, and America’s citizens. Question 23: DHS Investment Portfolio Management Program -- Please supply information pertaining to the referenced program. Response 23: DHS Investment Portfolio Management Program define DHS IT portfolios by developing groups of related IT investments and assets into portfolios based on mission areas, strategic goals, objectives, and infrastructure requirements, irrespective of organizational boundaries. Processes to manage these portfolios improve visibility into the relationships and interfaces between investments, reduce duplicative investments in systems and platforms, and enable the DHS to more effectively allocate resources to provide the greatest benefit to the enterprise. Question 24: GMO GII – Please supply the referenced architecture / infrastructure information so we may gain an understanding of the Department’s overall objectives. Response 24: The Geospatial Information Infrastructure (GII) systems architecture was designed as the DHS enterprise geospatial solution that allows users to access a centralized platform of data and geospatial services that will serve as the foundation for the DHS common geospatial data warehouse. The GII addresses the need to establish enterprise-class direct access to the Common Geospatial Data, provide a centralized location for data sharing from a common operating dataset, which consolidates operations and maintenance costs, establish the foundation for an extensible geospatial information infrastructure that may be readily adopted and leveraged by all users across the DHS geospatial user community and to establish a central storehouse for raster data products such as aerial and satellite imagery that will serve the entirety of the DHS geospatial community. Question 25: What type of funding is envisioned for the acquisition that would likely emerge from the Geospatial Management Office (GMO) review of the RFI responses? Specifically, is GMO looking for commercial-off-the-shelf (COTS) systems that are ready to be installed to address the RFI’s lists of capabilities, or would information about new research results be considered a useful response to the RFI? Two other approaches are to identify whether (a) 6.1 (basic research), 6.2 (applied research) or 6.3 funding is available, or (b) software is desired at Technology Readiness Levels (TRL) 2 or 9 (or somewhere along the range). Response 25: A fiscal strategy for an enterprise geocoding solution will be developed based on the technical solutions provided by this RFI. Question 26: We have a component capability that might be useful to a prime respondent. Is there a mechanism related to the RFI by which we could indicate our availability to team with another company? Response 26: Vendors are encouraged to collaborate, if necessary, to provide the best solution for DHS. Question 27: What are the 15 geocoding engines that are currently used by DHS (as identified in section 1.3)? Response 27: There are a variety of single-use licenses currently in use across the DHS enterprise. Components also utilize available web services for ad-hoc requirements. It is DHS’ strategy to develop an enterprise solution. Question 28: Is GMO interested in information beyond the RFI’s list of desired capabilities? Specifically, is GMO interested in research results for capabilities beyond those that the RFI details? Response 28: Yes. Vendors are encouraged to provide the best solution for DHS.
- Web Link
-
FedBizOpps Complete View
(https://www.fbo.gov/?s=opportunity&mode=form&id=95f500a469bba6683e17c34b2fa89348&tab=core&_cview=1)
- Record
- SN01601481-W 20080628/080626215742-5186522de149283d62229a973319a098 (fbodaily.com)
- Source
-
FedBizOpps Link to This Notice
(may not be valid after Archive Date)
| FSG Index | This Issue's Index | Today's FBO Daily Index Page |