OK NG911 GIS Toolkit

Most recent version as of February, 2022: Version 0.5.0

Adapted from the  Kansas NG911 Toolkit , the Oklahoma Next-Generation 9-1-1 Toolkit is a collection of Toolsets modified to identify possible errors and assist the user in complying with the NG911 Oklahoma Standards. The Oklahoma NG911 GIS Toolkit can be found at the  Oklahoma Geographic Information (GI) Council  website and includes the following parts:

• OK Prep - Provides the user with an easy way to create new standard-compliant geodatabases and/or convert existing data to comply with the Oklahoma NG911 Standards.
• Adjustment - Can fix minor errors and inconsistencies for certain fields in a given feature class.
• Comparison - Look for differences between versions of NG911 feature classes or entire geodatabases.
• Enhancement - Automate various tasks involved with data creation and perform quality checks to enhance data such as a Fishbone Analysis.
• MSAG - Compares MSAG spreadsheets or Telephone Number spreadsheets with the Road Centerline feature class.
• Submission - Can zip the geodatabase into a folder or convert feature classes to shapefiles.
• Validation - Review NG911 geodatabase data for submission to the NG911 repository using the Oklahoma NG911 Standards.

According to the NG911 Oklahoma Standards, there are 8 required feature class layers. The Oklahoma Standards can be found at the  Oklahoma GI Council website .

• Address Point
• Road Centerline
• Discrepancy Agency Boundary
• PSAP Boundary
• ESZ Boundary
• ESB Fire Boundary
• ESB Law Boundary
• ESB EMS Boundary

To begin utilizing the toolkit, unzip the NG911 Toolbox and leave all files and folders in the original structure. Maintaining this file/folder structure is required for proper operation of the Toolkit. The Toolkit requires an installation of ArcGIS Desktop and Python 2. The 'arcpy' package included with ArcGIS is required as well as an active license. Standard licensing is required for Topology (which is part of Check All Required), and Advanced license is required for Check Road ESN Advanced (optional Enhancement Tool setting). Otherwise, a Basic license is required. We recommend at least a Standard license for proper operation of the Toolkit.

First, the user must consider what data (if any) they have. Does the user have any data? If not, the user can start with the Create GDB tool in the OK Prep Toolset to create a blank GDB with blank required feature classes.

If the user has some data, does the data have the correct Unique NENA IDs for a given feature class? If not, the user can run the Assign Unique NENA ID tool in the Enhancement Toolset.

Is all the data in a Standard-compliant GDB? If not, run the Create GDB tool. If your feature classes are not Standard-compliant, then save them for the Field Map tools in the OK Prep Toolset.

Are the feature classes formatted to meet Oklahoma NG911 Standards with the correct field names, lengths, domains, etc? If not, the user can run the Field Map tools in the OK Prep Toolset.

Is the data itself Standard-compliant? Once the datasets are all formatted correctly and in a Standard-compliant GDB, the user can then run the Validation tools to make sure the data in the feature classes meet standards and the user isn't missing any required information.

There are a few Adjustment and Enhancement tools to assist the user in limited correction of the data such as Fix Submit tool which fills in the null SUBMIT field with "Y" or the Geocompare Address Points tool which fills in the Address Point RCLMATCH field with the corresponding Road Centerline NENA ID. For more information about a particular tool, see the Documentation provided with the toolkit.

The OK Prep tools are extremely useful and likely where the user will begin utilizing the toolkit.

If the user doesn't have a Standard-compliant geodatabase, then the 0 Create GDB tool is where they'll start. The tool inputs are a folder location for the geodatabase, an output GDB name, and a selected coordinate reference system (the Standard-compliant reference system is default). The user can then add Standard-compliant feature classes to the GDB, create blank Standard-compliant feature classes, or leave the input blank to do neither. If the users has non-Standard-compliant feature classes, then they should leave the appropriate feature class input blank (these feature classes will be field mapped later).

To use the Field Map tools, the user will input the desired feature class, a Standard-compliant geodatabase, and the corresponding field map fields for all possible fields in a given feature class. If the tool detects the name of a already Standard-compliant field name, the tool will automatically fill-in the appropriate field name for the user. This reduces the amount of time manually mapping the field to the appropriate standard-field name.

The tool will then create a Standard-compliant feature class with the correct field names and other field attributes. Using the field mapping inputted by the user, the tool will then append the appropriate data to the corresponding fields. In the end, a Standard-compliant feature class will be created in the Standard-compliant geodatabase that was supplied.

Once the user is fairly certain they have Standard-compliant data in a Standard-compliant geodatabase, the user can move onto the validation of the data to ensure standard-compliance of the data itself.

At this point, the user will want to run the Check All Required tool on the Standard-compliant geodatabase. Some of the checks include checking that the required fields have values (fields that should not be null), making sure that the values match the domains where applicable, and checking that every object has a Unique NENA ID that is correctly formatted. For an extensive list of Validation checks, see the Validation Documentation provided with the Toolkit in the Docs folder.

The Validation tools will write to two output tables: TemplateCheckResults and FieldValuesCheckResults. The tools will return an "Error" or a "Notice". Errors are crucial to the Standard and must be fixed, while Notices are issues that won't impede submission of the dataset but should be looked at to ensure the issue isn't an actual problem. As shown in the example tables below, the TemplateCheckResults table outputs errors with regards to the schema. This includes feature classes that must match Standard names exactly and must be within the NG911 feature dataset to be detected by the Validation check as correct. The spatial reference must be WGS 84 as default in the Create GDB tool. Similarly, the FieldValuesCheckResults table outputs the other errors and notices detected by the Validation checks such as Topology errors not marked as exceptions, Field Domain issues, and Unique NENA ID formatting errors.

Please note that the Check All Required will delete the output results tables, while the other Validation tools will not. If you would like to clear the results tables, run the Clear Results Table tool. Check All Required will also create a text file with the name of the geodatabase in the same folder location that states the date, time, and either PASS or FAIL.

If the user is wanting to run checks on a specific feature class or feature class category (Boundaries), then these options are available instead of running the Check All Required tool for every minor change to the data.

The Oklahoma NG911 Standards require that a number of topological relationships exist within and among the feature classes.

All Polygon feature classes must individually conform to the rule:

• Must Not Overlap (Area)

The ESB_EMS_BOUNDARY, ESB_FIRE_BOUNDARY, ESB_LAW_BOUNDARY, and PSAP_BOUNDARY layers must individually conform to the rule:

• Must Not Have Gaps (Area)

The ROAD_CENTERLINE layer must conform to the following rules:

• Must Not Overlap (Line)
• Must Not Have Dangles (Line)
• Must Not Self-Overlap (Line)
• Must Not Self-Intersect (Line)
• Must Be Single Part (Line)

NOTE: Rules in italics may be marked as exceptions on a per-feature basis (denoted by the TopoExcept Field).

• ADDRESS_POINT: Must Be Properly Inside (Point-Area)
• ROAD_CENTERLINE: Must Be Inside (Line-Area)
• ESB_EMS_BOUNDARY: Must Cover Each Cover (Area-Area)
• ESB_Fire_BOUNDARY: Must Cover Each Cover (Area-Area)
• ESB_Law_BOUNDARY: Must Cover Each Cover (Area-Area)
• ESZ_BOUNDARY: Must Cover Each Cover (Area-Area)
• PSAP_BOUNDARY: Must Cover Each Cover (Area-Area)

NOTE: Rules in italics may be marked as exceptions on a per-feature basis (denoted by the TopoExcept Field).

The ROAD_CENTERLINE feature class includes the TopoExcept field, which allows the user to mark individual features as exempt from the Must Not Have Dangles (Line) and/or the Must Be Inside (Line-Area) (with DISCREPANCYAGENCY_BOUNDARY) rule. These exceptions will be accounted for when the Verify Topology Exceptions or Check All Required Validation tools are run.

The Adjustment Toolset can fix minor errors and inconsistencies for certain fields in a given feature class.

Fix Street Type and Direction

The Fix Street Type and Direction tool allows the user to copy Street Type and Direction fields (StreetType, PreDir, SufDir, Street) to their Legacy field counterparts (LgcyType, LgcySufDir, LgcyPreDir, LgcyStreet) and to convert the Street Type and Direction fields to the correct next generation schema (fully written out). The tool will also give the user the option to calculate LgcyAdd if an Address Point feature class is provided.

Fix Submit

The Fix Submit tool will calculate blank/null values in the SUBMIT Field to "Y" for specific feature classes or the entire geodatabase. The user would mark to objects they don't want included in submission with a "N" and run the Fix Submit tool.

The Comparison Toolset can be user to look at difference between NG911 feature classes or entire geodatabases. It is important that the feature classes and geodatabases are Standard-compliant to utilize the tool properly.

Add/Validate NG911 Topology

The Add/Validate NG911 Topology tool creates and adds layers and rules to the topology and can validate topology if checked. This tool does not export errors for topology to the FieldValuesCheckResults table, so topology exceptions (TopoExcept) are not taken into consideration with this tool.

Assign Unique NENA ID

The Assign Unique NENA ID creates an Unique NENA ID for features in a feature class. The feature class does NOT have to be Standard-compliant to run. The tool can generate new IDs for all the features or change only the null values. The user may optionally provide a field with existing local unique IDs consisting of numbers, characters, dashes, and curly-braces to be incorporated into the newly-generated NENA IDs, or the user can allow the tool to generate sequential numbers for the NENA IDs. The only required field is the Agency_ID field, because it's necessary for the construction of the Unique NENA ID.

Generate Fishbone Analysis

The Generate Fishbone Analysis tool generates a "Dirty" Fishbone Analysis for Address Point Verification. The analysis is considered dirty, because the fishbone line shapefile is created without the user performing a quality check on the geocoded data. Ties and non-matches are simply removed from the analysis. This tool should be used as an aid to the QA/QC process and not as a complete quality check of the data.

For more on the methods for the Generate Fishbone Analysis tool, see the Generate Fishbone Analysis Tool Documentation in the Docs Folder.

Calculating the Required Fields: RCLMatch and RCLSide

In order to calculate the required fields RCLMatch and RCLSide in the Address Point feature class, the user should begin with running the Geocompare Address Points Tool on Standard-compliant data. After that has completed, the user will then run the Populate RCLMatch NO_MATCH tool to populate missing/null values to "No Match" and "U" for RCLSide.

All MSAG Tools have a legacy option to use the legacy fields in the NG911 geodatabase if MSAG or TN spreadsheets are formatted with the legacy format.

MSAG NG911 Comparison

The MSAG NG911 Comparison tool compares a Master Street Address Guide (MSAG) Excel file with the NG911 Road Centerline address ranges. The tool returns errors for segments in the MSAG File that are not in the Road Centerline, segments in the NG911 Road Centerline that are not in the MSAG, and any values or ranges in either the MSAG or NG911 Road Centerline that exist in one file but not the other. The tool creates a folder called MSAG_analysis_NameOfGeodatabase in the same folder as your NG911 Geodatabase. Inside the folder, a geodatabase called MSAG_analysis_NameOfGeodatabase.gdb is created where all working layers and tables are saved. While most of the outputs can be useful, the one of note is the MSAG_reporting table. This will give you the report and comparison field. If the MSAG and Road Centerline address ranges for a segment match, then the report will return "Exact MSAG match". Otherwise, the report will return multiple outputs including "Does not have an MSAG match", "Does not have a road centerline match", or "Not in NG911 road" and "Not in MSAG" for a given set of address ranges along a given road segment.

Check TN List

The Telephone Number tools compare a telephone number spreadsheet to the NG911 Road Centerline address ranges. There are two tools: one for AT&T specific spreadsheets and one for all TN carriers. The tool geocodes full addresses housed in a spreadsheet against MSAG information in a NG911 geodatabase. Similar to the MSAG NG911 Comparison, the TN tool will create a folder with the name NameOfGeodatabase_TN with a geodatabase called TN_Working.gdb.

This update included:

• CURRENTLY, MSAG and TN Tools do NOT function as intended. Please wait for the next Standards update.
• Fixed FullName/FullAddr concatenations and usages
• Fixed Unicode compatibility issues
• Improved Legacy checks specifically to MSAG_CheckTNList.py.
• Finalized usage of MSAGComm fields in Geocompare Address Points Tool and other necessary usages
• Improved Street Name/Type/Direction parsing
• Removed null values of MSAGComm from appropriate feature classes before running MSAG or TN Tools.
• Added Fix PreType to Fix Street Type and Direction Tool.
• Replaced all usages of Label with FullName/FullAddr where appropriate and deleted Calculate Label Tool.
• Added Check Road FromLevel ToLevel Tool.
• Updated Documentation

For more information about the changes to the Oklahoma NG911 GIS Toolkit, please see the Change Log with the Toolkit Folder.

With the exception of emergency version releases, the next version of the Toolkit will be released after the next version of the Standards.

• Adding `TopoExcept` to Address Point Feature Class
  • The `TopoExcept` field is expected to be added to the Standards.
  • It will be implemented into the Topology analysis to account for address points that are outside the Discrepancy Agency Boundary but need to be included in the NG911 data for that PSAP.
• Adding `LgcyPreTyp` to Address Point and Road Centerline Feature Classes
  • The `LgcyPreTyp` field is expected to be added to the Standards.
  • It will be implemented into `LGCYNAME_FIELDS` and `LGCYADDR_FIELDS` to fix the MSAG Tools functionality.
  • We will be adding "Copy from PreType to LgcyPreTyp" to the Fix Street Type and Direction Tool.
• ArcGIS Pro Conversion
  • ArcGIS Desktop has entered the phase of its life where it is only being maintained, not updated.
  • The Oklahoma NG911 GIS Toolkit will be converted to the Oklahoma NG911 GIS Pro Toolkit.
• Python Toolboxes Conversion
  • With the complexity of the Custom Toolbox Validation codes for the some of the NG911 Tools, we are exploring the possibility of implementing Python Toolboxes instead of Custom Toolboxes.
• Documentation Fixes
  • Documentation will be fixed as necessary.
  • A glossary of outputs and errors will be created.