Glossary
GIVE is Geospatial Integration, Validation and Editing. A browser-based, cloud-hosted platform for developing, validating, maintaining, and publishing NG9-1-1 GIS data across local, regional, and state agencies.
GIVE-Verified™ is Gistic’s term for NG9-1-1 GIS data maintained in GIVE that has passed the platform’s validation rules, had identified anomalies resolved in workflow rather than downstream, and aligns to the current NENA GIS data model. It describes the condition of data within GIVE, not an external certification or audit.
GAIN is Geometry, Alias, Inheritance, Names. GIVE’s authoritative domain framework, governing boundaries, place names, street-name components, sanctioned aliases, place-type tagging, and hierarchical containment across state, county, and municipal levels.
PACT is Priority, Anchoring, Collaboration, Topology. GIVE’s resolution methodology, determining what should be corrected first: upstream and authoritative data before dependent data.
A3i is GIVE’s machine-learning street-name parsing engine, which parses each master street name into both the legacy four-field and NG9-1-1 eight-field component structures in a single pass.
Dynamic Fishbone is a visualization and validation tool that calculates where an address point should fall along its road centerline and draws the connector, exposing missing matches, duplicate matches, parity conflicts, and street-name discrepancies.
Legacy Sync is GIVE’s tooling for maintaining alignment between legacy MSAG and ALI records and current road centerline and address point data.
Hub-and-spoke collaborative concept is the model GIVE is built on: local agencies operate as spokes retaining ownership and editing authority, while a regional or statewide environment serves as the hub providing coordinated visibility.
GIVE Location Services is GIVE’s publication layer, connecting managed data to authorized GIS and public-safety systems through WFS, WMS, WMTS, OGC API Features, an OGC Geocoding API, REST and Esri-compatible feature services, vector tiles, GeoJSON, and file geodatabases.
NENA is the National Emergency Number Association. The professional association that publishes the standards NG9-1-1 is built on, including the NG9-1-1 GIS Data Model that defines the required layers, fields, and value registries for 9-1-1 GIS data. NENA also operates the registries that supply many controlled values used in that model.
NG9-1-1 is Next Generation 9-1-1. The IP-based architecture replacing legacy analog 9-1-1. Where the legacy system routed calls using tabular lookups, NG9-1-1 routes on geospatial data: the caller’s location is matched against GIS boundaries to determine which agency receives the call. This makes the accuracy and currency of GIS data an operational requirement rather than a mapping exercise.
MSAG is the Master Street Address Guide. The legacy tabular database of street names, address ranges, and community values used to validate addresses and route calls in the legacy 9-1-1 system. MSAG records must stay aligned with road centerline data throughout the transition to NG9-1-1, which is why discrepancies between the two are a routine maintenance concern.
ALI is Automatic Location Identification. The legacy database that returns a caller’s location to the answering position when a 9-1-1 call arrives. ALI records are tied to telephone service records and must reconcile with both MSAG entries and current address data.
PSAP is the Public Safety Answering Point. The call center that answers 9-1-1 calls for a defined area. In NG9-1-1, the PSAP boundary is a GIS polygon, and its accuracy determines which center receives a call — a misaligned boundary can route a call to the wrong agency.
9-1-1 authority is NENA’s term for the state, county, regional or other governmental entity responsible for 9-1-1 service in an area. Which entity that is varies by state: a county, a city, an Emergency Communications District (ECD), a regional board or a state program. In GIVE materials, county refers to geography; 9-1-1 authority refers to the body responsible for the data.
ECD is an Emergency Communications District. A special-purpose district created under state law to fund and operate 9-1-1 service for a city, a county or a region. ECDs exist in some states but not all, and the name varies. Alabama, for example, has 85 ECDs: one for each of its 67 counties plus 18 municipal districts, including Birmingham’s.
RCL is the Road Centerline. The line layer representing the road network, carrying street name components, address ranges, parity, and zonal values. Road centerlines are the authoritative source for address-to-road relationships; address points inherit the applicable attributes from them.
SSAP is the Site/Structure Address Point. The point layer representing individual addressable locations — a house, a building, a unit. Each point should resolve to a position along its corresponding road centerline consistent with that road’s address range and parity.
ESN is the Emergency Service Number. A legacy code representing a unique combination of law enforcement, fire, and EMS responders for a given area. ESNs pair with MSAG records to determine legacy call routing and remain relevant while legacy and NG9-1-1 systems operate alongside each other.
PRV is the Provisioning Boundary. The polygon defining the geographic extent for which an agency is the authoritative source of NG9-1-1 GIS data. Road centerlines or address points falling outside an agency’s provisioning boundary indicate a data or boundary problem.
ESB is the Emergency Service Boundary. The polygons defining response areas for law enforcement, fire, and EMS. Misalignment between these boundaries and road centerlines can affect several agencies at once.
OGC is the Open Geospatial Consortium. The standards body publishing open specifications for sharing geographic data, including WFS, WMS, WMTS, and OGC API Features — the formats through which NG9-1-1 data is made available to other systems.
Discrepancy report terms
Rule names you will see on state and NGCS validation reports, and the NENA-STA-006.3 fields they check.
Discrepancy Report (DR) is NENA’s term for a notice that a record in an NG9-1-1 GIS layer breaks a rule or conflicts with another dataset. A validation or provisioning report lists these as rows, one rule per row, with a count of the records that fail it. The agency named in DiscrpAgID receives the report and is responsible for resolving it.
Extends Beyond Provisioning Boundary is a report finding that a PSAP, police, fire or EMS boundary polygon is not fully inside the provisioning boundary (the ProvisioningPolygon layer in NENA-STA-006.3). One provisioning boundary drawn slightly inside the county line can produce this finding on every polygon that touches the edge, so the fix usually starts with the provisioning boundary itself.
Gap is a report finding that part of the area inside the provisioning boundary is covered by no polygon of a boundary layer. A caller in a gap has no service boundary and therefore no route. NENA-STA-005 requires the ECRF and LVF to detect gaps.
Overlap is a report finding that an area is covered by two or more polygons of the same boundary layer, so a caller there has more than one route. A gap and an overlap often come from one shared edge digitized twice; snapping the edge once closes both.
Multipart is a report finding that one record’s geometry is made of more than one separate shape, often a sliver left by an old edit or an annexation drawn as a separate piece.
Island is a report finding that a polygon is entirely surrounded by another polygon of the same layer.
Does Not Break at Boundary is a report finding that a road centerline segment crosses a boundary without being split there. Each segment must fall on one side of every boundary, so the fix is to split the segment at the crossing and carry its attributes to both parts. Counts are often large because one rule applies to every crossing.
Digitized Direction is a report finding that a road centerline segment is drawn against the direction of increasing address numbers, so its from and to address values run backwards.
Address Range Overlap is a report finding that two segments of the same street claim the same address numbers in their range fields (FromAddr_L, ToAddr_L, FromAddr_R, ToAddr_R). The location validation function cannot tell which segment an address belongs to.
NGUID is the NENA Globally Unique ID, the primary key every record in an NG9-1-1 GIS layer must carry. In NENA-STA-006.3 the field is named NGUID on every layer, built from a layer code, a local ID and the agency’s domain. Reports flag it when it is blank or when two records share one, because the NGCS rejects or replaces such records.
A1 to A5 are the administrative levels NENA-STA-006.3 uses for place names: A1 state, A2 county, A3 incorporated municipality, A4 unincorporated community, A5 neighborhood. Road centerlines carry left and right versions (A1_L, A1_R and so on). The 2026 standard renamed the earlier state, county and community fields to these levels and removed the state field from service boundary layers, so a report still flagging a state value on every boundary polygon is checking against the earlier 006.2 schema.
DiscrpAgID is the Discrepancy Agency ID, a mandatory field naming the agency that receives discrepancy reports for a record and takes responsibility for resolving them. It is written as the domain name that identifies the agency.
DateUpdate is the mandatory date and time a record was created or last changed. It must be updated whenever the record’s attributes or geometry change.
Service URN is the identifier on a service boundary that tells the ECRF which service the boundary routes, for example urn:emergency:service:sos.psap for a PSAP boundary. The field is named ServiceURN; a blank value leaves the boundary unusable for routing.
Not Reflected in RCL or AP is a report finding that a legacy MSAG range or ALI record has no matching road centerline (RCL) or address point (AP) in the GIS. These findings measure legacy synchronization, which most states still score during the transition to NG9-1-1, commonly against a 98 percent benchmark.
Request
Demo/Trial
Fill out the form below, and we’ll be in touch with you via email shortly.
Request
White Paper
Fill out the form below, and we’ll be in touch with you via email shortly.