Data
Address data is the hardest data a local government owns
Addresses disagree across permitting, assessment, billing, and dispatch, and reconciling them takes an address layer with a named owner.
Every local government system stores addresses. Permitting, assessment, utility billing, dispatch, and code enforcement each hold a copy, and the copies do not agree. Ask each department how many addressable locations exist in the jurisdiction and you get different answers, each defensible on its own terms.
Address data looks like the easiest data an agency owns: short, familiar, readable by anyone. It is the hardest, for three reasons. An address is not one thing, the authority to create one is spread across departments, and most systems do not record where a value came from or when it changed.
An address is several different things
The word covers several distinct objects:
- The legal or situs address assigned by an addressing authority under local ordinance
- The postal delivery point, which the Postal Service maintains under its own standards
- The parcel address in assessment records, tied to a property boundary rather than a building
- The site or structure address used for emergency response, which must identify a place a responder can reach
- The mailing address of an owner or account holder, often in another jurisdiction
- The unit or occupancy address inside a building, which often exists in no system until someone complains
These do not have to agree, and usually do not. One parcel can hold several structures, and one structure can hold many separately occupied units. ZIP Codes describe postal delivery routes rather than jurisdictional boundaries, so a ZIP Code is a weak basis for deciding what lies inside a service area.
Why the copies disagree
The divergence follows from how the records are created.
- Different moments. Permitting records an address at plan submittal, assessment when a parcel is created, the utility at service connection. The same location is addressed several times over its life, by different people.
- Different formats. One system stores 123 N Main St Apt 4, another 123 North Main Street #4, a third splits the parts into columns with its own abbreviations.
- No shared key. Most systems match on address text, so a punctuation change produces what looks like a new location.
- Change in the real world. Annexations, street renames, renumbering, subdivisions, and demolitions reach systems unevenly, and some never hear of them.
- Nothing is retired. Addresses that stopped existing stay active in systems with no lifecycle concept.
What an authoritative address layer requires
It is not a cleanup project that ends but a system of record with specific properties.
A persistent identifier. One identifier per address that does not change, is not reused, and is carried by every downstream system. Without it, reconciliation starts over from text every time.
Atomic components. Store number, prefix, street name, street type, unit type, and unit value in separate fields alongside the assembled form. The United States Thoroughfare, Landmark, and Postal Address Data Standard, approved by the Federal Geographic Data Committee, defines those components and the tests used to check them. It is a better starting point than a schema invented locally.
Documented geometry. A point placed by a stated rule, whether the structure, the entrance, or the parcel centroid, with the rule recorded rather than assumed.
Lifecycle status and dates. Proposed, assigned, active, and retired are different states. History is preserved rather than overwritten, because records elsewhere still point at the old value.
Relationships. Links to the parcel, the road centerline, service and response boundaries, and child unit addresses.
Provenance. For each value, which source asserted it and when. This is the field most often skipped and the one that settles disputes.
A named authority. One office, named in writing, that assigns addresses and runs the request workflow. Scattered authority produces most of the other problems on this list.
Matching is a system, not a one-time script
Reconciling existing sources against the layer is continuing work. In our own reference builds we normalize both sides, match deterministically on identifiers and exact strings, score the remainder as candidates, and send ambiguous cases to a review queue rather than letting software guess. Match decisions are stored, so the same pair is not resolved differently next quarter. Unmatched records go back to the department that owns them. Nothing is written silently into a source system.
Maintenance, not remediation
The layer is accurate on the day it is published and decays from there unless change flows through it. That requires validation rules that run continuously, a publishing path other systems can subscribe to through an API or an extract, and a request workflow that planning, building, and public works actually use.
Public safety raises the stakes. Next Generation 911 routes calls using geospatial data rather than tabular lookup tables, so address points and response boundaries must be current and must agree with neighboring jurisdictions at shared borders. The National Emergency Number Association publishes a GIS data model that defines those layers.
What to do next
Name the addressing authority in writing and give it a request workflow. Budget for maintenance, not remediation alone, because a cleanup with no workflow behind it goes stale. Put the address identifier into procurement language, so any new system stores it, returns it, and exposes it through an API. Start with a reconciliation report that compares your major sources and counts where they disagree. That report turns a complaint about data quality into a countable problem a budget committee can act on.