NENA Next Generation 9-1-1 Workflows in FME

Introduction

Next Generation 9-1-1 (NG9-1-1) is all about transitioning emergency call capabilities from analog to the new digital IP-based, geo-enabled 9-1-1 system. To accomplish this, data providers need to consolidate required data and conform to NENA NG9-1-1 standards. NG9-1-1 will be implemented in stages. First, the existing functionality will be migrated to the new digitally based communications system. Next, device location + GIS data will be aggregated from local authorities so that 9-1-1 dispatch systems can execute geodetic call routing. After that, support for additional data will be added, such as real-time text, phone, video & photo, and med alerts enabled from devices. This will provide a richer set of situational awareness to better inform dispatched emergency crews.

FME provides tools to support the data transformation, validation, and update automation required for NG9-1-1 compliance. Ultimately, the goal is that geo-enabled digital NG9-1-1 will improve emergency response and save lives.

Key FME Workflows 

Two of the crucial workflows required for NG9-1-1 GIS data management are data loading and validation. Sample demos for each of these workflows are included below. Note that the examples and data provided are for instructional use only, are not meant to be used in any operational capacity, and there is no implied endorsement by any related agency. Questions about the data should be referred to the data authority, and questions about the NENA standards should be addressed by consulting the appropriate NENA standards, such as the NG9-1-1 project at nena.org. For more on the NENA GIS data model used for these demos, see the NENA GIS data model specification available from NENA's NG9-1-1 GitHub project.

NENA NG9-1-1 Data Loader

The purpose of this NG9-1-1 loader workflow is to demonstrate how to extract data from a local municipal dataset, transform it, and then load it into a NENA-compliant GIS database schema. The data used in this demo is the assessors parcel database obtained from the publicly accessible Winnipeg Open Data portal. 

The source data theme used is the assessment parcels exported as GeoJSON from: https://data.winnipeg.ca/Assessment-Taxation-Corporate/Assessment-Parcels/d4mq-wa44/about_data

Source parcel assessment data from the Winnipeg Open Data Portal

The loader reads from the Winnipeg parcels GeoJSON dataset above, performs the transformations below, and then writes out the NENA GIS database as either an Esri geodatabase or an OGC GeoPackage.

Loader Transformation Steps

1. Convert parcel polygons to points using the CenterPointReplacer
2. Extract longitude and latitude values with the CoordinateExtractor
3. Generate required fields such as the NENA ID or NGUID
4. Remove records with duplicate IDs or addresses
5. Perform schema mapping from Assessment Parcels schema to NENA NG9-1-1 database schema
6. Convert date time fields to the correct format
7. Apply field value mappings to NENA code lists
8. Change case to mixed title case

NG9-1-1 Loader Workspace

Winnipeg SiteStructureAddressPoint GIS database output (geodatabase and GeoPackage)

NENA NG9-1-1 Data Validator

The NG9-1-1 validator is meant to support the pre-validation of NG9-1-1 GIS data against the NENA GIS standards. The idea is to validate early and often in order to minimize the number of validation errors during the final top-level aggregation process. Our validator is more of an instructional tool to demonstrate how users can configure their own validator and is not meant to be used as a finalized product to certify NENA compliance on its own.  One advantage of the FME approach is that it can easily be customized and also supports automation. Esri also provides an NG9-1-1 Validator as a hosted web-based tool that can also be used to do comprehensive checks on the NG9-1-1 file geodatabase. This tool uses a user-interactive web form and requires an AGOL account.

For the purposes of this tutorial, it's best to work through the data loader exercise above and then use the resulting NENA geodatabase or GeoPackage as the input for this validation demo. Note that only one of the geodatabase or GeoPackage NG9-1-1 readers in the validator should be enabled at a time.

Key Validation Steps

1. Read SiteStructureAddressPoint database table (geodatabase or GeoPackage)
2. Read data authority provisioning boundary
3. Error introduction (these steps are only for instructional purposes and would be omitted for a typical validation implementation): Introduce attribute, schema & geometry errors
4. Feed features through the NG911Validator custom transformer to run schema and attribute checks
5. Use the GeometryValidator to check for valid geometry
6. Use the GeometryFilter to confirm point geometry
7. Use the SpatialFilter to check that the address points fall within the provisioning boundary
8. Output error features to a Visualizer for inspection on a map interface
9. Generate an HTML error report with a record for every error instance

NG911Validator workspace

HTML Validation Report with Validation Errors

Validation Error features in FME Data Inspector

Validation errors can be reviewed in the Data Inspector output or in the HTML Report. Every error has an address point feature associated with it. If one input address has multiple errors, it will generate multiple error features. The map output can also be written to an error feature dataset in a format of choice, such as GeoJSON. The visual output makes it easier to locate the actual error feature and use that to locate the associated record in the source dataset to correct the problem.

The NG911Validator is configured to use business rule CSV tables, which were extracted directly from the NENA GIS Specification table definition rules. Alternatively, users can simply use a range of testing transformers, such as Testers, AttributeValidators, etc., to perform this schema, attribute data type, and value checks.

Note that this early validator version does not include domain code checks. The user can add additional validations to address more of the NENA business rules or to take into account the specific context and issues associated with the local data authorities. Note that this validator currently only checks on schema, field names, data types, and field widths. Code list checks and conditional attribute checks will be added later.

References

For more information on NG9-1-1 and a video demo of the above workspaces, please refer to our webinar: Data-Driven Public Safety: Reliable Data When Every Second Counts

NENA NG9-1-1 Project: https://www.nena.org/page/ng911_project 

NENA NG9-1-1 github: https://github.com/NENA911/NG911GISDataModel 

NENA GIS Data model: https://github.com/NENA911/NG911GISDataModel/blob/main/docs/nena-sta-006.2-2022_ng9-1-1.pdf 

CRTC Emergency Services Working Group: https://crtc.gc.ca/cisc/eng/cisf3e4.htm 

For more information from Esri, see the Esri NG9-1-1 overview, Public Safety GeoXchange and the Esri NG9-1-1 Validator.

If you have specific questions about how to adapt these loader and validation workflows to your specific context, please contact Safe Software Support.

Data Attribution

The data used here originates from data made available by the City of Winnipeg, Manitoba. It contains information licensed under the Open Government License - Winnipeg.