UGRC - Utah's NG911 GIS Roadmap

As the State of Utah moves closer to NG911, GIS data providers will soon be required to adhere to national standards set forth by the NENA, opens in a new tab and the UCA 911 Division, opens in a new tab (section 6 of ref 1). It can be daunting navigating these standards and best practice documents, so the intent of this article is to demystify the relevant information and lay out a road map of where we are going.

This post is focused on GIS as it relates to NG911 Core Services and the SI. These are the services needed to process a call on the ESINet (ref 9). For GIS, this equates to address validation and 911 call routing. Essentially, these are the operations that take place before the call is received at the appropriate PSAP. As a result, NENA has established standards to ensure that these operations can be carried out flawlessly. Failing to comply with these standards could ultimately result in misrouted 911 calls (section 2.2 of ref 5 and section 2 of ref 4).

Currently with E-911, the ALI MSAG, and selective router are responsible for these functions. However, in a true NG911 environment, the GIS is the backbone to address validation and call routing, eventually replacing the MSAG, ALI, and selective router (section 4.8 of ref 1, section 2.1 of ref 5, and section 2.1 of ref 3). Within NG911 Core Services, the LVF will pre-validate addresses and the ECRF will route calls to the appropriate PSAP based on a point-in-polygon query with either the pre-validated address (for landlines) or the cellular devices’ x,y coordinates (section 4.7 and 4.8 of ref 1, section 3 of ref 5, section 2 of ref 4, and section 2.1 of ref 3).

Now if you’re not familiar with this topic, all these acronyms might sound like mumbo jumbo, and if that’s the case, don’t worry (and also, take a look at the Recommended Reading and References section below). We’ll make it easy for you! The big takeaway is this: accuracy and consistency of GIS data in NG911 systems are extremely critical.

Standards and Best Practices

Required Datasets

Service area boundaries
- PSAP boundaries
- Emergency service boundaries (e.g., law, fire, and EMS)
- Provisioning boundaries (i.e., boundaries that define the extent of the data provider’s responsibility)
Civic location data
- Site/structure address points
- Road centerlines
For further reading see section 3 of ref 3 and section 4.2 of ref 5.

Data Requirements

Prior to NG911 implementation, civic location data must be matched and reconciled against the MSAG and ALI.
- The GIS data should contain all valid ALI/MSAG records (section 2.2.1 of ref 4; ref 8).
The required GIS datasets must adhere to NENA NG911 Data Model specifications, including: projection, field names, data types, domains, etc. (ref 3).
Emergency service boundaries (e.g., law, fire, and EMS) must be checked for unintended gaps or overlaps.
- Gaps or overlaps could result in incorrect 911 call routing (section 4.7 of ref 5).
Site/structure address point and road centerline address components should be consistent.
- Validate and check for unintended discrepancies (section 3.2 of ref 3 and section 4.7 of ref 5).
Road centerlines should not contain segments with identical attributes and different geometries (section 4.7 of ref 5).
Road centerlines should not contain overlapping address ranges (section 5.4.3 of ref 5).
Site/structure address points should not contain duplicate records (section 5.4.3 of ref 5).

For further reading see (reference 3, 4, 5, 7, 8, 9, 10)

Who’s Responsible for What? (see graphic below)

UCA 911 Division in conjunction with UGRC will:

Provide Utah’s statewide NG911 GIS database;
Aggregate and validate 911 data (perform QA/QC before providing data to the State’s NG911 Core Services service provider);
Ensure that required GIS datasets adhere to NENA NG911 Data Model specifications;
- UGRC will look for discrepancies and inconsistencies in the aggregated statewide NG911 GIS Database and report discrepancies back to the data providers section 5.4.3 of ref 5); and
Be the authoritative source for PSAP boundaries utilized by NG911 Core Services (ECRF/LVF) (section 3.5 of ref 3).

For further reading see section 4.7 of ref 1, sections 4.1 and 5.2.4 of ref 5, section 3 of ref 3, and section 2.2.3 of ref 10:

Authoritative Data Providers will:

Coordinate and collaborate with the UCA 911 Division, UGRC, and neighboring agencies (PSAPs);
Create, maintain, and provide required GIS datasets (within their provisioning boundary) for NG911 Core Services (ECRF/LVF):
- Service area boundaries, and
- Civic location data;
Ensure that the required GIS datasets adhere to current NENA standards:
- Civic location data
  - Maintain consistency between site/structure address points and road centerlines
- Emergency service boundaries (e.g., law, fire, and EMS)
  - Ensure that there are no unintended gaps or overlaps; and
Perform regular QA/QC on required datasets.

For further reading see section 4.7 of ref 1, section 5.2.1 of ref 5, and section 2.2.3 of ref 4:

NG911 GIS Roadmap

`Near-Term`

Data validation and cleanup are the next, most logical steps for GIS readiness. These are often considered the first steps in NG911 transition. At the moment, UGRC is focused on facilitating two specific data validation checks, both mentioned in the previous Data Requirements section of this page:

ALI/MSAG and GIS

The UCA 911 Division is in the process of obtaining statewide ALI and MSAG data for the purpose of GIS data synchronizing. UGRC will geocode the ALI database against the GIS data to ensure that all valid addresses in the phone carrier’s database can be located/validated in the GIS data (section 6 of ref 1). A similar process will need to happen with the MSAG data. All valid addresses in the ALI database must have a corresponding site/structure address point in the GIS data.
UGRC will then work with the data providers to resolve any valid discrepancies.

Address Component Cross-Check

NG911 Core Services state that site/structure address points and road centerlines must be consistent. In other words: unless intended, each site/structure address point should match an associated road centerline. This supports the requirement that a civic address be considered valid if it can be located within the database uniquely (section 4.8 of ref 1). Here are some common mismatch issues UGRC has found:
- Address components don’t match, including mismatching in the following address component fields: pre-direction, street name, post type, and post direction.
  - To resolve: Data providers must determine which dataset (i.e., site/structure address points or road centerlines) has the correct address component and then correct the issue.
- Site/structure address points cannot find corresponding road centerlines. Often this is because the road has the alias and primary names switched or the road segment has not been put into GIS yet.
  - To resolve: Data provider needs to determine the official primary street name and adjust dataset fields as needed.
- Road centerline address range does not accommodate the address point.
  - To resolve: Typically, the road centerline address ranges need to be adjusted.
UGRC will work with data providers to resolve any unintended discrepancies (see the What can you do now? section below).

`Mid-Term`

Identify and resolve any gaps and/or overlaps in the emergency service boundaries (e.g., law, fire, and EMS).
Resolve address range overlap in road centerlines.
Resolve duplicate records in site/structure address points.
Break/split all road centerline segments at PSAP and jurisdiction boundaries. This will ensure that road segments contain the proper spatial-boundary values.
- Fields corresponding to polygon boundaries will need to be updated as well.
Ensure the current PSAP boundaries are official and that each PSAP has signed off on them. It is essential that these boundaries are correct, as they will be used to route 911 calls.
- Identify and resolve any gaps and/or overlaps in the PSAP boundaries.
Establish a statewide, multi-user mechanism that supports near-live NG911 data editing in Utah. This would allow data providers (e.g., cities, counties, PSAPs, etc.) to quickly resolve conflicts and/or unintended discrepancies, allowing them to directly edit 911 GIS data (section 4.7 of ref 1).
Determine the authoritative data providers for data used in NG911 Core Services and create the provisioning boundaries (section 3.5 of ref 3).

`Long-Term`

Get all 911-related data providers the needed training and access to the statewide NG911 multi-user data editing platform/application.
Incorporate a workflow to review these edits (from the NG911 multi-user data editing platform) and push them into the official State of Utah NG911 database (on a daily basis).
Establish the NG911 multi-user data editing platform as Utah’s official NG911 data editor (section 5.1 of ref 5 and section 4.7 of ref 1).
Provision Utah’s statewide, NG911 GIS database so it can used locally by the PSAPs (for their record keeping and dispatch systems). This would eliminate data duplication and ultimately provide all 911 users with the best possible data. This concept is in line with the UCA 911 Division promotion of a consistent 911 service across the state (sections 5.3 and 6 of ref 1).

What Can You Do Now?

If you are a 911 GIS data provider, it’s in your best interest to begin validating and provisioning your data as soon as possible. In the coming months, UGRC will geocode the ALI database and begin working with the data providers to resolve missing addresses.

At the moment, the most effective thing you can do is to resolve unintended discrepancies between site/structure address points and road centerlines. To facilitate this effort, UGRC has created a custom process to perform these validation checks and then output the needed discrepancy reports for the 911 data providers. Get involved now by visiting the project’s homepage, opens in a new tab.

It’s also in your best interest to view the current draft version of Utah’s statewide NG911 GIS database. In particular, it is highly recommended that you validate your jurisdiction’s PSAP, fire, law, and/or EMS boundaries, ensuring that they are correctly represented. UGRC will continue to push monthly updates and modifications into this database in hope that 911 data providers will view the data and help us resolve unintended discrepancies.

Keep in mind:

NG911 implementation won’t happen overnight: there will be a hybrid GIS/MSAG (GeoMSAG) approach at first.
Provisioning data for NG911 Core Services (ECRF/LVF) is an ongoing process (section 1 of ref 5).
We should all be working together, toward the same end goal of public safety.

Be proactive and get involved now. For more information contact Greg Bunce from UGRC at GBunce@utah.gov | 801-349-0039.

Search our website