SOLICITATION NOTICE
T -- GeoEntity Extraction/Geocoding Systems
- Notice Date
- 6/2/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.
- Web Link
-
FedBizOpps Complete View
(https://www.fbo.gov/?s=opportunity&mode=form&id=9dcf645b321e231202eeda04f0fae453&tab=core&_cview=1)
- Record
- SN01584895-W 20080604/080602220328-9dcf645b321e231202eeda04f0fae453 (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 |