PROBLEM
When point data containing house number ranges is used to build a PointAddress role locator with the Create Locator tool, even and odd input addresses may be geocoded to the wrong side of the street.
In the example shown in the image below, the Middlebury Addresses point feature class contains two address points with house number ranges stored in the HouseNumFrom and HouseNumTo fields. The address "6 Swanage Ct, Middlebury, Vermont, 05753" is an even-numbered address and should match the feature with ObjectID 2, which represents the even-numbered side of the street (south side). However, the address is incorrectly matched to the feature with ObjectID 1, which represents the odd-numbered side of the street (north side).

When geocoding an address with a PointAddress role locator that uses address ranges in its reference data, parity values must be correctly defined.
In this example, the Parity field in the MiddleburyAddresses point feature class contains <Null> values. Without parity information, the locator cannot restrict matches based on odd-numbered or even-numbered addresses.
As a result, the locator evaluates candidates features based on address ranges alone and may return a match that does not align with the expected parity of the input address.
The specific steps to follow to reach a resolution depend on how address ranges and parity are defined in the reference data. In this example, the issue is caused by missing parity values, so it can be resolved by going through the following steps:
In the example shown in the next image, after updating the Parity values and rebuilding the locator, the address "6 Swanage Ct, Middlebury, Vermont, 05753" is matched to the feature representing the expected (even-numbered) side of the street.

Note: If the 'Parity' field is not mapped to the locator, it must be re-created (instead of rebuilt) through the Create Locator tool with the 'Parity' field mapped in the tool's 'Field Mapping' parameter.
Article ID: 000042438
Get help from ArcGIS experts
Start chatting now