8.3 GIS Data Quality, Topology & Provisioning Workflows

8.3 GIS Data Quality, Topology & Provisioning Workflows

Quick Answer: The Spatial Interface (SI), defined in NENA-STA-010, is the standardized functional component that acts as the secure gateway between local authoritative GIS databases and Next Generation Core Services (NGCS). The SI ingests local spatial data, validates schema conformance and topology, transforms local coordinates into unprojected WGS84 (EPSG:4326), and provisions the verified datasets into two critical core engines: the Location Validation Function (LVF) (which validates subscriber civic addresses prior to call placement) and the Emergency Call Routing Function (ECRF) (which performs real-time point-in-polygon calculations during emergency call setup). Before relying on GIS for NG9-1-1 routing, NENA guidance (NENA 71-501) recommends at least a 98% match rate between authoritative GIS data and legacy MSAG/ALI databases. When routing anomalies, boundary edge mismatches, or unvalidated locations occur, they are remediated through the Discrepancy Reporting Web Service (DRS), ensuring a closed-loop resolution process between the core network and local GIS data stewards.

---

1. The GIS Data Maintenance Lifecycle: From Local Addressing to NGCS

In legacy E9-1-1, GIS layers were often updated irregularly—quarterly, semiannually, or annually—because CAD map displays were non-authoritative reference backdrops. In NG911, an unmapped road, missing address point, or unaligned boundary prevents a citizen's address from validating in the LVF and misroutes calls in the ECRF. Consequently, public safety authorities must establish a continuous, near real-time data maintenance lifecycle.

┌─────────────────────────────────────────────────────────────────────────────────┐
│                     NG911 GIS DATA PROVISIONING PIPELINE                        │
│                                                                                 │
│  [Local Authoritative GIS]        [Spatial Interface (SI)]        [NGCS Core]   │
│   - City/County Addressing         - Ingestion & ETL               - ECRF       │
│   - Local Projections      ──►     - Coordinate Transform (WGS84)─►- LVF        │
│   - Continuous Maintenance         - Schema Validation             - Map Service│
│                                    - Topology Quality Gates                     │
│                                              ▲                                  │
│                                              │                                  │
│  [Discrepancy Resolution] ◄──────────────────┴────── [DRS Web Service]          │
│   - Local GIS Data Steward                           - Automated Error Reports  │
│   - Closed-Loop Remediation                          - Unvalidated Location Flag│
└─────────────────────────────────────────────────────────────────────────────────┘

Authoritative Source Integration

Maintenance workflows must interface directly with local authoritative addressing authorities: city planning departments, county GIS divisions, tax assessors, and public works permitting offices. Whenever a new subdivision is platted, a commercial site dedicated, or a road named, the GIS data must be committed immediately into the operational workflow. NENA guidelines recommend that authoritative GIS data be updated and synchronized to the NG911 Spatial Interface on a daily or weekly cycle, with monthly provisioning representing an absolute upper ceiling.

---

2. The 98% GIS-to-MSAG/ALI Match Rate Recommendation

Before an emergency communications authority can decommission legacy selective routers and transition live 9-1-1 traffic to NG911 spatial routing (ECRF and LVF), NENA 71-501 recommends a quantitative benchmark, which many state NG9-1-1 programs adopt or tighten:

$\text{GIS-to-MSAG/ALI Match Rate} = \left( \frac{\text{Valid Active ALI Records Matching GIS}}{\text{Total Active ALI Database Records}} \right) \times 100 \ge 98.0\%$

           THE 98% GIS-TO-MSAG/ALI PRE-CUTOVER BENCHMARK

  [Authoritative 9-1-1 GIS Layers]      [Legacy Telecommunications Databases]
  - Road Centerlines (RCL)              - Master Street Address Guide (MSAG)
  - Address Points (SSAP)               - Automatic Location Identification (ALI)
              │                                       │
              └───────────────────┬───────────────────┘
                                  ▼
                 [AUTOMATED RECONCILIATION AUDIT]
                                  │
         ┌────────────────────────┴────────────────────────┐
         ▼                                                 ▼
   MATCH RATE >= 98%                                MATCH RATE < 98%
   - Authoritative GIS synchronized                 - Unresolved kickouts
   - Ready for NG911 ECRF/LVF cutover               - Cutover not recommended   
   - Exceptional cases identified (< 2%)            - Remediation required

The Three-Way Reconciliation Process

Achieving the 98% benchmark requires a comprehensive three-way synchronization audit between:

1. The GIS Road Centerlines & Address Points
2. The Legacy Master Street Address Guide (MSAG)
3. The Active Carrier ALI Database Records

Audit Workflow Steps:

1. GIS-to-MSAG Comparison: Every street name, directional prefix/suffix, community name, and address range in the MSAG is compared against the GIS road centerline layer. Any discrepancy in spelling (e.g., "First St" vs "1st St"), missing segments, or range gaps is flagged.
2. ALI-to-GIS Geocoding Audit: Every active telephone record in the legacy ALI database (wireline telephone numbers, fixed VoIP lines) is programmatically geocoded against the GIS layers. The record must either match a discrete Site/Structure Address Point (SSAP) or interpolate cleanly within a valid Road Centerline address range.
3. Resolving the Remaining 2%: NENA 71-501 recommends at least a 98% match before relying on the GIS data. The remaining 2% typically represents legitimate administrative exceptions: post office boxes mistakenly stored in billing records, rural route approximations, dormant unassigned lines, seasonal addresses, or recently annexed territories pending postal reconciliation.

---

3. Road Centerline Topology & Address Point Validation Checks

Data quality control requires strict topological rules to ensure that road networks and address points support automated dispatch and navigation:

Centerline Network Connectivity Rules

1. Node-to-Node Segmentation at Intersections: Road centerlines must be split into discrete line segments at every at-grade intersection. Two crossing or joining streets must share a common topological junction node. If lines cross without an intersection node, CAD routing algorithms cannot calculate a turn, rendering the network topologically disconnected.
2. Grade-Separated Crossings (Bridges and Tunnels): When a roadway passes over another roadway via an overpass or bridge, or under via a tunnel, the two centerlines must not be broken into nodes. They must cross as continuous, unsplit lines with differing Z-elevation attributes (Elevation = 0 for ground, Elevation = 1 for bridge). Inserting an intersection node at an overpass creates an impossible turn, directing emergency vehicles to drive off a bridge deck.
3. Pseudo-Nodes Elimination: A pseudo-node is an unnecessary node that divides a continuous road centerline into two segments where no intersecting street, municipal boundary, or attribute change occurs. Pseudo-nodes bloat database size and degrade CAD network calculation performance. They must be merged unless they mark a legitimate administrative boundary crossing (e.g., an ESB crossing).
4. Dangles, Undershoots, and Overshoots: Dead ends and cul-de-sacs must terminate in a single dangling node. However, intersections where a line fails to reach the crossing street (undershoot) or extends past it erroneously (overshoot) break network connectivity and must be corrected using topological snapping.

Address Point Quality Checks

• Range Conformance: The numeric house number of every SSAP must fall within the FromAddr and ToAddr range of the adjacent road centerline segment.
• Parity Alignment: An odd-numbered SSAP must sit on the side of the road centerline designated as odd (Parity = O). If an odd address point is geographically situated on the even side of the centerline, an addressing discrepancy exists.
• Side-of-Street Geometric Placement: Automated QA tools construct perpendicular vectors from each SSAP to the nearest road centerline to verify that the point is spatially positioned on the correct side of the street.

---

4. The NG911 Spatial Interface (SI) Architecture (NENA-STA-010)

In Next Generation 9-1-1, core network functional elements do not directly access local municipal or county GIS geodatabases. Local authorities use diverse GIS software platforms, coordinate projections, and internal maintenance schedules. To bridge this divide, NENA established NENA-STA-010, defining the Spatial Interface (SI).

The Spatial Interface is the authoritative functional entity responsible for collecting, transforming, validating, and provisioning spatial data from local 9-1-1 GIS authorities into the Next Generation Core Services (NGCS) environment.

  [LOCAL GIS REPOSITORIES]       [ETL TRANSFORMATION ENGINE]       [VALIDATION GATEWAYS]
  - City Geodatabase             - Re-project to WGS84 EPSG:4326   - Zero Gaps/Overlaps
  - County SDE Layers      ──►   - Map to NENA-STA-006 Schema──►   - Range Continuity
  - State DOT Road Centerlines   - Generate NGUIDs (URN form)      - Schema Conformance
                                 - Standardize CLDXF Street Names           │
                                                                            ▼
  [PRODUCTION NGCS DEPLOYMENT] ◄── [STAGING / QA SANDBOX] ◄──────── Passed All Checks
  - Live ECRF Routing Nodes        - Automated Mock LoST Queries   (Failed = Reject &
  - Live LVF Validation Nodes      - Regression Call Simulation     Report via DRS)

Steps in the Spatial Interface ETL Pipeline

1. Data Harvesting & Ingestion: The SI ingests authoritative spatial datasets from cities, counties, regional consortiums, and state departments of transportation.
2. Coordinate Transformation: Re-projects native GIS data (typically State Plane or Universal Transverse Mercator [UTM]) into unprojected WGS84 geographic coordinates (EPSG:4326).
3. Extract, Transform, Load (ETL): Normalizes diverse local data structures into the standardized NENA NG9-1-1 GIS Data Model (NENA-STA-006) and Civic Location Data eXchange Format (CLDXF). Generates NENA Globally Unique Identifiers (NGUIDs) for every feature.
4. Staging and Validation Gates: Before GIS data is pushed into active call routing engines, it is ingested into an isolated staging sandbox. Automated validation scripts test for:
   • Planar partition integrity (ensuring zero boundary gaps and overlaps).
   • Complete road centerline network connectivity and directional parity.
   • NGUID uniqueness.
   • Mandatory attribute completeness (no null values in required fields). If any critical validation check fails, the entire upload is rejected, and a detailed diagnostic error log is returned to the local data steward.
5. Provisioning Synchronization & Rollback: Delivers validated spatial databases simultaneously to live production ECRF and LVF nodes. The system maintains version control with instant rollback capability, ensuring that if an ingested dataset introduces unforeseen routing errors, the network can revert to the previous operational state within seconds.

---

5. Provisioning Core Functional Elements: ECRF vs. LVF

Once spatial data successfully passes through the Spatial Interface validation gateways, it is provisioned into two foundational NGCS engines that utilize the exact same GIS data for two entirely different operational purposes:

┌─────────────────────────────────────────────────────────────────────────────────┐
│                      LVF vs. ECRF: OPERATIONAL DICHOTOMY                        │
│                                                                                 │
│  LOCATION VALIDATION FUNCTION (LVF)    EMERGENCY CALL ROUTING FUNCTION (ECRF)   │
│  ──────────────────────────────────    ──────────────────────────────────────   │
│  • OPERATIONAL TIMING:                 • OPERATIONAL TIMING:                    │
│    Pre-Call Phase (Hours/Days Before)    Real-Time Call Setup (Milliseconds)    │
│  • PURPOSE:                            • PURPOSE:                               │
│    Validates civic addresses             Resolves spatial location to URI       │
│  • INITIATING ENTITY:                  • INITIATING ENTITY:                     │
│    Access Network Provider (LIS/Telco)   Emergency Service Routing Proxy (ESRP) │
│  • PROTOCOL:                           • PROTOCOL:                              │
│    LoST Protocol (RFC 5222)              LoST Protocol (RFC 5222)               │
│  • QUERY INPUT:                        • QUERY INPUT:                           │
│    Civic Address Structure               Geodetic Coords (Lat/Long) or Civic    │
│  • RESPONSE:                           • RESPONSE:                              │
│    <valid> or <invalid> status token     Authoritative SIP URI of Target PSAP   │
└─────────────────────────────────────────────────────────────────────────────────┘

The Location Validation Function (LVF)

• Pre-Call Operation: The LVF operates entirely in the pre-call provisioning phase—hours, days, or months before an emergency call occurs. It replaces the legacy MSAG validation process.
• Subscriber Address Certification: When a customer orders wireline, VoIP, or enterprise Multi-Line Telephone System (MLTS) service, the telecommunications service provider queries the LVF via the Location-to-Service Translation (LoST) protocol (IETF RFC 5222).
• Validation Engine: The LVF validates the submitted civic address against the provisioned Site/Structure Address Points (SSAP) and Road Centerline (RCL) address ranges. If the address exists and falls within valid jurisdictional boundaries, the LVF returns a <valid> response along with standardized CLDXF address elements.
• Error Prevention: If the address does not exist, the LVF returns an <invalid> response detailing which specific attribute failed (e.g., invalid street type, out-of-range house number). The carrier cannot provision the address for 9-1-1 service until the discrepancy is resolved, preventing unvalidated addresses from ever reaching the live emergency routing network.

The Emergency Call Routing Function (ECRF)

• Real-Time Operational Call Flow: The ECRF operates in real time during emergency call setup, executing within milliseconds.
• Spatial Routing Resolution: When a 9-1-1 call enters the ESInet, the Emergency Service Routing Proxy (ESRP) extracts the caller's location—either geodetic coordinates (latitude/longitude from GPS/WiFi) or a validated civic address—from the Presence Information Data Format Location Object (PIDF-LO). The ESRP sends a LoST <findService> query to the ECRF with the service URN urn:service:sos.
• Point-in-Polygon Query: The ECRF plots the coordinates against the provisioned PSAP Boundary layer. It performs a geometric point-in-polygon calculation, identifies the authoritative PSAP, and returns the PSAP's SIP routing URI (sip:psap@agency.org) to the ESRP so the call can be delivered.

---

6. The Discrepancy Reporting Web Service (DRS) & Exception Workflows

Despite rigorous pre-ingestion checks, anomalies inevitably emerge during live operations: callers report addresses that fail LVF validation, calls land near boundary lines that exhibit micro-gaps, or telecommunicators report that an address mapped to the wrong response zone. To manage these errors, NENA standardized the Discrepancy Reporting Web Service (DRS).

                    CLOSED-LOOP DRS REMEDIATION WORKFLOW

  1. DISCREPANCY DETECTED
     - LVF address validation failure (<invalid>)
     - ECRF boundary anomaly (gap/overlap/unresolved)
     - Telecommunicator CAD map discrepancy report
                 │
                 ▼
  2. AUTOMATED DRS TICKET CREATION
     - DRS generates structured XML/JSON discrepancy notice
     - Attaches error code, coordinates, timestamp, and bad record
                 │
                 ▼
  3. DISPATCHED TO LOCAL GIS STEWARD
     - Sent via automated web service to authoritative agency (DiscrpAgID)
     - Logged in municipal/county GIS remediation queue
                 │
                 ▼
  4. LOCAL INVESTIGATION & REMEDIATION
     - GIS technician researches aerial imagery, deeds, and field surveys
     - Corrects road centerline range, snaps boundary vertex, or adds SSAP
                 │
                 ▼
  5. RE-PROVISIONING & TICKET CLOSURE
     - Corrected layer pushed through Spatial Interface (SI)
     - ECRF/LVF updated; DRS validates fix and closes ticket

Common Discrepancy Categories

NENA i3 defines discrepancy reporting as a standard web service between functional elements and data owners; each report identifies the problem and the record involved. Common categories include:

• Address validation failures: A civic address submitted by a service provider does not match any SSAP or road centerline range in the LVF.
• Routing anomalies: A location falls in a boundary gap (no PSAP returned) or an overlap (conflicting results).
• Boundary edge mismatches: Adjacent GIS authorities have misaligned boundaries along a shared border.
• Attribute conflicts: An address point's attributes disagree with the underlying road centerline or boundary layers.
• Other data sources: Discrepancies can also be raised against routing policy, ALI or LIS records, or PSAP reports of wrong locations.

---

7. Comparative Summary: Spatial Provisioning Architecture

---

8. Operational Traps & ENP Exam Watch

• LVF vs. ECRF Operational Timing: This is one of the highest-yield questions on the ENP exam. The LVF operates in the pre-call phase to ensure subscriber addresses are valid before an emergency occurs. The ECRF operates in real time during emergency call setup to route active 9-1-1 calls.
• The Spatial Interface (SI) Does Not Edit Local Data: The SI is an ingestion and validation gateway; it does not author or manually correct GIS data. Authoritative corrections must always be executed by the local authoritative GIS data steward in the primary source database and re-provisioned through the SI.
• The 98% Match Rate Recommendation: NENA 71-501 recommends at least a 98% match rate between GIS and MSAG/ALI before relying on GIS for routing. Skipping reconciliation leads to validation kickouts and default-routed calls.