Since 2003, E-911 dispatch data and communication standards and protocols have been undergoing a major redesign to accommodate Voice over Internet Protocol (VoIP) IP and cellular broadband technology. The initiative, known as Next Generation 911 (NG911), will enable emergency callers to transmit voice, photos, videos, and text messages to call centers known as public-safety answering points (PSAP). Perhaps equally important, NG911 transmits the caller’s latitude/longitude in order to route the closest first responders to the caller’s location. Transitioning to NG911 nationwide involves efforts at all levels of government to plan and deploy a continually evolving system of hardware, software, standards, policies, protocols, and training.
The National Emergency Number Association (NENA) considers GIS a critical component of NG911. Counties need accurate GIS datasets, such as address points, road centerlines with road names and address range data, cell towers, and PSAP boundaries, to accurately map the caller’s location and route emergency responders. County GIS programs create and maintain data used by the current 911 systems to operate E-911 dispatch centers and to update tax parcels, address points, and road centerlines.
County GIS programs have traditionally focused only on maintaining GIS data within their boundaries, resulting in discontinuous and inconsistent road centerline data across county boundaries that can lead to serious routing and dispatch problems. Creating a seamless and up-to-date regional road centerline dataset from individual county centerlines—each with inconsistent database structures and data standards—may seem difficult at first glance, but it doesn’t need to be.
Six counties in the Southeast Pennsylvania Task Force (SEPATF) region (Philadelphia, Bucks, Berks, Delaware, Chester, and Montgomery) are working collaboratively to prepare for the NG911 changes. These counties decided to adopt the NENA draft GIS data standard for regional road centerlines. Understanding the importance of GIS to NG911, the SEPATF worked closely with a team of GIS experts from geographIT®, a division of EBA Engineering, Inc., to deploy a new Amazon cloud-hosted GIS data collaboration environment using various GIS tools that save time and money, while improving data quality.
To create a regional set of GIS data conforming to NG911 standards, counties could submit their GIS data to a contracted vendor who transforms, edge matches, and standardizes the data. The vendor might then provide the standardized data back to the counties for use in their NG911 dispatch systems.
This approach has several drawbacks. First, less expensive options are available. Second, county GIS data structures usually support a variety of programs, such as transportation planning and asset management, so adopting a new database structure could negatively impact other uses. Third, counties frequently tie GIS data maintenance workflows to subdivision developments, and these result in GIS updates to tax parcels, address points, and road centerlines. When a contracted vendor standardizes GIS data, normal county data maintenance procedures are disrupted. The county must either retain a separate version of the standardized data for Public Safety E-911 dispatch or develop an integration process to incorporate the standardized data back into the county’s data.
For these reasons, the SEPATF decided to explore a collaborative approach to creating and maintaining regional NG911 GIS data with all counties participating. An “extract, transform, and load” (ETL) and QA/QC process automates the monthly creation of a standardized dataset—compliant to the NENA data model—that still allows each individual county to maintain their own GIS database structure and continue to make edits to their own source data. Counties can submit their data on a monthly basis to be processed by an automated ETL and QA/QC “engine” that generates a regional centerline dataset directly from the submitted data. Any errors in the data, such as discontinuous and inconsistent road centerline data between county boundaries, are automatically logged so they can be fixed. The counties can review all errors, make appropriate edits, and then resubmit the data the following month.
The ultimate goal is to enable each county to maintain its GIS database in its native structure while implementing a regional GIS dataset in compliance with the NENA NG911 standard. The standardized regional dataset is constructed directly from the native data structures, with no disruption to their routine database maintenance procedures. Individual counties negotiate geometric edge-matching and resolve road name and address range inconsistencies with neighboring counties. The objective is to reduce regional GIS data errors reported in successive monthly submittals.
The ETL and QA/QC scripts can easily be modified to accommodate changes in source data structures or changes in the draft NENA standard, as well as expanded to incorporate GIS data contributed by other counties.
On a monthly schedule, counties upload their GIS data to a shared ArcGIS Online (AGOL) group accessible by every SEPATF county. An Amazon Web Services (AWS) cloud server runs the Python ETL process on the data; performs QA/QC batch tests with ArcGIS Data Reviewer; and publishes an AGOL feature service, web map, and NENA-compliant GIS database for easy online visualization with an AGOL web viewer. After the server runs its processing, counties are notified that new data and error log is available.
The process not only produces a regional GIS dataset structured according to the draft NENA standard, but also highlights data quality issues that should be improved. County GIS editors can visualize where errors occur in the dataset and also view error statistics about each monthly run (number of errors, types of errors, number of errors per county, etc.). This collaborative environment has already helped reduce GIS data errors.
The project offers a promising case study for leveraging ArcGIS Online, AWS, ArcGIS Data Reviewer, and the NENA draft standard for road centerline data to produce regional road centerline datasets conforming to NG911 requirements.
Andrew Smart, GISP, is a senior GIS analyst for geographIT, a division of EBA Engineering, Inc. He can be reached at 717.399.7007 or at email@example.com.