Select to view content in your preferred language

ArcPro - Geocoding Problems With Over Matching

1234
2
07-28-2022 11:25 AM
DJacobs_UNMTRU
New Contributor

Hello GIS Community,

We geocode traffic crash data and have routinely done so using ArcMap Desktop and a composite address locator built off of the State's roadway shapefile. This has worked successfully for more than 10 years by not over-matching incorrect locations. This allows the geocoder to review geocoding options and find or clean street information.

The traffic crash data contains a list of street names or address where crashes took place. We create a single intersection field containing either the address or intersection information for the crash.  Along with the City that crash occurred in, we input those two fields into our address locators (sample data below):

DJacobs_UNMTRU_0-1659032385222.jpeg

However, as we are attempting to transition this progress to ArcPro we’ve encountered problems with our over-matching of bad addresses or intersections.  Below are our ArcPro Address Locator properties:

DJacobs_UNMTRU_1-1659032385230.jpeg

DJacobs_UNMTRU_2-1659032385238.jpeg

We have pulled out some results that are particularly wrong, many of which we could not realistically use match score to filter out. Most of them have matches that include a single piece from directly next to the intersection connector but ignore most of the rest of the input. For example, an input address of an intersection “I 40 @ Carlisle Blvd NE” yields a street address of “40 Carlisle.”

 

DJacobs_UNMTRU_4-1659032508410.png

Typically, we would expect this to have a low match score and to be able to filter results like this out, but some of these results have a match score of more than 95. Many of the poor results follow the above pattern, but not all of them. An input address of “Tramway Blvd NE @ E/B Interstate 40 off ramp” gives a match of “E & I, Albuquerque.”

The locator only includes streets so we would expect this to not match. Up to this point we have been using locators that were originally created in ArcCatalog but the transition to ArcPro 3.0 has made these unavailable for use.

My question is, what is causing these poor matches and is there anything I can change to prevent them from matching?

0 Kudos
2 Replies
DJacobs_UNMTRU
New Contributor

Sorry, I realized you may not be able to see our Geocoding Results.  See attached:

0 Kudos
ShanaBritt
Esri Regular Contributor

@DJacobs_UNMTRU ,

Looking at the screenshots and info you provided I have a few questions and suggestions.

Since this is just a street based locator I would make sure the Match out of range is set to 'No'. I see that just StreetName is mapped when creating the locator. Does the reference data not split up the address components into individual fields? If the street is not broken up into components in the reference data I would run the Split Addresses into Components tool and use the result to build the locator. It would be helpful to see the street values in the street data, the Addr_type field in the geocode result, and what Address categories are checked for the locator in the Geocoding options. I also see that you have the forward slash as an intersection connector along with '@' and for some of the intersections both of those characters are listed. 

0 Kudos