NG9-1-1 GIS validation
Groundtruth
Validation Workbench
A data check is the beginning of the work.
The Workbench checks local NG9-1-1 GIS data through an ArcGIS Pro toolbox. It calls each reported anomaly or condition a finding, linked to the affected source record. You can examine it, record your decision, and return to that reasoning when the condition appears again.
In development
Follow one issue through review.
FICTIONAL RECORD / SAMPLE-0147
- Check severity
- Advisory
- Human review
- Unreviewed
- History
- New finding
The check reports Advisory. A person has not reviewed this finding yet.
From source data to an inspectable result
Your data.
A review you can return to.
Start with local GIS data. Inspect what the checks found. Keep the result and the human explanation together, ready for the next review.
Local GIS data
Field mappings require confirmation. Source data is read, with new outputs written separately.
Validation Workbench
See the reported condition, the record it concerns, and the context needed to review it.
No external AI service, telemetry, or cloud processing in the current runtime.
Take the review with you
Confirm the mapping.
A suggested field match becomes authoritative only after a person confirms it. New or renamed fields require review.
Keep the finding.
Empty, invalid, or ambiguous geometry can prevent a spatial attachment. The report keeps the finding and explains why it could not be mapped.
Carry the review forward.
Review status, reasons, and earlier decisions stay available alongside the finding. The next person can see what was considered and why.
The tool advises. The human decides.
What the check found.
What you decided.
A check identifies a condition that needs attention. Local knowledge helps determine what to do about it. Severity records the check’s assessment; review status records where the human review stands. Marking something Reviewed preserves the original assessment and the review history.
Sometimes there is a documented reason to handle a recurring condition as an exception. The Workbench calls that an Approved Local Convention: explicit approval for an exact value, field, layer, and rule. A matching finding can leave the active queue, the list needing attention, while the finding and rationale remain available.
An approved local convention
After review
The queue changes.
The history stays useful.
The current list of items needing attention and the record of what happened serve different purposes. The Workbench keeps them distinct.
Follow the source.
Findings reference the source record’s identifier. Results and review history are stored separately, so you can trace an issue back to the data without adding it to or rewriting the source dataset.
Revisit the decision.
The record retains the check’s result, the review status, and the recorded reason. An approved local convention can change what needs attention without deleting the underlying finding.
Check again with context.
If the condition appears on a later run, it starts Unreviewed with the earlier review linked as history. An exact Approved Local Convention can keep that occurrence out of the active queue. Earlier saved results remain a record of what was found.
What the checks examine
The Workbench looks within individual records and across the layers that need to agree. These are examples of the conditions its check families examine.
Schema
Missing required fields, values that exceed field lengths, and required fields dominated by null or blank values. This separates structural problems from problems inside a record.
Domains
Values outside the applicable code lists, including state abbreviations, directionals, street types, parity, one-way codes, and service identifiers.
Attributes
Invalid or duplicate NGUIDs, reversed address ranges, parity conflicts, inconsistent dates, and coordinate attributes that disagree with feature geometry.
Topology
Disconnected road endpoints, duplicate or self-intersecting segments, and service-boundary overlaps or seam gaps. Placement checks also compare address points with their named roads.
Cross-layer relationships
Address points without matching centerlines, numbers outside matching ranges, and points outside PSAP or law, fire, or EMS boundaries. Community and municipality comparisons expose disagreements between layers.
Fishbone analysis
Lines connect address points to their range-based positions along matching roads. Missing or multiple matches, wrong-side placement, long connections, and inconsistent address order give reviewers specific relationships to inspect.
MSAG comparisons
With a supplied Master Street Address Guide, checks examine required values, range order, parity, ESN format, overlapping entries, and agreement with centerline names, ranges, and communities.
ALI comparisons
With supplied Automatic Location Identification records, checks look for matching address points, centerline range coverage, missing required values, and community mismatches.
How severity and workflow are kept separate
Severity uses Critical, Advisory, Watch, and N/A. Human review uses Unreviewed, Active, Flagged, and Reviewed, with a recorded reason for a decision. Reviewed means a person has made a review decision; it does not automatically mean the data was changed or the condition was fixed.
An Approved Local Convention records a narrowly scoped exception for review. It does not change an external standard. Recognition can change the active queue while preserving the finding, its original severity, and the reason it matched.
This is the work I want to move forward.
The Workbench is Groundtruth’s main technical development priority. Support would create focused engineering time and make paid technical review possible. A useful conversation can start with a capability, a technical question, or a bounded development scope.
A question is enough to begin. Start with a general description or public reference; there is no need to send operational datasets.
For a tool available now, explore the free public-beta Groundtruth Schema Bridge. It helps move data between NENA schema versions.