Preparing GIS Data for NG9-1-1

Sandi Stroud

National Director of Public Safety GIS

URISA Worshop Author and Instructor

Mid Atlantic Regional Leadership Chair –

NAPSG

Former GIS coordinator for Baltimore

Metropolitan Council (MPO) and GIS Manager

City of Laurel, MD 7/5/2015 2

7/5/2015 3

Dial “911”

Emergency Call

Routing

Speaking to PSAP

Source: Evan Mason (Wikipedia)

Current Revenue for Telephone Company MSAG/ALI/cellular location/selective router access fees

Emergency Call Routing Workflow: E9-1-1

Emergency Call Routing Workflow: NG9-1-1

Source: Evan Mason (Wikipedia)

Spatial Information Function (SIF) Location information component of the i3 NG9-1-1 architecture indicates the source for this as authoritative locally maintained GIS data. This source data feed into the ESInet ECRF/LVF call routing components replaces the need for the MSAG/ALI/cellular location/selective router services

Replaced by locally maintained ESInet components

NG9-1-1 3 Components

Confusing Database Standards Conflicting Authority: Addressing,

GIS and New Data Editors Getting Data Ready for “go live”

• Mutual Aid Data

Planning ahead

GIS “Pain Points”: Overview

Documents to Review NENA

Published • 08-003 Detailed Functional and Interface Standards for the NENA i3

Solution

• 71-501 Synchronizing GIS with MSAG & ALI

Draft • GIS Data Model for NG9-1-1

• this document defines the Geographic Information Systems (GIS) database model that will be used to support the NENA Next Generation 9-1-1 (NG9- 1-1) systems, databases, call routing, call handling, and related processes.

• Provisioning and Maintenance of GIS data to ECRF/LVF

• Site/Structure Address Points

• Is currently developing a document to serve as a guide for those developing site/structure address point data in a GIS for use in 9-1-

• Next Generation 9-1-1 Data Management Requirements

• The intent of the document is to provide 9-1-1 authorities, vendors, Communication Service Providers (CSP), and other interested parties with guidelines for communicating issues or status of various elements within the system.

This document describes the “end state” that has been reached after a migration from legacy TDM circuit-switched telephony, and the legacy E9-1-1 system built to support it, to an all IP-based telephony system with a corresponding IP-based Emergency Services IP network (ESInet). To get to this “end state” it is critical to understand the following underlying assumptions:

#5 9-1-1 authorities have accurate and complete GIS systems, which are used to provision the LVF and ECRF. A change to the 9-1-1Authority’s GIS system automatically propagates to the ECRF and LVF and immediately affects routing.”

(NENA 08-003, p. 16)

Assumptions in 08-003

GIS Data Model for NG9-1-1

Defines, the Geographic Information Systems

(GIS) database model that will be used to support

the NENA Next Generation 9-1-1 (NG9- 1-1)

systems, databases, call routing, call handling,

and related processes.

Not written for the GIS stakeholder

• May need some additional “translation”

MINIMUM requirements

Still in draft mode; is planned for public

comment release.

GIS Data Model for NG9-1-1

Already being used

• Different versions are being adopted and used by

local, regional and state authorities (TIPS)

Does not “require” address points

• The requirements will be driven by business process

and stakeholder input

New data layers for a GIS

• Authoritative Boundary

• PSAP Boundary

NENA is developing a data management requirements document that includes recommended turnaround times for error correction in GIS data provided to the system • In draft format • Between 1 and 3 business days

RECCOMENDATION: Need an internal GIS data maintenance workflow that enables the emergency communications center to edit the GIS that their system is using in near-real time fashion. Also needs to include workflow for new address’ to enter into GIS system in near-real time fashion.

Next Generation 9-1-1 Data Management Requirements

Minimum Data Required to

Support ECRF/LVF in i3 NG9-

1-1 Architecture*

Source: data supplied to the SIF should

come from each jurisdiction as defined by

the extents of the Authoritative Boundary

polygon.

Footprint: each PSAP needs access to a

seamless, normalized and highly accurate

footprint of data from any jurisdiction it

shares a boundary with.

Update: new data and data errors should

be updated in the GIS within a 1-3 business

day cycle.

Accuracy: Each source entity is

responsible for the accuracy (both spatial

and attribution) of each dataset. This

results in the need for coordination amongst

neighboring jurisdictions as there are no

allowable gaps, overlaps or redundancies in

any of the datasets.

Road Centerlines

PSAP Boundaries

Emergency Services Boundaries

Authoritative Boundaries *Address Point data is not required per the NENA NG9-1-1

GIS Data Model but will likely be deemed so by the majority of end-users.

Attribute Mandatory/Option

al Field Type Field Length

Source of Data M A 75

Date Updated M D 26

Effective Date M D 26

Expiration Date O D 26

RCL_Unique_ID M A 100

Understand your PSAP model and data flow

Conflicting Authority: Addressing, GIS and New Data Editors

NENA is developing a data management standard that includes recommended turnaround times for error correction in GIS data provided to the system • In draft format • Between 1 and 3 business days

RECCOMENDATION: Need an internal GIS data maintenance workflow that enables the emergency communications center to edit the GIS that their system is using in near-real time fashion. Also needs to include workflow for new address’ to enter into GIS system in near-real time fashion.

GIS Data Maintenance for NG9-1-1

GIS database (Multi-jurisdiction)

Data Assessment - MSAG/ALI Corrections - Data Clean Up/Creation - Boundary Conflation – Aggregation of Data

Now 3 months 6 months 9 months 12 months 18 months

Planning

GIS d

atabase p

lann

ing - sam

ple

Now Task

3 months MSAG – Centerline • Identify where errors exist (GIS or telco) • Update centerline • Update telco

• MSAG defines a tabular extent of PSAP boundary but centerlines will define spatial extent.

Identify “authorities”

• Identify required datasets to support emergency call routing business driver

• Identify internal authority of datasets; coordinate access and update schedule

• Eliminate silos of data being maintained and work through access issues

6 months ALI – Centerline ALI – Address Point

• Identify where errors exist (GIS or telco) • Update centerline/address points • Update telco*

• Making the centerline corrections first will reduce redundant ALI errors that require analysis.

9 months Internal Data Clean Up/Data Creation

• PSAP boundary • Address Points • Centerline • Authoratative Boundary • Emergency Services Zones

• Need to conduct spatial and likely some attribution level quality control validations.

• Topology of boundaries • Centerline edge matching • Address point location • Centerline-address point

validations

12 months External Data Clean Up • Work with neighboring jurisdictions on boundary data conflation

• No gaps/overlaps in boundary files • PSAP/Authoritative boundary

topology w/ centerlines • No centerline feature duplication • No address point duplication • Road name alias table

18 months Prepare data for coalesce into database management system

• Database “crosswalk” needed • Update schedule

Planning

Data Cleanup and Readiness: coordinate with neighbors

Data Cleanup and Readiness: defining authority

Data Cleanup and Readiness: other business drivers

MSAG/ALI Comparison

MSAG to

Centerline to

ALI to

Centerline to

ALI to

Address Points to

MSAG to

ALI to

MSAG/ALI Comparison

*slated for release in v2

MSAG

Errors in MSAG • Blank fields • Incorrect ESN/MSAG community • Incorrect domains (ie: street type)

Run initial MSAG validations

Errors in Centerline • Incorrect domains (ie: street type) • Punctuation and spaces • No ESN/MSAG community*

Run initial centerline validations

Errors in either MSAG or Centerline

• Centerline or MSAG range inaccuracy • Centerline or MSAG attribute discrepancy • No match centerline or MSAG features

Centerline-MSAG comparison MSAG-Centerline comparison

ALI

Errors in ALI • Blank fields • Incorrect ESN/MSAG community • Incorrect domains (ie: street type) • ALI no match to MSAG or attribute discrepancy

Run initial ALI validations ALI – MSAG validations

Errors in Address Point

• Incorrect domains (ie: street type) • Punctuation and spaces • No ESN/MSAG community*

Run initial address point validations

Errors in either ALI, Address Points or Centerline

• No match ALI to Address Point • No match ALI to Centerline • Partial match ALI to Address Point • Partial match ALI to Centerline

ALI – Centerline ALI – Address Point

GIS database (Multi-jurisdiction)

Data Assessment - MSAG/ALI Corrections - Data Clean Up/Creation - Boundary Conflation – Aggregation of Data

Now 3 months 6 months 9 months 12 months 18 months

Planning

Tennessee (case study) • State created standard and PSAP/ESZ boundary

layer • GIS grants for data clean up • MSAG synchronization and clean up • ALI synchronization • Staff of 10 • 5 year project (just went live January 2015) • No more grant $$$ - locals mired with ALI issues • Are routing calls geospatially