Inconsistency of Geocoding result

[RuiyangLi]

Hi everyone,

I've encountered an issue when I am geocoding a dataset (~150k records) with arcpy and streetmap premium.

I run it 4 times and set it match only at 100 score.

I got 4 different numbers of matched records : 105974, 105976, 105977, 105979

And meantime, the total number of records stats the same.

I wonder if anyone had similar experience.

Thanks in advance.

[RuiyangLi]

Some updates on this issue.

I've run another 10 same-variable tests (at 100 score). These rounds of test were running under the same environment (same machine at different time with no other application running) and same input variables (click from "Result" window). I got different matched number range from 105972 to 105979.

And I have joined matched records with unmatched records across different rounds. I found the inconsistent records are tend to appear more than once across rounds.

When I take a closer look at each unmatched records, they are address with suffix numbers (such Lot 9, or Suite 102). They can be matched at 100 score when taking out the suffix.

Is anyone having the same issue?

Thanks again.

[DakeHenderson]

 I ran  4 same -variable tests on about 1000 records, and got match rates between 802 and 820.  Then I did the same test, but this time using the "Rematch Automatically" button immediately after the initial match.  The end results were almost identical (833 matched). I will always run the automatic rematch henceforth.

[RuiyangLi]

Hi Dake,

Thank you for the reply. That helped me to realize that I'm not alone.

We used exactly same method - geocode the unmatched record one more time, to solve the issue.

I thought there were no interested in this topic so I didn't update the solution.

Best,

Yang

[OH]

This is still a problem.

I only noticed because I happened to have the same address multiple times in an input dataset.

One of those copies got geocoded successfully, the other one did not.

This is completely unacceptable behavior.  ArcGIS should return the exact same result for a given input (especially if those inputs are only occuring 30 seconds apart).

[RuiyangLi]

Hi Otto,

Based on the information provided by a ESRI Geocode team member, it is because of a hidden input variable 'Time Out' setting in the geocoder. The program will stop searching for a record after certain time. There will be less chance if I increase the 'Time Out'. But it will take significantly longer time for the program to run. So it's really a trade-off.

Now our standard practice is first create a unique address table, and then run the geocoder. Then run the 'leftover' records through the geocoder again. It usually solve the problem.

[OH]

I'll check out the the Time Out option.  I've been having pretty bad performance issues with recent versions of ArcGIS on my systems, so that may be making the problem even worse.

I ended up having to run the unmatched addresses through the rematch process 4 or 5 times before it stopped finding new matches.  Wasn't a lot in the end (about 60 matches out of 20k+ addresses), but it is disturbing that the same address might have different results depending on when you run it.