NENA Standard for NG9-1-1 GIS Data Model

1. NENA Standard for NG9-1-1 GIS Data Model John Milburn Hancock County GIS Coordinator 111 S American Legion Pl Suite 171 Greenfield, IN 46140 317-477-1150 jmilburn@hancockcoingov.org

2. The Intent of Presentation • Describe the basics of the standard • Describe some relatively painless ways we can meet most of the standard • Help motivate Indiana to adopt a standard so the GIS community can actually help. Otherwise, everything we’re doing to try and support NG9-1-1 is just busy work. Because, if we don’t have a standard then we can’t build out a strategy for how we’re going to get from where we are now to a NG9-1-1 ready State in a coherent and transparent way. *Caveat – I’m not a 911 Professional. I have a basic understanding of 911 and how spatial data is leveraged in a NG9-1-1 environment. This presentation is being given from a GIS perspective.

3. Additionally, according to NENA following the standard… • “Enables the validation of civic locations before a 9-1-1 call is made” • “Provides the data structure that allows the NG9-1-1 functionality that routes calls to the correct destination” • “Maintains or improves support for accurate plotting of 9-1-1 calls in public safety mapping applications for call handling purposes” • “Provides a framework to help migrate existing GIS datasets to NG9-1-1 systems” • “Streamlines data maintenance” • “Enhances interoperability and data sharing” • “Reduces confusion and ambiguity that can result for unstandardized data”

4. Basics • The current standard (NENA-STA-006.1-201X) hasn’t been finalized and is just a draft. It’s not official, at least not yet. • It’s a Data Sharing standard. The standard doesn’t apply to the GIS data a Public Safety Answering Point (PSAP) uses for daily operations. The GIS data they provide to other public safety entities has to follow the standard. So if a PSAP maintains mandatory GIS layers in a different schema then it has to convert them to the standard before it hands them off to someone else. • Shared GIS layers are required to include all mandatory data fields in the data model but are not required to include optional and conditional fields if a PSAP doesn’t maintain these.

5. Basics continued… • Data fields are standardized and domains are assigned to them, values outside a domain are ignored or replaced with null values. • Every feature of every mandatory layer has a NENA Globally Unique ID (NGUID). For example a Hancock County road centerline layer might have a feature with a NGUID of RCL12011@hancock.in.us. This would differentiate it from every other line segment of every single road centerline in the United States. This is very powerful. We’ll discuss it more later. • GIS data format (shapefile, GDB, MDB etc…) is not defined in the NENA data model.

6. Basics continued… • The Coordinate Reference System and Datum used for all mandatory layers is the World Geodetic System of 1984 (WGS84). • Geodetic parameters for 2-D geometries (EPSG:4326) • Geodetic parameters for 3-D geometries (EPSG: 4979)

7. A few notes… • Data type and field width (where applicable) are defined in the standard. I’m not going to go over these. • Each field is defined as either Mandatory, Conditional or Optional. I’m only going to cover Mandatory fields.

8. Mandatory Layers • Road Centerlines • Site/Structure Address Points • PSAP Boundary • Emergency Service Boundary (Law, Fire and EMS Boundaries as separate layers. • Provisioning Boundary

9. Mandatory Fields Road Centerlines • Discrepancy Agency ID “Agency that receives a Discrepancy Report, should a discrepancy be discovered, and will take responsibility for ensuring discrepancy resolution. This may not be the same as the 911 Authority…” • Date Updated • Road Centerline NENA Globally Unique ID • Left FROM Address • Left TO Address • Right FROM Address • Right TO Address • Parity Left (if address range is even or odd) • Parity Right (if address range is even or odd) • Street Name (no prefix, street type or suffix)

10. Road Centerlines cont..… • Country Left • Country Right • State left • State Right • County Left • County Right • Incorporated Municipality Left (not postal, corp boundary) • Incorporated Municipality Right (not postal, corp boundary) *Could be issues with no prefix or suffix directional and street type. NENA may be assuming in this case that the PSAP would be using the conditional street name alias table.

11. Mandatory Fields Address Points • Discrepancy Agency ID • Date Updated • Site NENA Globally Unique ID • Country • State • County • Incorporated Municipality *Interestingly, the actual address is not mandatory. It’s probably assumed that in this case the conditional landmark name table would be linked to NGUID. *Also, in some PSAPs an address point may be used solely to identify an access point. The actual address may come from another source, like a parcel polygon.

12. PSAP Boundary • Discrepancy Agency ID • Date Updated • ESB NENA Globally Unique ID • State • Service URI (uniform resource identifier used for call routing, for example, sips:sos.psap@eoc.houston.tx.us:+12025551212) • Service URN (uniform resource name used to select a service) • Agency vCard URI (electronic business card) • Display Name

13. Emergency Service Boundaries • Discrepancy Agency ID (unique layer for each Law, Fire, EMS) • Data Updated • ESB NENA Globally Unique ID • State • Agency_ID • Service URI • Service URN • Agency vCard URI • Display Name

14. Provisioning Boundary • “This polygon layer defines the area of GIS data provisioning responsibility, with no unintentional gaps or overlaps. The Provisioning Boundary Polygon must be agreed to by all adjoining data provisioning providers…” • My perception is this is necessary because one PSAP may provide service inside another PSAPs territory. Currently, this can be a little confusing, for example if one PSAP’s been contracted to dispatch Fire and EMS inside another’s area but that area’s PSAP still dispatches Law Enforcement then they may both maintain different GIS datasets for that area. Which entity feeds data to the NG9-1-1 system?

15. Provisioning Boundary Mandatory Fields • Discrepancy Agency ID • Date Updated • Provisioning Boundary NENA Globally Unique ID

16. Anticipated timeline to develop NG9-1-1 GIS Data • Depends on the quality of existing data. • NENA strongly advises that one go through the process of standardizing and synchronizing their existing GIS data with the Master Street Address Guide (MSAG) and Automatic Location Information (ALI) as described in NENA 71-501 prior to migrating to NG9-1-1. NENA further advises that the MSAG and GIS data reach a 98% or greater match rate. • The estimates I’ve heard indicate that it usually takes 1-2 years.

17. Those are the basics… There’s lots more in the standard and the current draft can be accessed online at – https://dev.nena.org/higherlogic/ws/public/document?document_id=12932&wg_id=csds-gis If you have at least a basic understanding both 911 and GIS and you’re a NENA member then you can also be a part of the NENA GIS Data Model for NG9-1-1 Work Group – https://www.nena.org/?page=GIS_DataNG911

18. Some thoughts on the GUID… • If every feature in every map layer has a GUID then it gets a lot easier to add value to the data beyond what the standard requires but still keep your dataset up to date. Instead of having to update a entire dataset with each data harvest you only have to process features that’ve changed in some way. • For example, if you have a centerline database that contains GUID, street name, line length and the X,Y coordinates of the beginning and end node of the line then you can compare the GUID’s of harvested data to the GUID’s in the database. If the values in the harvested street centerline database are the same then you can simply leave those features alone. This makes doing value add work much more viable and data will be much easier to process and update if it needs to be converted to a different format. • The majority of centerline data isn’t going to change from harvest to harvest so why process all of it?

19. It’s worth noting... • Meeting most of the requirements doesn’t take any knowledge of coding but if you know how to code, most, if not all (depending on your data) of the process can be automated. If everyone uses the same database schema then you only have one schema you need to convert to and from. • If the mandatory GIS layers you use for day to day operations are already in the schema then everything gets real easy.

20. Tips for meeting the standard if you’re not very familiar with coding Assuming you’re using ESRI products, the field calculator is your friend. 90% of the time, converting from your current format to the standard is just a field calculation. For example, if you need to assign a NGUID to all the line segments in your centerline dataset then that’s just "RCL" & [FID] & "@911_county.in.us“

21. Tips cont..… A lot of data clean up can be done with a simple ‘replace’ command. Just change your field calculator parser to Python and a short field calculation can make removing extra spaces, punctuation, or converting to NENA naming conventions very easy. Be sure you’re in a edit session first so you can undo changes in case you get unexpected results. !St_Name!.replace (“ “, “ “) !St_Name!.replace (“.”, “”) !St_Name!.replace (“Street”, “ST”)

22. Tips cont.… Parity values: assuming you have address ranges on your centerlines and their terminal vertices ends in the direction of ascending addresses, are a simple Selection by Attribute. You can select all even or odd address ranges in a field with MOD(“Field Name”, 2) = 0 Unselect all the records with a value of 0 in both to and from fields then the remaining values have a parity of even. Odd is MOD(“Field Name”, 2) = 1 Do a field calculation in the selected records R/L parity field

23. Parity Cont. • If you don’t have address ranges on your centerlines and the direction of line flow is arbitrary then you have a little more work to do but you don’t need to touch every line one by one. • You’ll need to build an addressing meridians layer to use the following method. A quick and easy way to do this is by making a copy of both your corporate boundary layer and county boundary layer. Delete all the corporate boundaries that use county addressing then perform a Union analysis between the two. Divide the municipal and county boundary polygon into addressing quarters (NE, NW, SE, SW) along the addressing meridians. Spot check around cities and towns - city style addressing sometimes doesn’t follow municipal boundaries. Check the edges of county boundaries to make sure all centerlines are inside.

24. Addressing Meridians Layer Example

25. A quick way of finding meridian lines • Create a sub selection of address points based on prefix directional.

26. Steps • ArctoolboxData Management FeaturesAdd Geometry Attributes • Select your centerlines as the input feature and check LINE_BEARING as the geometry property then click OK. • This adds a directional bearing to each centerline: 0 is due north, 90 due east, 180 due south, 270 due west. • Generally speaking, you can use directional bearing to batch flip lines that are going the wrong direction. For example, if I’m in the NE quad then roads that run N-S should have a bearing range between 340-20. If a line has a range that’s due opposite of that, say 200-160 then its probably a N-S line running the wrong way. If I select all the roads inside the NE quarter polygons then do a sub-selection of those with a bearing between 200-160 then I can flip them all at once using the Flip line tool (Standard License).

27. Steps • For example, for north running roads pointing the wrong direction in both northern quads: selects all lines in the NE and NW quad then use create layer from selected feature and then select by attribute in the sub layer – "BEARING" >= 160 AND "BEARING" <= 200 Open your attribute table and unselect any lines you may have inadvertently picked up with a E-W suffix. Then us the flip line tool and recalculate the bearing of the lines. Just rinse and repeat this process with the remaining centerlines. If you don’t have prefix directional assigned to your centerlines it’s easy to populate this in a different field while you’re sorting the parity issue.

28. Things to keep in mind • There may be exceptions in some parts of the county so the bearing ranges for a directional could be different. For example if streets in a town were laid out based on a railroad that didn’t run N-S or E-W. Take this into account. • It’s worth looking at the selected records inside your attribute table before you do the batch flip. You’ll probably pick up a few roads you don’t want but those are usually easy to identify because they’ll have the wrong suffix directional. • Remember to recalculate bearing after flipping your centerlines. • Because line parity is uniform in each quadrant you can assign most of your parity values after you’ve flipped your lines through a field calculation.

29. A few notes… • While parity should be uniform in each of the quadrants sometimes cities and towns like to muck things up. You’re probably already aware of the problem areas in your jurisdiction. Just keep them in mind. • If you have a lot of unnecessary line segments, for example, 5-6 lines segments along a stretch of road which really only needs one then running a dissolve and a planarize lines may make things a little easier. You’ll need to create a dissolve field first. A fast and dirty way: perform a spatial join with zip code tabulation areas, populate a field with the prefix directional you created, street name and zip code. Don’t worry about spaces. Dissolve using this field. Join your pre-existing centerline dataset to dissolve output and export the dissolve as a new layer. • In the new layer, planarize lines, delete any line segments that are dangles in a batch selection (say lines that are less than 15-20ft in length), and repair geometry. Then do your batch flips. Not only will you have less errors when you do a flip but you’ll have less line segments to review.

30. Towards a Standard • Hancock County is currently collaborating with the Indiana Integrated Public Safety Commission (IPSC) to move Indiana towards a GIS Standard for NG9-1-1. • We’re currently using the IGIC Geospatial Preparedness Committee as a kind of legislative staging area. • We’re in the information gathering phase. Once we’re done gathering information and get feedback from public safety stakeholders we’ll explore next steps before reaching out to legislators to try and get a standard finalized. • Things are currently on hold until a replacement for Megan Compton is selected by the IPSC

31. Additional Info • National 911 Progress Report - https://www.911.gov/project_national911progressreport.html • State of 911 Webinar Series (June 2017 for good GIS case study) – https://www.911.gov/webinars.html • Indiana Integrated Public Safety Commission - https://www.in.gov/ipsc/ • Hancock County 911 - https://www.hancockcoingov.org/hancock-county-government-departments/hancock-county-indiana-e-911-office

32. Questions???