It’s been a long time coming - Entering your NextGen Era
As Canada continues to move steadily forward towards fully implementing Next Generation (NG) 9-1-1 and geodetic call routing, 9-1-1 authorities and local government agencies across the country are taking a closer look at the GIS data that they will be required to provision to their 9-1-1 network provider.
The GIS data layers required for NG9-1-1 are well-defined in the NG9-1-1 GIS Data Model Standard (NENA’s version) but lack specific guidance and best practices around managing that data. NENA recently published the much-anticipated Information Document for GIS Data Stewardship for Next Generation 9-1-1. The first version of this document tackled guidance on Public Safety Answering Point (PSAP) boundary considerations. This new version adds guidance for the Road Centerline and Service Boundary layers. If you’re a lover of best practices, then this document should provide you with the guidance you need for the development of current, complete, and accurate GIS data layers to be used inside your 9-1-1 network provider’s NG9-1-1 systems.
For some data authorities, it’s possible that some of your GIS databases and data management processes have not been updated since 1989, or whenever the current E-911 system and it’s Master Street Adress Guide (MSAG) were established. It’s possible that, for a successful NG9-1-1 data management and exchange implementation, many of these processes will need an overhaul.- Are you ready for it?
Don your cardigan and let’s dig into the GIS Data Stewardship guide a little deeper and highlight some of the key elements so that you’re not spending your midnights combing through yet -another document that sits on your desk collecting dusk forevermore.
PSAP Boundary
This polygon layer defines the geographic area where a PSAP has responsibility for emergency call handling and emergency requests within the coverage area of a 9-1-1 authority or local government agency. Within a 9-1-1 network provider’s NG9-1-1 system, the Emergency Call Routing Function (ECRF) functional element uses this boundary to determine where to route a 9-1-1 call. During an NG9-1-1 call, the ECRF is presented with location information (either a civic address or geographic coordinates) and will query this boundary layer to route the call to the appropriate PSAP. Since a geographic location can only have a single designated primary PSAP, it is imperative that data authorities creating this layer must ensure that it covers the full extent of its coverage area, aligns with neighbouring coverage areas, and is free from gaps and overlaps. Creating this layer may cause you to turn red as it requires the cooperation of local and neighbouring data authorities and emergency service providers. In addition to the topological concerns, this polygon layer must also contain specific attributes that are new to NG9-1-1: the Service URN and the Service URI. The Service URN (Uniform Resource Name) for the PSAP boundary must always be presented and follow a strict naming schema that looks similar to urn:emergency:service:sos:psap. This Service URN is used to select a specific service (in this case a PSAP) in emergency call routing. The ECRF uses a combination of the Service URN and location to determine a Service URI. The Service URI (Uniform Resource Identifier) defines the route to the selected service (in this case, the PSAP in the Town of Lavender Haze agency). It follows a strict syntax and is typically also a SIP(s) (Session Initiation Protocol) URI such as sip:sos.psap@TownOfLavenderHaze.ts.
Service Boundaries
These polygon layers define the geographic extents of specific response services. While it includes layers representing the primary emergency services of Police, Fire, and EMS, the advice in this section can also be used to define other services such as Coast Guard, Municipal Enforcement, and Poison Control. These boundaries are used by PSAPs to identify which first responders need to be dispatched for a specific location. The ECRF uses these layers to perform a geographic query (point-in-polygon) to determine the responsible agencies for a location. As well, in the case of a selective transfer, these boundaries are used to direct an Emergency Incident Data Object (EIDO) to an agency for the dispatch of the appropriate resources. Like the PSAP boundary, these service boundaries must also contain a Service URN (e.g., urn:emergency:service:responder.fire) and Service URI (e.g., sip:folklore‑fire@TownOfLavenderHaze.ts). These service boundaries should not have any unintentional gaps or overlaps with neighbouring agencies of the same service type. If a call location occurs in an area with a gap, the ECRF will not be able to use these boundaries to determine which agency should be dispatched for this call. Likewise, in the event of an overlap, the ECRF will struggle to correctly determine which agency of the offending overlaps should receive those calls.
Other Boundary Advice
In addition to the specific advice mentioned above, it’s also important to note there are other factors that should be considered when building these polygon datasets. For example, these boundaries may not always follow jurisdictional boundaries. While a legal government boundary may be disputed by neighbouring agencies, a service boundary can be more informal and based on how neighbouring agencies decide to best handle call routing scenarios (e.g., neighbouring municipalities may have a reputation for disputing where their legal limit occurs but can mutually agree on where to define fire department boundaries based on response times). Along a similar vein, service boundaries do not need to be restricted to a coastline. Areas along the coast or other major waterway should consider extending their boundaries to cover all waterbodies which an agency could be expected to receive a call, particularly a wireless caller, even if that call will be transferred to a Coast Guard agency for dispatch.
Phased Approach
For those data providers who may be starting from scratch, the GIS Data Stewardship guide offers a phased approach to make your whole dataset shimmer. The first, or initial development, phase focuses on the, often iterative, process of acquiring and developing the initial layers. It recommends creating a draft of potential boundaries by coordinating with your local PSAP and response agencies. It also recommends only focusing on basic attribution of these layers, such as the agency display name and Service URN.
The second phase, or modification and refining phase, is where a lot of the finer details emerge from your response agency collaboration occurs, and it can feel like you’re moving boundary edges a million little times. This phase is also when you should consider synchronizing your data to any existing MSAG or ESZ (Emergency Service Zone) data that may also exist for your area. MSAG alignment is an important element in an agency’s NG9-1-1 transition and NENA recommends a match of 98% or higher, so time spent in this phase will never go out of style. It should also be noted that this phase may continue beyond this phase, into the final phase, and even into long-term maintenance, so consider establishing processes to optimize boundary refinement. In the final, or NG9-1-1 readiness, phase the end goal is to have service boundaries that can support NG9-1-1 call routing. This will mean the development of the remaining required NG attributes and will likely require the support of the data provider, 9-1-1 authority or local government agency, and the 9-1-1 network provider. This phase is critical to ensure that these boundaries can support both location validation and emergency call routing.
Road Centerlines
As the name implies, the line features in this dataset represent the centre of a road, thoroughfare, or accessway. These features also contain several attributes to enable the locating of a civic address somewhere along its length through a geocoding process. While this dataset is commonly used for other public safety uses (e.g., Computer Aided Dispatch maps, vehicle routing, etc.), it is also used by the Location Validation Function (LVF) and ECRF functional elements in an NG9-1-1 system to validate a location or to route an emergency call to an appropriate PSAP or dispatch agency. As this dataset typically supports numerous functions inside a data provider’s organization beyond NG9-1-1 call routing, careful consideration should be taken to ensure that the dataset is constructed in such a way that it can support NG9-1-1, or a data export routine must be developed so that the dataset can be properly provisioned to a 9-1-1 network provider. While there are several attributes required for this layer, a set of attributes that should be ready for combat is the civic address ranges. When no civic address points are available, these ranges will be used by the ECRF and LVF to geocode the location of a civic address. There are several address range styles (potential address ranges, hundred-block address ranges, interval-based address ranges, actual address ranges), each has its own merits. However, it’s crucial to ensure that the addressing style within your organization is consistent and, at the very least, free from gaps and overlaps between centerlines. Additionally, when constructing your road centerline layer, it’s important to note that the NG9-1-1 system requires road name elements to be fully parsed and spelled out in full (i.e., no abbreviations). This would mean that if your dataset today has Speak Now ST in a “Street Name” field, in NG9-1-1 Speak Now would remain in the “Street Name” field and the ST suffix must be parsed into a new “Street Type Suffix” field and fully spelled out as Street. Aligning with neighbouring jurisdictions continues to be important in this dataset and neighbouring jurisdictions should agree on tie-to/stitch points for roads that cross boundaries. Further guidance can be found in this section that cover topics such as cul-de-sacs, splitting roads at boundaries (which is critical when a centerline passes over any administrative level boundary like municipality or county/region), representing multi-lane intersections, multi-level roadways and stacked geometries.
Phased Approach
Like the service boundaries, the road centerlines dataset can also be constructed in a phased approach. While the phases – creation, modification, NG9-1-1 ready – remain the same, some of the steps within those phases are different.
In the first (creation) phase, it is possible that road centerline data may already exist at the provincial or federal level that can serve as a benchmark to construct your local dataset.
In the second (modification/refinement) phase, existing MSAG or address datasets can be leveraged as comparisons to ensure the completeness and accuracy of your dataset.
During the final (NG9-1-1 ready) phase, you can assign the final attributes required for emergency call routing. This can include new “Validation Left” and “Validation Right” fields. These fields are a new concept that does not exist in the current E-911 system and will instruct the LVF to ignore those records coded as N from location validation.
Regardless of where a data authority may be on their NG9-1-1 data transition journey, the GIS Data Stewardship document is a worthwhile read. It should not be understated how long it may take to ensure your data is NG9-1-1 ready and that some data changes may take longer than others, especially if relying on guidance from neighbouring agencies. With the implementation of geodetic call routing in Canada expected to start in 2025 and be fully operational by 2027 it’s never too early to start preparing your NG9-1-1 data and maintenance processes. Regardless of timelines, current, complete, and accurate GIS data never goes out of style, and these changes will help ensure more efficient emergency call routing by your 9-1-1 network provider and more accurate agency response from PSAP dispatchers.
If you need help, there are a number of resources at your disposal. The NG9-1-1 GIS Validator is free online service that compares and scores your data to the NENA Standard for NG9-1-1 GIS Data Model. Much like NG9-1-1 data readiness is an iterative process, this service can be used repeatedly until your data is NG9-1-1 compliant and ready for national rollout of geodetic call routing.
Still have questions, comments, or concerns? We’re here and to help your organization be ready for your NG9-1-1 data transition! Reach out today and our fearless NG9-1-1 team would love to partner with you for success (no friendship bracelet required).