Geocoding fails for some addresses

[carolmanderson]

I've been geocoding a large number of Utah County addresses and have found a small percentage fail to return a match. This is a sample: geocoding_failures.csv

I can't find an obvious reason for the failures. The addresses exist, and I'm able to manually look them up here. I'm geocoding these addresses as the first step in looking up precincts, so I'm also open to suggestions about a different workflow for achieving that. Precinct lookups are working fine -- the problem is the geocoding step.

Below is the code I'm using, which works for the vast majority of addresses.

class Geocoder():

    def __init__(self, api_key):
        self._api_key = api_key
        self._geocoding_url_template = "http://api.mapserv.utah.gov/api/v1/geocode/{}/{}"
        self._precinct_url = "https://services1.arcgis.com/99lidPhWCzftIe9K/ArcGIS/rest/services/VistaBallotAreas/FeatureServer/0/query"

    def get_coordinates(self, street, zone, **kwargs):
        """
        street (str): a street number and name
        zone (str): a city name or ZIP code in Utah
        """
        kwargs["apiKey"] = self._api_key
        kwargs["spatialReference"] = 4326

        result = requests.get(self._geocoding_url_template.format(street, zone), params=kwargs)
        if result.status_code != 200:
            # if result isn't found, check for unit number, remove and retry
            if "#" in street:
                num_signs = street.count("#")
                if num_signs == 1:
                    street = street.split("#")[0]
                    result = requests.get(self._geocoding_url_template.format(street, zone), params=kwargs)
                elif num_signs > 1:
                    print("Messy address with two number signs, giving up: ", street)

        return result

    def get_precinct(self, long, lat):
        """
        lat (int): latitude of location in EPSG:4326 coord system
        long(int): longitude of location in EPSG:4326 coord system
        """
        params = {
            "geometry": f"{long},{lat}",
            "geometryType": "esriGeometryPoint",
            "inSR": 4326,
            "spatialRel": "esriSpatialRelIntersects",
            "outFields": "*",
            "f": "json"
        }
        return requests.get(self._precinct_url, params=params)

    def extract_coords(self, response):
        long = response.json()['result']["location"]['x']
        lat = response.json()['result']["location"]['y']
        return (long, lat)

    def extract_precinct_id(self, response):
        return response.json()['features'][0]['attributes']['PrecinctID']

Example request:
geocoder.get_coordinates("1391 N Fox Borough Dr", "Lehi", **{"acceptScore": 90})

Returns:
{"status":404,"message":"No address candidates found with a score of 90 or better."}

(I've also tried a score threshold of 70, which doesn't improve results.)

[steveoh]

Thank you for bringing this to our attention. I'll share these addresses with our data team and see what we can figure out. Good luck and I'll keep you posted here.

A couple things come to mind that I would like to share with you.

1. We have a javascript component written and battle tested for geocoding that you can use if you want. You can find it in the @ugrc/utilities package with the source code in our agrc/kitchen-sink repository.
2. Our geocoding endpoint can only be as successful as the data we've been provided. This blog post explains any and all caveats. If the failed addresses are found in our data then we likely have an API issue.

[steveoh]

I took the time to look at one address, the 373 N 1200 E in American Fork. This to me looks like it should match but not where I initially thought.

In the image below you can see that addresses on the 1200 E cul-de-sac do not go as high as 373. The roads verify this with a left and right value of 329.

But looking at the Kimberly street above, which is an alias for 1200 east, it does have an address point and road segment that should match. The county may not have provided the alias values for that street to us to be able to match on the alias. But trying to geocode with 373 N KIMBERLY CIR also does not find a match in the address points or the roads. Not finding the address point is a mystery to me but the roads appear to have the ranges set incorrectly...

So this one is at least partially a data issue that we can handle in our next update. Does that seem right to you @eneemann?

[eneemann]

I think a number of these may be related to formal street name vs alias street name issues. I will try to dig deeper into the data side of it in the next few days.