Key takeaways
- Routing runs on a short list. A 911 call that arrives with a coordinate reaches the right PSAP (public safety answering point) on the PSAP boundary. A call that arrives with only a street address also needs address points or road centerlines to place it. That's the routing-critical set.
- Minimum means stricter, not looser. The layers that route calls have to be close to perfect: no gaps, no overlaps, edges that match the neighbors. Build layers in order of what routing requires, and hold each to the precision it needs.
- Everything else gets a date, not a pass. Emergency service boundaries (ESBs), the remaining data model layers and every non-conformance that doesn't affect routing still matter. ESBs are required for an i3 call handling system (CHE) to display a standards-conformant i3 call. Minimum viable data puts them in order; it doesn't drop them.
A cell phone dials 911. The call arrives at the NG911 core with a latitude and a longitude. Before anyone answers, the emergency call routing function (ECRF) asks one question of the GIS data: which PSAP boundary does this point fall inside? It gets an answer, and the call goes there.
That's the whole routing decision for that call. It didn't check whether the nearest address point sits on the right side of the street, or whether the road centerline's address ranges flow in the right direction. It checked one polygon.
Wireless calls are most of the traffic. States reported about 218 million voice 911 calls to the FCC for 2022, and almost 73% of them came from wireless phones (FCC, 15th Annual 911 Fee Report).
Yet a lot of NG911 GIS programs are run as if every layer and every check has to be finished before cutover, all at the same target and on the same timeline. Product teams have a name for the opposite approach: the minimum viable product, the smallest version that does the job correctly, shipped first. NG911 needs the same idea for its data.
What minimum viable data means, and what it doesn't
Minimum viable data is the smallest set of GIS data that routes every call to the right PSAP, held to the highest standard, and finished first.
In 911, "viable" means the call reaches the right center every time, not most of the time. So this isn't permission to lower the bar. It's a way to put the highest bar on the data and data elements that route calls, and to put a dated schedule on everything else.
That distinction matters because the alternative isn't a higher standard. It's a single standard applied to everything at once, which usually means the layers that route calls wait in line behind work that doesn't.
How NGCS actually routes a call
Your GIS data reaches the routing system through the Spatial Interface (SI), which NENA describes as the "last stop" before authoritative GIS data is placed into service (NENA-STA-005.1.2, section 6.1). From there it's provisioned into two functional elements that matter most for this series:
- The ECRF (emergency call routing function) takes the caller's location and returns where the call should go.
- The LVF (location validation function) checks civic addresses before a call is ever made, when a carrier or MLTS operator loads them into a location database or location information server (LIS).
Locations arrive in two forms, and they lean on different data.
A coordinate, which most wireless calls carry, only needs the PSAP boundary. The ECRF finds the polygon the point falls in.
A civic address, which wireline, many VoIP and MLTS (multi-line telephone system) calls carry, has to be placed before it can be routed. That's where address points and road centerlines come in. When an address doesn't match a provisioned address point but falls inside a road centerline's address range, the i3 standard lets the ECRF and LVF match on the centerline and flag it as a degraded match (NENA-STA-010.3, section 3.4.10.2).
When the data can't place a call at all, the system falls back to policy and default routing. That still gets the call somewhere. It's the outcome good data is meant to prevent, because a default route can mean a transfer, and a transfer means seconds lost.
The routing-critical set
The NENA GIS Data Model lists which layers each functional element requires (NENA-STA-006.3-2026, Table 4-1). Read it with one question in mind, which data decides the PSAP, and the list gets short.
PSAP boundary. Required by the ECRF, LVF and MDS. It decides which center gets the call, so it has to be near-perfect on day one.
Road centerlines. Required by the ECRF, LVF, GCS, MCS and MDS. They place civic-address calls and are the fallback match when an address point is missing. Day one, wherever civic calls arrive.
Site/structure address points. Required by the ECRF, LVF, GCS, MCS and MDS. They place civic-address calls at the structure. Day one, wherever civic calls arrive.
Law, fire and EMS boundaries. Required by the ECRF and MDS. They determine which responders are sent, not which PSAP answers. They need to be right before go-live; Part 5 covers them.
Everything else (A1 to A5 administrative boundaries, hydrology, rail, markers). MDS only. Map display and context, on a dated schedule after cutover.
GCS is the geocode service, MCS the MSAG conversion service, and MDS the mapping data service. The provisioning boundary isn't on this list because no functional element routes on it; NENA-STA-006.3 describes it as a GIS data management layer. It still matters: it defines whose data covers which area, and points that fall outside it get flagged.
The tiering is by function, not importance. Emergency service boundaries matter enormously, and the standard requires them in the ECRF. They answer a different question than which PSAP picks up, and Part 5 in the series covers them on their own.
Why minimum has to mean stricter
A PSAP boundary that's 99% right still misroutes the calls in the other 1%. So the routing-critical layers get the tightest tests, and NENA's own list of what should happen before data leaves the SI reads like a routing checklist: coordinates in WGS 84, gap and overlap errors resolved to the threshold the ECRF and LVF set, service boundaries edge-matched with neighboring jurisdictions, and consistency with the GIS data model (NENA-STA-005.1.2, section 6.1).
The places that go wrong are predictable: jurisdiction edges, annexations, new subdivisions, county lines and water. Those are where the effort goes first, and where neighboring PSAPs have to agree on where the line actually sits.
Here's the other side of it. A good GIS steward runs a fishbone check, which draws a line from each address point to the road centerline segment it matches, and finds points on the wrong side of the street. The instinct to fix them is a good one. But if a point is still inside the correct PSAP boundary, the ECRF routes the call to the same place, and the LVF validates the record the same way. Neither one would notice.
If you're still in transition, I'd check conformance between your ALI data and the legacy elements in your address points and road centerlines, such as ESN, MSAG community name and legacy street name, before running a fishbone check. Those fields are what keep GIS, MSAG and ALI in step while calls still route the legacy way (NENA-INF-034, GIS MSAG ALI Synchronization).
Worth fixing, just not first. Part 4 in the series is about exactly that: how to sort a list of non-conformances by what each one does to a call.
Everything else gets a date
Minimum viable data only works with a written schedule for the rest: which layer or error type, what target, by when, and who owns it. Without that schedule, "minimum" quietly becomes "final," and that's the failure to name honestly up front.
It also changes how a cutover plan reads:
- Readiness is measured on the routing-critical set, not an average across every layer. "98% overall" can hide a PSAP boundary with gaps; "PSAP boundary clean, address data 94% and improving" can't.
- Go-live depends on correct routing, and the rest keeps improving in production, with the gaps documented rather than hidden.
- Remediation is ranked by what it does to a call. A list of 4,000 non-conformances and a list of 12 that affect routing are very different statements about readiness.
Questions to settle before you set a cutover date
For 911 authorities
- Which of our calls arrive with a coordinate, and which with only a civic address? That mix decides how much address data is routing-critical for us.
- Is our PSAP boundary free of gaps and overlaps, and has every neighboring PSAP agreed to the line?
- Are we measuring readiness on the routing-critical layers, or on an average across all of them?
- For every layer and error type outside the routing-critical set, do we have a target, a date and an owner in writing?
- What does our RFP say "GIS ready" means? If it doesn't define it, the vendor will.
For vendors
- Show which layers your routing service reads, and what happens to a civic address it can't place.
- Report readiness by layer and by function, not as one percentage.
- Put the post-cutover data schedule in the statement of work, so "minimum" doesn't become "final."
- Be ready to explain what happens to a call that lands in a boundary gap. Buyers who've read this will ask.
Bottom line
Not every GIS layer routes a call. The ones that do have to be right before anything else, and the ones that don't need a date, not a pass.
Minimum viable data isn't a lower standard. It's the right standard in the right order: the right layers first, and the highest bar where it routes.
Where does your data stand? Ground Truth GIS checks your road centerlines and address points, and optionally your MSAG and ALI, against NENA-STA-006.3. It labels each finding by what it affects, so you can see which ones touch routing first. It's free, and your files never leave your computer.
The rest of this series takes each piece in turn: the PSAP boundary next, then civic addresses, then how to triage the flags a tool like this one finds.
Frequently asked questions
What GIS data is required for NG911 call routing?
Under NENA-STA-006.3, the NG911 GIS Data Model, the emergency call routing function (ECRF) requires road centerlines, site/structure address points, the PSAP boundary, and law, fire and EMS boundaries. For getting a call to the right public safety answering point (PSAP), the PSAP boundary decides the answer. Road centerlines and address points matter when a call arrives with a civic address instead of a coordinate, such as most wireline and many VoIP calls. Law, fire and EMS boundaries determine which responders are sent. Other layers, like hydrology or administrative boundaries, support map display.
What is minimum viable data in NG911?
Minimum viable data is the smallest set of GIS data that routes every 911 call to the correct public safety answering point (PSAP), held to the strictest standard and completed first. It borrows from the minimum viable product idea in software. In practice it means a near-perfect PSAP boundary, plus enough road centerline and address point data to place civic-address calls. Everything else, like emergency service boundaries and map layers, gets a written schedule with a target, a date and an owner. It's a sequence, not a lower bar.
Does every GIS error affect 911 call routing?
No. Many non-conformances that GIS validation tools flag don't change where a 911 call goes. For example, a fishbone check may show an address point on the wrong side of the street from its road centerline. If that point is still inside the correct PSAP boundary, the emergency call routing function (ECRF) sends the call to the same place, and the location validation function (LVF) validates it the same way. Those errors are worth fixing, but after the ones that affect routing, such as gaps or overlaps in the PSAP boundary.
What is the difference between a PSAP boundary and an emergency service boundary?
A PSAP boundary defines the area each public safety answering point (PSAP), or 911 center, serves. It decides which center answers a call. An emergency service boundary (ESB) defines the area each responding agency covers, such as a police department, fire district or EMS provider. It decides which responders are sent. NENA-STA-006.3 requires both in the emergency call routing function (ECRF), but they answer different questions. A call can reach the right PSAP with a flawed fire boundary, and still have the wrong engine company recommended.
What happens when NG911 can't match a caller's address?
If a civic address doesn't match an address point but falls inside a road centerline's address range, the i3 standard lets the emergency call routing function (ECRF) match on the centerline and return a degraded-match warning. If it can't be placed at all, the system falls back on routing policy and a default route set by the 911 authority. The call still goes somewhere, but possibly to a center that then has to transfer it, which costs time. That's why the data that places civic addresses is routing-critical wherever those calls arrive.