Beyond Attribute Tables: A Better Way to Validate Road Address Continuity

Roads with mismatched Ranges between segments

If you work with road centerline data, you’ve probably stared at an attribute table full of address ranges and wondered: is any of this actually right?

From Left, To Left, From Right, To Right. Four fields per segment. Multiply that by thousands of road segments across a county, and you’ve got a dataset that’s nearly impossible to validate by eye. And for NG911 — Next Generation 911, the standard that emergency dispatch systems run on — that data needs to be correct. Not mostly correct. Correct.

When it isn’t, the consequences are real. A reversed address range means geocoding puts an address at the wrong end of a street. A gap in the sequence means some addresses don’t exist in the routing data at all. An ambulance following bad routing data loses time it doesn’t have.

This is a data quality problem, and like most data quality problems, it’s unglamorous, tedious, and extremely important.

What address range data actually is

Before getting into the tool, a quick primer if this data model is new to you.

In a road centerline dataset, each road segment — the stretch of road between two intersections — stores the range of address numbers that fall along it. That range is split by side of the road: left and right, as you travel in the direction the segment was digitized.

A typical residential block might look like this:

From Left:  101    To Left:  199
From Right: 102    To Right: 200

Odd numbers on one side, even on the other. The ranges run in the same direction as the segment geometry. When you string several connected segments together along the same street, the numbers should flow continuously — segment one ends at 200, segment two picks up at 201, no gaps, no jumps, no duplicates.

That’s the model. In practice, this data gets built and edited by many different people over many years, and errors accumulate. A range gets entered backwards. Someone types 1000 instead of 100. A segment gets re-digitized in the opposite direction and nobody updates the address fields. Two segments that should connect end up with a gap of a dozen address numbers between them.

Finding these errors manually is painful. That’s where data quality tools come in.

Introducing RoadRanger

RoadRanger is a free, open source data quality tool for ArcGIS Pro that validates road address range data against NG911 standards. You point it at your road layer, tell it which fields are which, and it produces a new feature class containing every segment where something looks wrong — with a plain-English description of the problem on each one.

It runs entirely inside ArcGIS Pro. No extra software, no Python setup, no licensing costs beyond what you already have.

Here’s what it checks.

Per-segment checks: catching data entry errors

The first category of checks looks at each segment in isolation. These are the classic data entry mistakes.

Reversed ranges. If the From value is higher than the To value, the range is running backwards relative to the segment direction. This is one of the most common errors and one of the easiest to miss in a table view.

Both sides the same parity. Left and right sides of a road should carry opposite parities — one odd, one even. If both sides are odd, or both are even, something went wrong. Either the values were entered in the wrong fields, or the data was copied from somewhere incorrectly.

Mixed parity within a side. A range like 101–200 on the left side spans both odd and even numbers, which means it’s likely crossing an intersection it shouldn’t be. Each side of a segment should be consistently odd or consistently even.

Single-number ranges. A segment where From and To are the same number covers exactly one address. Almost always a data entry error.

Null or unparseable values. Empty fields, non-numeric text where numbers should be — anything that can’t be read as an address number gets flagged.

Non-consecutive start or end numbers. Within a single segment, the left and right start numbers should differ by exactly 1 (e.g. 101 and 102). Same for the end numbers. If they differ by more, there’s a mismatch within the segment itself.

Cross-segment checks: catching continuity errors

The second category is where it gets more interesting. These checks look at pairs of connected segments on the same street and ask: does the address sequence flow correctly from one to the next?

To do this, RoadRanger groups segments by street name, then chains them together spatially — walking from one segment endpoint to the next nearest one, within a configurable distance tolerance. Once it has that chain, it checks each connected pair.

Gaps. If segment A ends at address 200 and segment B starts at address 203, addresses 201 and 202 are missing from the dataset. Anyone with an address in that range won’t geocode to anything. The tool flags this and tells you exactly which addresses are missing.

Overlaps. If segment B starts at 198 when segment A already ended at 200, some addresses exist on two segments at once. Geocoding becomes ambiguous.

Side switches. This one is subtle. If the odd and even sides silently swap between two connected segments — left was odd, now left is even — you likely have a digitizing direction issue. The numbers might look continuous but the left/right assignment is wrong, which means address points will be matched to the wrong side of the street.

Parity changes at the boundary. Similar to a side switch but caught by checking whether the parity of each side stays consistent as you move along a street.

What the output looks like

The tool produces a polyline feature class — the flagged road segments, shown in place on your map — with these attribute fields:

Field What it tells you StreetName The street name from your data IssueCount How many problems were found on this segment Issues Plain-English description of each problem, separated by semicolons FromLeft / ToLeft / FromRight / ToRight The actual values, so you can see the problem immediately

A segment with a gap might read:

Issues: GAP: address(es) 201-203 missing between OID 1042 (ends 200) and OID 1043 (starts 204)

You can open the output layer, sort by IssueCount to find the worst offenders, and work through corrections in the editor. No hunting through tables, no manual cross-referencing between segments.

How to get it running

RoadRanger is an ArcGIS Pro Python Toolbox — a standard format for custom geoprocessing tools that plugs right into the interface.

1. Download RoadRanger.pyt from the GitHub repository
2. In ArcGIS Pro, open the Catalog pane and navigate to the folder where you saved it
3. Expand the toolbox — the RoadRanger tool will appear inside, just like any built-in tool
4. Open the tool and fill in the parameters:

• Your road segment layer
• The street name field
• Your four address range fields (From Left, To Left, From Right, To Right)
• An output file geodatabase
• A name for the output layer
• A connection tolerance in meters (default 10m — how close two endpoints need to be to count as connected)

5. Run it

The output is added to your active map automatically. The tool messages panel prints a full summary breakdown by issue category when it finishes.

A note on what it doesn’t do

RoadRanger checks attribute data. It doesn’t validate geometry, check network topology for dangles or gaps, or compare your data against a reference dataset. It won’t tell you if a road segment is missing entirely — only that the segments present have address range problems.

It also uses a simplified spatial chain to connect segments. For most streets this works well. At complex intersections or on streets with unusual digitizing, the tool skips uncertain cross-segment checks rather than produce a false positive. Better to miss a potential edge case than flag correct data as broken.

Why this matters for NG911

NG911 standards require address range data to support accurate geocoding for emergency call routing. NENA — the National Emergency Number Association — publishes detailed data model specifications for this, and address range completeness and continuity are core requirements.

Most GIS teams working on NG911 know what good data looks like. The hard part is finding where existing data falls short, particularly in large datasets built up over years from multiple sources and editors.

Running a data quality check like this before a submission or after a major edit session catches the kind of errors that are invisible in a table but very visible to a dispatcher trying to route a call.

Get the tool

RoadRanger is free and open source under the MIT license. Find it on GitHub A-Charvin/RoadRanger-QA-911. Issues, feedback, and contributions are welcome.

If your data model doesn’t quite fit — one-sided ranges, different field naming conventions, address ranges stored in a non-standard way — open an issue. The goal is a tool that works for how road data actually exists in the wild, not just how it looks in a spec document.