When an Address Has to Become a Point

By Sandi C. Stroud, ENP · Published October 18, 2026 · Updated October 19, 2026

Key takeaways

• A civic address routes only when it matches something. The LVF and ECRF look for one site/structure address point first, then fall back to one road centerline segment whose range holds the address.
• Validation is stricter than routing. An address whose house number doesn't match any address point, but falls within a road centerline's range, still gets a route. Whether it also validates depends on how you built the data. Validation asks whether a responder could find the place; routing only asks where to send the call.
• Placeable means conformant, unique and inside the right line. The address has to match one and only one record in the GIS data, in the standard structure, sitting in or on the right PSAP boundary.

A landline rings into 911 from 412 Oak Street. There's no latitude and no longitude, only an address. Before the call can route through NGCS, that address has to turn into something the GIS can place: a point, or a spot on a road segment, inside a PSAP boundary.

In Part 2, the PSAP boundary went first because coordinate calls need nothing else. Civic-address calls are what come next. They stay on ALI/MSAG or transitional LDB routing until your address points and road centerlines can place them. This part is about what "can place them" actually means.

Two kinds of location

Every 911 call reaches NGCS with one of two kinds of location, and they lean on different GIS data.

• A coordinate (latitude and longitude, or x/y). Most wireless calls carry one. The ECRF only needs the PSAP boundary to route it.
• A civic address (house number, street, community). Wireline, many VoIP and MLTS (multi-line telephone system) calls carry one. Fixed-device calls are the core of this group.

A civic address isn't a place on a map until something matches it. That's the job of your address points and road centerlines, and it's why they become routing-critical wherever civic calls arrive.

The address itself comes from a record the 911 Authority's GIS doesn't hold: a location database (LDB) the 911 Authority pays for and the originating service provider (OSP) updates with new service orders for phones, or a location information server (LIS) owned by the originating service provider. Who Owns the LIS? covers that side. This post is about the 911 Authority's side: whether your GIS can place the address when it arrives.

How the LVF and ECRF use civic data

Two functional elements read your address data, at two different moments (Four Boxes, One Map walks through both).

Before the call, the LVF validates. When an address goes into a LIS or LDB as a new customer record, with the location of the customer's new fixed device, it's supposed to be validated against the location validation function (LVF), which checks it against your provisioned GIS. It searches in a set order: site/structure address points first, then road centerlines only if no single address point matches (NENA-INF-027.1, section 2.5.4).

In order for the LVF to produce a "valid" result, every element in the address has to match the record, and match one and only one record in the GIS data (section 2.5.2). So a house number that misses every address point but falls in a road centerline's range validates on the range, unless that segment's Validation Left or Right is set to "N". When the match lands on a road centerline instead of an address point, the i3 standard lets the LVF and ECRF flag it as a degraded match: the address was placed, but not with the best data available (NENA-STA-010.3, section 3.4.10.2).

LVF-valid and routing-valid aren't the same thing, though. The FCC defines a dispatchable location as the validated street address plus details such as suite, apartment or floor needed to find the caller (47 CFR § 9.3). If your GIS doesn't store those subaddress elements, a service order location that carries them may not come back LVF-valid. That doesn't make it a bad location for routing a 911 call: the street address still places it, inside the right PSAP boundary.

During the call, the ECRF routes. The emergency call routing function (ECRF) takes the address the call carries, matches it the same way, and returns the PSAP whose boundary the matched feature falls in. The ECRF can be more flexible than the LVF about which data it searches and in what order, because its job is to get the call somewhere.

That difference matters more than it looks. NENA puts it plainly: "Invalid locations get a route" (NENA-INF-027.1, section 2.2). Validation asks whether a responder could find the place. Routing only asks which PSAP should answer. So the bar for validation is higher. For minimum viable data, the routing bar comes first: primary address elements that match, inside the right boundary.

What makes an address placeable

The LVF decides what's valid by comparing an address to what you provisioned, so your GIS data effectively writes the rules (NENA-INF-027.1, section 2.2). For civic calls to move onto i3 routing, the address data has to clear five bars.

1. It's in the standard structure. An LVF should validate only against road centerlines and address points that follow CLDXF, the NENA civic address standard (NENA-INF-027.1, section 2.5.5; NENA-STA-004.2). Street names parsed into the right fields, communities in the right fields, payload in the NG911 GIS Data Model (NENA-STA-006.3). Legacy-format data doesn't count, however correct it looks.
2. It matches one and only one record in the GIS data. Two address points with the same address, or two overlapping centerline ranges, mean the LVF can't choose, and the address fails.
3. The road centerline is a real fallback. Ranges cover the addresses that exist, and parity (odd and even sides) is right, because when no address point matches, the range is what places the call.
4. It sits in or on the right PSAP boundary. The feature an address matches decides which PSAP gets the call, so it has to fall inside the boundary from Part 2. One caveat: a GIS steward has no way to confirm a point falls inside the correct PSAP unless the GIS data carries legacy elements, like the ESN, to check it against.
5. Subaddresses say what you mean. If you want a building or unit required, the data has to force it. An address point with no building number will make a building-less address valid (NENA-INF-027.1, section 2.2). That's a step beyond the routing bar; it doesn't hold up routing.

When the road is the boundary

Part 2 left this one for here. When a PSAP boundary runs down a road, a centerline match is risky. To place an address on a centerline, many LVFs and ECRFs interpolate a point along the range and offset it to the odd or even side. Set those offsets wrong and the point can land in the neighbor's PSAP, or outside the coverage area altogether, which returns a LoST notFound error instead of a result (NENA-INF-027.1, section 2.4.1.3).

The fixes are in the data:

• Build address points along boundary roads, so addresses there match a point instead of an interpolated spot on the line. NENA recommends exactly that.
• Set Validation Left and Validation Right to "N" on those segments. Those two road centerline fields tell the LVF that addresses on that side should validate only against address points (NENA-STA-006.3, sections 5.118 and 5.119).
• Provision each side to its own PSAP. PSAP A's road centerline carries only the even side, PSAP B's only the odd. In practice that's a stacked road centerline, or one from each entity, falling within each PSAP boundary.

When an address can't be matched

The outcome depends on when the miss happens.

At validation, it's a fixable record. The LVF lists the elements it couldn't match, such as the house number or street name, as invalid. The exception is a degraded match against the road centerline: if the house number missed every address point but fell in a range, the address comes back valid, with a warning. Otherwise, the OSP shouldn't load that address into the LIS or LDB, and if it believes the address is right, it files a discrepancy report against the LVF (NENA-INF-027.1, section 2.2). That report lands with the 911 Authority's GIS team. Every one is either a GIS gap to close or a bad record caught before a call.

At call time, it still gets a route. The ECRF uses whatever it can match to return the best route it can. If it can't place the address at all, the system falls back on routing policy and a default route the 911 Authority sets. A LoST server can say so directly, with a warning that a default was returned (NENA-STA-010.3, section 3.4.9). The call goes somewhere, but possibly to a center that has to transfer it.

That's the case for building address data to the routing bar first. If a service order validates against a road centerline, it should go into the LIS. If its primary elements (house number, street, community) all match but the subaddress details that make up a dispatchable location don't, it will still get the call to the correct PSAP. Until there's a high level of confidence that dispatchable locations are being validated, PSAPs will need to verify subaddress information on the call.

This gets especially important with MLTS databases. Enterprise phone systems carry building, floor and room details. Some 911 GIS data stores those for public buildings but likely not for private ones, since there's no access to collect them, so that's where LVF-valid and routing-valid drift furthest apart. A later post in this series takes MLTS on directly.

Questions to settle before civic calls move to i3

For 911 authorities

1. Which of our calls arrive with only a civic address, and through which carriers and MLTS operators?
2. Do our primary address elements match well enough that service orders validate, at least against a road centerline?
3. Have we decided what the LVF should treat as valid: is a building or unit number required anywhere?
4. Until dispatchable locations validate reliably, how will our PSAPs verify subaddress information on the call?
5. Who on our team receives LVF discrepancy reports, and how fast do they close them?

For GIS stewards

• Check that address points and road centerlines are CLDXF-conformant, not just correct.
• Find duplicate address points and overlapping centerline ranges; each one fails validation.
• Along boundary roads, build address points and set Validation Left and Right to "N".
• Keep legacy elements like the ESN on address points and road centerlines, so you can confirm each one falls inside the correct PSAP.
• Report how many addresses match an address point versus fall back to a centerline.

For vendors

• Show the match type and degraded-match warnings your LVF and ECRF return.
• State your geocoding offsets, and how you keep interpolated points from crossing a boundary.
• Explain what your ECRF does with an address it can't match.

Bottom line

A civic address only routes when your GIS can place it, exactly once, in the standard structure, inside the right line. Build the primary address elements to the routing bar first, then work toward validating full dispatchable locations.

Where does your data stand? Ground Truth GIS checks your road centerlines and address points, and optionally your MSAG and ALI, against NENA-STA-006.3, and labels each finding by what it affects. It's free, and your files never leave your computer.

Next in the series, Part 4: not every flag is a routing error.

Frequently asked questions

How does NG911 route a call that arrives with only a street address?

The emergency call routing function (ECRF) matches the civic address to the 911 Authority's GIS data, first to a site/structure address point and, if none matches, to a road centerline segment whose address range holds the number. It then routes the call to the public safety answering point (PSAP) whose boundary the matched feature falls in.

What is the difference between LVF validation and ECRF routing?

A new customer record with the location of a fixed device is supposed to be validated against the location validation function (LVF) before any call, when it is loaded into a location information server (LIS) or location database (LDB). The ECRF uses the address during a call to pick a PSAP. Validation is stricter: NENA notes that invalid locations still get a route (NENA-INF-027.1, section 2.2).

Why does an LVF check address points before road centerlines?

Address points are the more accurate data. NENA-INF-027.1 says an LVF should always search site/structure address points first and fall back to road centerlines only when no single address point matches. A centerline match can be flagged as a degraded match under NENA-STA-010.3.

Why would a valid-looking address fail LVF validation?

Common causes are data that doesn't follow the CLDXF civic address standard, duplicate address points or overlapping road centerline ranges that create more than one match, address elements, such as a street suffix or community name, that don't match the GIS record exactly, and subaddress elements (building, floor, unit) the GIS doesn't store. An address that fails for that last reason can still route correctly.

How should GIS data handle addresses along a road that forms a PSAP boundary?

NENA recommends building site/structure address points along boundary roads so addresses match a point rather than an interpolated position on the centerline. The Validation Left and Validation Right fields in NENA-STA-006.3 can be set to "N" so those addresses validate only against address points.

← All insights