Key Takeaways:
- In legacy 911, routing and caller location were two separate flat-file lookups stitched together by phone number, and either could fail independently. NG911 GIS mapping changes that: the map itself becomes the routing engine, with the ECRF running a geospatial routing query against the authoritative GIS layer to find the right PSAP and the LVF validating location data before a call ever happens.
- GIS coordinators are now adjacent to call delivery. A centerline edited Tuesday can carry live emergency traffic by Wednesday. Most counties’ GIS was never built to be a routing layer, which is why INDIGITAL runs MSAG and GIS mapping in parallel until NG911 GIS quality is provably equal or better.
- INDIGITAL’s DIG validates incoming GIS data at the source, and LIOS monitors data already in service and produces the documented evidence Phase 2 approvals require. When the FCC’s next round of Phase 2 requests moves through carrier review, provably accurate NG911 GIS mapping gets approved on first submission; assumed-accurate data gets bounced.
Back in the summer of 1940, as German bombers crossed the Channel toward British cities, the prevailing approach to air defense was reactive. Observers spotted formations overhead, the alarm went up, and squadrons scrambled to chase them. Air Chief Marshal Hugh Dowding believed that was already too late. He built a different system. Radar returns and Observer Corps reports flowed into Fighter Command’s Filter Room, where WAAFs moved wooden blocks across a gridded map of Britain in real time. Group and Sector commanders read that table and decided which squadrons to scramble.
The pattern was clear as day. Where the block sat on the map determined which squadron flew, at what altitude, toward which town. In a way, Dowding’s plotting table acted as the operational layer behind the air defense of Britain. And you could say that we’re now arriving at the same pivotal point in modern emergency response.
In a legacy system, maps were useful for situational awareness, but the routing decision happened in a database lookup against a flat-file table called the Selective Routing Database (SRDB) based on the Master Street Address Guide (MSAG). The map showed you the territory while the table delivered the call.
In a next-generation 911 (NG911) system built to NENA i3, that separation no longer exists. The map is what does the routing. Every polygon, every road centerline, and every address point becomes load-bearing: the difference between a call reaching the right Public Safety Answering Point (PSAP) and a call reaching the wrong one. Like a misplaced block on Dowding’s table, all it takes for a misroute is just one bad polygon.
GIS mapping is what defines the second half of the NG911 transition. If Phase 1 is whether the carrier can deliver SIP, then Phase 2 is whether your map can carry the call.
NG911 GIS Mapping: From Flat-File Lookup to Geospatial Query
In a legacy system, a 911 call enters the network and the selective router queries the SRDB for the calling phone number, matches that calling phone number to an Emergency Service Number (ESN), and sends the call to the corresponding PSAP. Once the call lands, the PSAP performs an ALI dip to return the subscriber’s name, address, and class of service. Routing and location are two separate lookups against two separate flat-file tables, stitched together by the phone number. If either is wrong, the call goes to the wrong PSAP, or the right PSAP gets the wrong address. And the tables are wrong more often than anyone is comfortable admitting.
In an i3 system, the routing decision is a geospatial query. A call arrives with a location object: a coordinate pair, address, or civic location in PIDF-LO format. The Emergency Call Routing Function (ECRF) consults the authoritative GIS layer, finds the polygon where the location falls, and returns the URI of the PSAP that serves it. The Location Validation Function (LVF) is the pre-call counterpart: it tells the originating carrier, before the emergency, whether the location it has on file would resolve correctly. Together, ECRF and LVF turn GIS data into the routing engine.
Now, this is where it gets hairy. GIS coordinators who were once peripheral to call delivery are now adjacent to it. A road centerline edited on a Tuesday afternoon could carry live emergency traffic by the following morning. While most counties have GIS, even excellent GIS, almost none have GIS that was built to be the routing layer for emergency services. Getting from current state to end-state NG911 means reconciling parcel data across counties, harmonizing road centerlines that disagree at jurisdiction boundaries, validating GIS data against MSAG until the two converge, and keeping the result current as new construction lands.
INDIGITAL’s deployments run a parallel MSAG-and-GIS period: the system supports both routing methods in production until GIS quality is demonstrably equal to or better than the legacy table. That is the responsible discipline when transitioning to NG911 GIS mapping.
From Production to Provable: The Data-Quality Layer
Running ECRF and LVF in production answers whether the routing engine works. It does not answer the question every 911 Authority gets asked the moment carriers start submitting Phase 2 requests: how do we know the GIS data feeding the engine is good enough?
That question is what INDIGITAL’s two data-quality platforms exist to answer:
The Data Integrity Gateway (DIG) is the front door for GIS data. Counties and addressing authorities submit their layers through DIG, which validates them against the geometric and attributional rules NG911 routing requires, such as polygon topology, address-range continuity, road-segment connectivity, and jurisdictional-boundary alignment. Errors are returned with enough specificity to fix at the source rather than band-aid downstream.
The Location Integrity Oversight Service (LIOS) is the operational counterpart. Where DIG governs ingestion, LIOS monitors the quality of location data actively in service, surfacing misalignment between the GIS layer and live address activity, and producing the documented evidence that 911 Authorities, GIS contributors, and OSPs all need when a Phase 2 request is on the table. That evidence is what turns “we believe our data is accurate” into “here is the validation history, the discrepancy log, and the resolution record.” The difference is the difference between a Phase 2 submission that gets approved on first review and one that bounces back for additional documentation.
For 911 Authorities, that pairing produces a defensible audit trail. For GIS contributors, it closes the feedback loop on what specifically needs to change. For OSPs, it is the validation handshake a Phase 2 request actually requires.
Two Governance Models, the Same GIS Discipline
Vermont has been on the INDIGITAL ESInet since 2015 with statewide direct service across a population of approximately 650,000, with ECRF and LVF live in production and active carrier integration testing with Sinch, Verizon, T-Mobile, and AT&T currently underway. The state’s GIS stewardship is centralized through the Vermont Center for Geographic Information, which keeps the data path from authoritative source to production routing engine short and well-documented.
Florida works at the opposite end of the governance spectrum. Rather than a single statewide architecture, individual PSAPs and county 911 authorities procure their own NGCS. INDIGITAL provides Next Generation Core Services to 40 of Florida’s 67 counties (with production ECRF/LVF shared across multiple ESInets). The Florida footprint processed 769,374 calls in Q4 2025 alone, spanning deployments at every scale: from Hillsborough County’s nine primary PSAPs and 141 call handling positions to Duval County, where geospatial routing went live in December 2025 and served 182,907 calls that quarter. Five counties (Alachua, Duval, Pasco, Polk, and St. Johns) serve as designated default PSAPs, anchoring the network’s resilience architecture across the state.
Both governance models work. The GIS discipline is the same in both.
5 Questions Every 911 Authority Should Ask a Vendor About GIS Routing
- Are your ECRF and LVF deployed in production today, and where?
- What is your conformance evidence against NENA i3 sections on geospatial call routing?
- How do you handle GIS data updates from multiple counties, and what is the change-control process between submission and going live?
- What happens when the GIS lookup fails? Is there a fallback path, and how is it tested?
- Can you run MSAG and GIS routing in parallel during cutover, and for how long?
When the FCC’s next round of Phase 2 requests starts moving through carrier review, the agencies whose GIS is provably accurate will get approvals on first submission. The agencies whose GIS is only assumed-accurate will get bounced. The difference is measured in whether the GIS pipeline runs through validation and oversight tooling that produces evidence, or through a process that produces only assertions.
Build for the former.
Follow along via The 911 Wire for the rest of the series.
Frequently Asked Questions (FAQ)
NG911 GIS mapping is the geospatial data layer that routes 911 calls in a next-generation 911 system built to NENA i3 standards. Instead of relying on legacy flat-file lookups like the Selective Routing Database (SRDB) and Master Street Address Guide (MSAG), the map itself becomes the routing engine. Every polygon, road centerline, and address point determines whether a call reaches the correct Public Safety Answering Point (PSAP).
In an i3 system, a 911 call arrives with a location object — a coordinate pair, address, or civic location in PIDF-LO format. The Emergency Call Routing Function (ECRF) consults the authoritative GIS layer, finds the polygon where the location falls, and returns the URI of the PSAP that serves it. The Location Validation Function (LVF) is the pre-call counterpart, telling the originating carrier whether a stored location would resolve correctly before an emergency happens.
When carriers submit Phase 2 requests, 911 Authorities must demonstrate that their GIS data is provably accurate, not just assumed to be accurate. Phase 2 approvals require documented evidence of GIS validation, including discrepancy logs, resolution records, and conformance against NENA i3 routing rules. Agencies with provably accurate NG911 GIS mapping get approved on first submission; those relying on assertions alone get bounced for additional documentation.
ECRF (Emergency Call Routing Function) and LVF (Location Validation Function) are the two i3 functional elements that turn GIS data into a live routing engine. ECRF handles real-time call routing by matching a caller’s location to the correct PSAP polygon. LVF validates location data before a call is placed, giving originating carriers confidence that addresses on file will resolve correctly when an emergency occurs.
