Key takeaways
- The PSAP boundary is the layer you can finish first and use first. A call that arrives with a coordinate needs only that boundary to reach the right PSAP (public safety answering point). Build it, edge-match it, and you can route most of your 911 calls on it.
- Address data gets cleaned up in production, not before it. While the boundary routes coordinate calls, civic-address calls stay on the routing they use today. They move to i3 routing once address points and road centerlines can place them.
- Routing-ready means no gaps, no overlaps and agreed edges. A boundary that's 99% right still misroutes the calls in the other 1%.
Almost 73% of the voice 911 calls states reported for 2022 came from wireless phones (FCC, 15th Annual 911 Fee Report). Most of those calls can arrive with a latitude and longitude (or x/y). To route a call like that, the emergency call routing function (ECRF) asks one question of your GIS data: which PSAP boundary is this point inside?
That's most of your call volume, routed on one layer.
In Part 1, I made the case for building GIS layers in order of what's required, and how precise each has to be, to route every 911 call to the right PSAP. This part takes the first step in that order. The PSAP boundary is the layer to finish first, and not only because it has to be near-perfect. It's the one feature you can build, deploy and start routing calls on while the rest of your data is still being cleaned up.
There's a second reason, and it isn't often discussed. For fixed-device 911 calls, the ones that arrive with a civic address, the address points and road centerline segments have to live in or on the right PSAP boundary. When the ECRF matches that address, the call goes to the PSAP whose boundary the matched feature sits in. So you can't confirm your address data is in the right place until the line it's measured against is settled.
Why the boundary comes first
A call that arrives with a coordinate doesn't need an address point or a road centerline to route. The ECRF finds the polygon the point falls in and returns the PSAP that serves it. That's the whole decision.
So a clean, edge-matched PSAP boundary is something you can build, provision through the Spatial Interface (SI) and route on before the rest of your data is ready. The order looks like this:
- Build the boundary and route on it. Finish the PSAP boundary, agree on every edge with your neighbors, and route coordinate calls through NGCS. That's the majority of your 911 calls.
- Clean up address data in production. While the boundary carries most of your traffic, work through the address points and road centerlines that place civic-address calls, so they sit in or on the right PSAP boundary and conform to the standard structure and payload.
- Finish routing every call. Once address data can be validated against the GIS data and places fixed-device calls in the right boundary, move civic-address calls onto i3 routing too.
The payoff is time. You get the benefit of NGCS routing for most of your calls months earlier, instead of holding everything until the last address point is fixed.
The alternative is the plan Part 1 warned about: every layer built to the same target, on the same timeline, before anything goes live, with no order by what routing requires. The boundary waits in line behind address work it doesn't depend on, and so do the calls it could already be routing.
Where civic-address calls go in the meantime
A phased start doesn't leave civic-address calls without a route. Wireline, many VoIP and MLTS (multi-line telephone system) calls keep routing the way they do today, on one of two paths:
- Traditional ALI/MSAG routing. The call routes the legacy way, on the emergency service number (ESN) tied to the caller's ALI (automatic location identification) record, with the address validated against the MSAG (master street address guide).
- Transitional LDB routing. The caller's LVF-valid civic location comes from a location database (LDB) as a PIDF-LO (Presence Information Data Format Location Object) during the transition to i3, rather than from the legacy ALI system.
The difference is where the location comes from and what it's checked against. Both keep civic-address calls routing correctly while your address points and road centerlines catch up. A later post in this series breaks each one down, including what your GIS data has to stay in step with on each path.
What routing-ready means for a PSAP boundary
If most of your calls are going to route on one layer, that layer carries the highest bar. NENA's list of what should happen before data leaves the SI is a good test of it (NENA-STA-005.1.2, section 6.1):
- No gaps and no overlaps, resolved to the threshold the ECRF and LVF set.
- Edge-matched with every neighbor, so your line and theirs are the same line.
- Coordinates in WGS 84 and consistent with the NG911 GIS Data Model.
A call that lands in a gap or an overlap still goes somewhere. When the ECRF can't return one clear answer, the system falls back on routing policy and a default route the 911 authority sets. That's the outcome a clean boundary is meant to prevent, because a default route can mean a transfer, and a transfer costs seconds.
Where boundaries go wrong
The trouble spots are predictable: jurisdiction edges, annexations, new subdivisions, county lines and water. Most of them sit where two agencies meet, which is why a boundary can't be finished alone.
Routing-ready means both sides agree where the line sits. That takes the neighboring PSAPs and whoever maintains the source boundaries, usually in the same conversation. If your boundary and your neighbor's were drawn from different sources, expect them to disagree at the edges until someone reconciles them.
When the road is the boundary
Many PSAP boundaries run down the middle of a road. For coordinate calls that's simple: a point falls on one side of the line or the other (assuming the parity fields are correct).
For civic-address calls, each PSAP needs data provisioned that only routes to its own PSAP. If the even side of the road belongs to PSAP A and the odd side to PSAP B, PSAP A's road centerline carries only the even side, and PSAP B's only the odd. In practice that's typically a stacked road centerline, or a road centerline from each entity, falling within each PSAP boundary.
That's what lets an address on either side of a boundary road match to the right PSAP, and it's where Part 3 picks up.
A note on law, fire and EMS boundaries
The PSAP boundary decides who answers. Law, fire and EMS boundaries, the emergency service boundaries (ESBs), decide which responders serve the caller's location, and an i3 call handling system (CHE) needs them to display a standards-conformant i3 call. They aren't on the first-to-do list because they don't route the call. That information isn't sent with the initial 911 call; the PSAP queries the ECRF for it after the call has arrived.
That often means a 911 authority builds or rebuilds those boundaries alongside a CHE upgrade. Before you sign the purchase, find out what the vendor's system needs from your data: which boundary layers, which attributes, in what format, and how updates get delivered. Put those requirements in the purchase and the upgrade plan, so the boundaries are ready when the new CHE is. Part 5 covers ESBs in full.
Questions to settle before you plan cutover
For 911 authorities
- Does our cutover plan let coordinate calls route on the PSAP boundary before the address data is finished?
- Which path do our civic-address calls take today, ALI/MSAG or LDB, and on what date do they move to i3 routing?
- Has every neighboring PSAP agreed to our boundary, in writing?
- If a CHE upgrade is coming, do we know what law, fire and EMS boundary data the vendor needs, and is it in the purchase?
For GIS stewards
- Finish and edge-match the PSAP boundary first.
- Report its status separately from address point and road centerline remediation, so a clean boundary isn't hidden in an average.
- Check that address points and road centerline segments live in or on the right PSAP boundary, since that's where fixed-device calls will route.
- Where a road is the boundary, check that each side's road centerline is provisioned to its own PSAP.
For vendors
- Show how your routing service handles a phased start: coordinate calls first, civic-address calls later.
- Be ready to explain what happens to a call that lands in a boundary gap or overlap.
- Spell out, before the sale, what law, fire and EMS boundary data your CHE needs, in what format, and how it gets updated.
Bottom line
The PSAP boundary is the layer you can finish first and get the most out of first. Build it, route on it, and clean up the rest while most of your calls are already going where they should.
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, and labels each finding by what it affects. It's free, and your files never leave your computer.
Next in the series, Part 3: when an address has to become a point.
Frequently asked questions
Why should the PSAP boundary be the first NG911 GIS layer to finish?
The PSAP boundary is the only layer a 911 call with a coordinate needs to reach the right public safety answering point (PSAP). Most wireless calls arrive with a coordinate, and wireless calls were almost 73% of voice 911 calls in 2022. A clean, edge-matched PSAP boundary can be built, deployed and used to route most 911 calls through NGCS while address points and road centerlines are still being cleaned up. It's also the line those address points and road segments have to sit inside for fixed-device calls to route correctly.
Can an agency route some 911 calls through NGCS before its address data is ready?
Yes. Calls that arrive with a coordinate can route on the PSAP boundary through the emergency call routing function (ECRF). Calls that arrive with only a civic address, such as wireline, many VoIP and MLTS calls, keep routing on traditional ALI/MSAG routing or transitional LDB routing until the address points and road centerlines can place them. Then they move to i3 routing.
What does a routing-ready PSAP boundary look like?
A routing-ready PSAP boundary has no gaps and no overlaps beyond the threshold the ECRF and LVF set, is edge-matched with every neighboring PSAP, uses WGS 84 coordinates and conforms to the NG911 GIS Data Model (NENA-STA-005.1.2, section 6.1). Neighboring PSAPs should agree, in writing, on where the shared line sits.
What happens to a 911 call that lands in a gap or overlap in the PSAP boundary?
When the ECRF can't return one clear PSAP, the system falls back on routing policy and a default route set by the 911 authority. The call still goes somewhere, but it may reach a center that has to transfer it, which costs time.
How is a road that forms a PSAP boundary handled in NG911 GIS data?
Each PSAP needs data provisioned that routes only to itself. If the even side of the road belongs to PSAP A and the odd side to PSAP B, PSAP A's road centerline carries only the even side and PSAP B's only the odd. This is typically done with a stacked road centerline, or a road centerline from each entity, within each PSAP boundary.