Third Version’s the Charm: NG9-1-1 GIS Data Model FAQ
The third version of the NG9-1-1 GIS Data Model standard has been published! It has undergone considerable changes, with special attention given to addressing Canadian concerns and considerations. It will be used to support the implementation of geospatial call routing in Canada, and will impact 9-1-1 authorities, local governments, and the GIS data providers and aggregators that support them in their efforts to prepare NG9-1-1-compliant GIS data. The following is a list of Frequently Asked Questions about this new version and its impact on key participants in Canada.
What is the GIS Data Model?
The GIS Data Model is the common abbreviated name of NENA-STA-006.3-2026, the NENA Standard for NG9-1-1 GIS Data Model. It defines the Geographic Information System (GIS) data structure, requirements, and related components used in Next Generation 9-1-1 (NG9-1-1 Core Services (NGCS). It defines the GIS data layers that are used to support NGCS functionality such as emergency call routing and location validation, and are commonly needed by the Public Safety Answering Point (PSAP) applications for call handling, dispatch operations, and other related functions and solutions.
The GIS Data Model standard can be accessed here: www.nena.org/resource/resmgr/standards/nena-sta-006.3_ng9-1-1_gis_d.pdf
Who is NENA?
NENA (the National Emergency Number Association) is a professional organization focused on 9-1-1 operations, technology, education, and policy issues for North America. They do this work through standards development, training, accreditation, and thought leadership through its network of 9-1-1 industry experts and emergency communications professionals. NENA publishes many of the NG9-1-1-related standards that have been adopted for use in Canada.
Why do we need a GIS Data Model?
GIS data is the fuel that drives NG9-1-1. The points, lines, and polygons defined in the GIS Data Model represent common public safety features like civic addresses, thoroughfares, and emergency response zones, and support several key pieces of functionality within NG9-1-1 systems. This includes:
- Emergency Call Routing via the Emergency Call Routing Function (ECRF)
- Location Validation via the Location Validation Function (LVF)
- GeoCode Service (GCS)
- MSAG Conversion Service (MCS)
- Mapping Data Service (MDS)
The GIS data that is provisioned to NG9-1-1 will determine critical information such as:
- Which PSAP should an emergency call be routed to?
- Is a civic location (e.g., address information, site description, etc.) valid?
- Which emergency services and/or agencies are available at a civic location?
Without a common defined data structure, the use and reliability of NG9-1-1’s functions and interfaces would be compromised. These functions and interfaces are designed to be interoperable both nationally and internationally.
The detailed functional and interface design specifications, along with the overall architecture of NG9-1-1 systems infrastructure, are defined in the NENA-STA-010.3f-2021, the NENA i3 Standard for Next Generation 9-1-1.
More information about the NENA i3 standard
Additional information on NG9-1-1 GIS data layer usage can be found in Section 1 of the GIS Data Model standard.
How does the GIS Data Model differ from CLDXF-CA?
These two standards are related but serve different purposes. The GIS Data Model defines the GIS data layers which must be provisioned into NGCS to support NG9-1-1 services, while the Canadian Civic Location Data Exchange Format Standard (CLDXF-CA) defines how civic location information (known as location objects) must be structured for use within NG9-1-1 systems.
The GIS Data Model conforms to the CLDXF-CA representation of civic location information in Canadian NG9-1-1 systems, but has additional fields that provide information beyond what is represented in CLDXF-CA.
GIS data providers must understand both standards. The GIS Data Model specifies the structure of many GIS data layer attributes; however, the inclusion of an attribute may be controlled by business rules defined in the CLDXF-CA.
The GIS Data Model defines a SiteStructureAddressPoint layer to store civic location features and their associated addressing information. This layer has an A2 attribute used to store the Administrative Level 2 data value. While the GIS Data Model standard specifies whether a field is required or not, this feature has a specification of Conditional, indicating that this attribute is controlled by the CLDXF-CA and that the business rules defined in the CLDXF-CA must be followed.
For example, in the case of New Brunswick, CLDXF-CA states that this field is required, that A2 is the primary administrative subdivision, and will be the County value. In the case of Manitoba, CLDXF-CA states that A2 is not required, and that no values currently exist.
The CLDXF-CA standard can be accessed here: www.nena.org/resource/resmgr/standards/NENA-STA-029.1-2025_CLDXF-CA.pdf
What has changed since the last version?
Several factors have influenced the considerable changes found in version 3 of the GIS Data Model, including:
- Better alignment with the NENA i3 standard
- Includes incorporating a relational model formerly known as “Appendix B” in the i3 standard
- Enhancing clarity and use of various layers and fields
- Includes splitting distance markers and location markers into separate layers
- Considerations arising from CLDXF-US (v2) and CLDXF-CA working groups
- Includes aligning the “Required” classification of CLDXF-controlled fields
- Considerations arising from the 3D Requirements working group
- Includes the creation of the new SiteStructureAddressPolygon layer
More information on specific structural changes can be found in Appendix F of the GIS Data Model standard.
What happened to the Street Name Alias table?
Previous versions of the GIS Data Model defined a Street Name Alias table for storing street name alias information, however, that table has been removed in version 3.
Roadways and thoroughfares are often known and referenced by more than one name. This can be due to a myriad of reasons, including when:
- they cross jurisdictional boundaries,
- honorific or memorial names are assigned, and
- legacy names have persisted after an amalgamation or re-naming.
Street name alias information is certainly important, and consideration should be given to including it. However, only the authoritative name must be the value stored in the Street Name field of the RoadCenterLine layer.
Alias information is still supported in the GIS Data Model and is permitted in NG9-1-1 systems. This information can now be stored using any methodology, including the methodology from the previous GIS Data Model version, but it must be exported and provisioned to NG9-1-1 in a way that is compatible with the applicable defined structures.
More information about the structure of Street Name Alias information can be found in Section 4.1.2 and Appendix E of the GIS Data Model.
How does the GIS Data Model affect GIS data providers?
GIS data providers have a critical role in supporting public safety services for their area and this includes supporting the NG9-1-1 GIS Data Model and CLDXF-CA requirements. GIS data providers should expect both short-term and long-term impacts on their operations and will need to be ready to support this critical role technologically, financially, and with an appropriate level of governance and personnel.
More guidance on GIS data provider impacts from Canada’s Emergency Services Working Group (ESWG) can be found here: https://crtc.gc.ca/public/cisc/es/ESCO0801.pdf
How does the GIS Data Model affect others?
Supporting the GIS Data Model will have ripple effects across the public safety ecosystem. This includes:
- 9-1-1 Authorities that organize 9-1-1 services for their jurisdiction,
- Public Safety Answering Points (PSAPs) that answer 9-1-1 calls,
- Originating Network Providers (ONPs) that provide telephone services, and
- NG9-1-1 network providers that provide the core NG9-1-1 network and call routing services.
All organizations that create, manage, or use NG9-1-1 GIS data will be impacted by the GIS Data Model. For example, an ONP who is establishing landline telephone service for a new customer will need to provide that customer’s connection and civic location information to a NG9-1-1 network provider, where it will be validated against GIS data supplied by a 9-1-1 authority (or a GIS data provider and/or GIS data aggregator working on their behalf), and then stored in the NG9-1-1 network provider’s system.
More guidance on key partner impacts can be found from the ESWG here: https://crtc.gc.ca/public/cisc/es/ESCO0759.pdf
When will the GIS Data Model be adopted in Canada?
The new version of the GIS Data Model standard is now published and live. The Emergency Services Working Group (ESWG) previously submitted a formal recommendation to the Canadian Radio-television and Telecommunications Commission (CRTC) for its adoption and implementation across Canada’s NG9-1-1 ecosystem. The CRTC, as Canada’s telecom regulator, approved the recommendation and mandated the GIS Data Model’s adoption as the baseline standard for NG9-1-1 GIS services in Canada as part of Telecom Decision CRTC 2025-64.
Telecom Decision CRTC 2025-64, and its supporting documents
What about my existing GIS solutions?
The GIS Data Model defines the minimum GIS requirements to support standardized functionality in NG9-1-1 systems. Additional considerations may be established based on requirements from NG9-1-1 network providers and/or from additional local operations of an organization. Existing GIS data management solutions and workflows will likely need to be evaluated and enhanced to support the use cases and common structure required for NG9-1-1 services.
Organizations with commercial solutions should consult with their vendors to determine the processes, costs, and timelines required to adapt existing solutions to manage the structures defined in the GIS Data Model.
For organizations that are leveraging Esri Canada’s Public Safety GeoXchange® (PSGX) and/or NG9-1-1 Data Manager, these solutions have gone through a similar analysis. Additionally, these solutions have established a product lifecycle roadmap, which includes updates and enhancements to support new versions of the GIS Data Model and requirements established by NG9-1-1 network providers in Canada.
More information about Esri Canada’s solutions to support NG9-1-1
What about my CAD? Or my CHS? Or my RMS?
GIS data has many public safety-related use cases, including use within common PSAP applications such as a Call Handling System (CHS), Computer-Aided Dispatch (CAD), and a Records Management System (RMS). These solutions can leverage GIS data but often require the data to be augmented with additional attribute considerations (e.g., CAD may require turn restrictions and road median information to route specific fire trucks). It is also very common that GIS data is transformed into different, often proprietary formats to support PSAP operations. The long-term vision of the GIS Data Model is to include these considerations. This vision would allow organizations to have a single, interoperable, structure that can be used for NGCS operations (e.g., emergency call routing) and for PSAP operations (e.g., responder routing).
Organizations should consult with their PSAP solutions vendors to obtain any additional considerations and requirements which may be needed for their GIS data, and to ensure that their solutions can support NG9-1-1-compliant GIS data.
Do I have to start from scratch?
Not necessarily. It is possible that your existing GIS data structures already support what is specified in the GIS Data Model, or that field names and attributes can be modified without modifying existing workflows and processes. A gap analysis should be taken to compare what is required to create and manage NG9-1-1-compliant GIS data and what already exists within your jurisdiction.
Are there additional resources available?
Available in a GitHub repository, NENA has published additional resources including database scripts and templates. These resources were created to provide a common data structure for data exchanges between agencies and vendors, and to prevent interpretation errors for those using the GIS Data Model. While the resources are available to be used by any organization, care should be taken to ensure that the output aligns with the specific needs and requirements of that organization and of their NG9-1-1 network provider. Additionally, certain database values, such as domains, must be maintained by the organization as values may be specific to them (e.g., Additional Code) or expand with new values over time (e.g., Street Name Post Type).
Where can I find more information?
Several contributions related to best practices for preparing, maintaining, and consuming GIS data for NG9-1-1, including additional information about the CLDXF-CA standard have been created and shared with the ESWG. Many of these have been summarized into a single contribution which provides high-level summary information, organized by both the relevant NG9-1-1 migration phase and NG9-1-1 participant role.
This contribution from the ESWG can be found here: https://crtc.gc.ca/public/cisc/es/ESCO0784.pdf
Is this the final version of the GIS Data Model?
No. This version is expected to be stable for a period to allow industry and implementers time to “catch-up”. The transition to NG9-1-1 is an evolution, and as it evolves, or new demands are placed upon it, the GIS data and model that supports that data must evolve with it. This evolution could include considerations of other standards, information guides, and/or requirements documents published by other working groups.
The next scheduled review date of the GIS Data Model document is in 2029. It is possible, however, that as other working groups complete their work, some immediate adjustments may become necessary. NENA has allowances for this in its standards development process, and should it be required, a working group can be established prior to 2029 to make amendments to the current version of the standard or to create an updated version.
More information about the NENA Development Group process can be found here: www.nena.org/resource/resmgr/standards/nena-adm-001.5b-2022_final_2.pdf