Next Generation 9-1-1 replaces the selective router and the MSAG with two functions defined in the NENA i3 standard, and both of them run on your GIS data.
The first is the Location Validation Function, or LVF. Before a call is ever placed, the LVF checks whether a civic location is valid against the provisioned GIS data. Is there a road segment by that name? Does that address number fall within a valid range on that segment? Is the address inside a known service boundary? If the GIS says no, the address isn’t valid, and the carrier has a problem to fix before the phone can be provisioned properly.
The second is the Emergency Call Routing Function, or ECRF. When a call is placed, the ECRF takes the caller’s location, either a civic address or a latitude and longitude, and asks the GIS one question: which service boundary polygon contains this point? The answer is the answering point that gets the call.
That’s the whole change, and it’s enormous.
The map is no longer a picture of the routing system.
The map is the routing system.
What Specific Errors Now Do
This is the part that rarely gets explained plainly, so here’s the translation from GIS problem to 9-1-1 consequence.
A gap between two PSAP boundary polygons. In the old system, an address in that sliver still had an MSAG entry and routed fine. In the new system, a caller standing in the gap is inside no polygon. The ECRF has no answer. The call falls to a default route, which is typically a regional or statewide fallback, adding transfer time at the exact moment when transfer time matters most.
An overlap between two boundary polygons. The point is inside two polygons at once. Which answering point wins depends on how the ECRF is configured to break ties, which means the call may go to the wrong center with no one aware that a tie was ever broken.
A road centerline with the wrong address range. A house numbered 4520 sits on a segment whose range in the data reads 4400 to 4498. The LVF rejects the address as invalid. Or, if the caller’s device reports coordinates instead, the ECRF routes correctly, but the call taker’s screen shows an address that doesn’t match the map, and the dispatcher loses seconds resolving the conflict.
A street name spelled two ways. “N Main St” in one dataset and “North Main Street” in another. The old MSAG tolerated this with alias tables. The LVF doesn’t tolerate it at all. Every variant that isn’t explicitly governed becomes an address that fails validation.
A boundary that’s right on the map and wrong in the attributes. The polygon is drawn correctly, but its identifier doesn’t match the answering point’s identifier in the routing configuration. The geometry is perfect. The call still goes nowhere useful.
None of these are exotic. Every one of them exists today in most county datasets because, until now, many of these issues were largely cosmetic.
On cutover day, they become operational.
Cleaning the Data Once Isn’t Enough
The instinct, when an agency first understands this, is to commission a data cleanup: run a validation report, fix the errors, submit the corrected dataset, and declare readiness.
That’s necessary, but it isn’t sufficient, for one reason.
The data doesn’t hold still.
Every new subdivision adds road segments. Every annexation moves a boundary. Every renamed street creates a variant. Every edit made by a county, a city, or a tribal community inside a shared region is a new opportunity for a gap, an overlap, or a range error.
A dataset that was clean at submission starts to drift the moment the next edit lands, and the ECRF doesn’t know the difference between a dataset that was validated last quarter and one that was validated this morning. It only knows what the polygons say right now.
This is why the conversation in NG9-1-1 GIS is shifting from validation as an event to validation as a property of the workflow.
The question is no longer, “Did we validate the data?”
It’s, “Can an error get into the data at all?”
What to Ask Before Your Cutover Date
If your state or region has announced a geospatial routing timeline, here are the questions worth putting to your GIS and 9-1-1 leadership now, while there’s still time to act on the answers.
- Do our PSAP and emergency service boundaries close without gaps or overlaps, and how do we know that today rather than as of the last audit?
- Does every road centerline segment carry a valid, non-overlapping address range?
- Do we govern street-name variants, or do we discover them when something fails?
- When a neighboring jurisdiction edits a shared boundary, how does our data find out?
- When an error is introduced, how long does it live before someone sees it?
If the honest answer to the last question is “until the next report,” that’s the gap to close first.
A Note on Where We Sit
At Gistic Research, we build GIVE, a browser-based platform for maintaining NG9-1-1 GIS data, and our answer to that last question is built into the product: every edit is validated as it’s made, so qualifying gaps, overlaps, and range errors can be repaired in the editing session rather than discovered later in a report.
I mention that not as a pitch, but as context for the perspective in this article.
Whatever tool your agency uses, the principle is the same.
In Next Generation 9-1-1, the map routes the call.
The only question is whether your map is ready to.
Brian Brady is COO and VP of Business Development at Gistic Research, Inc., which has built collaborative GIS and data-quality systems for public agencies since 2005. He writes regularly about NG9-1-1 GIS data standards and practice on LinkedIn.