nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

100% Unmatched addresses

dylancummings

I have a table of about 250 addresses that i need to geocode. It is just an excel table with hospital names and addresses. I have done this a thousand times with no problem but now for some reason when i geocode the table it says that all 250 addresses were unmatched. I right click on the table, click Geocode Addresses, Select my Address Locator (North American Geocode Service), fill out the fields with the corresponding values (ie. Address = Street Address, Zip Code = Zip, etc.), then it returns 100% unmatched. When i click on Rematch Addresses, it brings up all the unmatched addresses but it shows that there are 100% matches for all of them but it just won't physically match them unless i click "match" for every single one. Why won't it just match them?

Finde mehr Beiträge mit dem Tag

Accepted answers

All comments

BradNiemand

You probably have spaces in the field names in your excel file. If you remove the spaces in the field names and regeocode, you will get the matches you are looking for.

Brad

AugustinePaz

Isn't the issue related to the ESRI discontinuing the North American Geocode service?

PeterHanmore

We have the same problem with our locators as well. We are trying to do testing against several locators and in many cases, a lot of addresses are unmatched. Similar to the OP, if you open the rematch dialog you see that most (if not all) unmatched addresses actually have scores of 100. If you click the 'automatic rematch' button it will often (depending on the locator being used) successfully match the records. Using our postal code locator, it actually goes from 100% unmatched to 100% matched.
We know that the locators themselves are working fine, at least through the REST endpoint, because we get the expected results both from apps consuming the REST service and directly from the REST endpoint interface.

There are no spaces in our field names, so that isn't the issue.
We have tested this with both v10 and 10.1 and the problem exists with both versions.

If anyone has any suggestions for fixes/workarounds, I'm more than willing to try them. At this point, we will have a hard time recommending using arcMap for batch geocoding because you can't rely on the results.

I've attached a screenshot showing the problem. You can see that it is 100% unmatched, yet there is a 100% score for the selected record.

Capture.PNG

JoeBorgione

"We know that the locators themselves are working fine, at least through the REST endpoint, because we get the expected results both from apps consuming the REST service and directly from the REST endpoint interface."

And yet you state they are not working and your screen shot indicates that as well. I'm confused.

I also geocode about 2,000 9-1-1 calls a day using a published ArcGis composite locator; trust me, if it didn't work, I'd be hearing about it.

PeterHanmore

What I state is that the results shown using the ArcMap geocoding tool can be incorrect and unpredicatable.
My screenshot shows that none of the addresses were matched automatically even though they have scores of 100%. The minimum score for automatic matching was 75%. Therefore the results contradict each other - if the minimum match score was achieved the geocoding was successful and this should be reflected in the totals of matched/tied/unmatched addresses but they are not.
In addition, if you simply click on the Automatic Rematch button, you will often see the results change - sometimes from 100% unmatched to 100% matched.

The geocoding service itself is returning the correct/expected results when the same addresses (that ArcMap failed to show as geocoded) are submitted through the REST interface, so we can be certain that it is not a problem with the ArcGIS Server service. ArcMap does not use REST - it uses SOAP and the traffic is in compressed binary format so we can't look at the traffic with tools like Fiddler2. I'm not saying the problem is with the REST service - in fact I doubt that it is - I think the problem lies in the logic of the geocoding GUI within arcMap. Our .NET and FLEX based applications which consume the REST services all appear to be working correctly - the JSON responses are formatted correctly and have all the information necessary to determine if a match was found or not.

I would at least like to be able to pinpoint why this behaviour is occuring. At least then we can document it for our users, and hopefully provide a solution as well.

JoeBorgione

Didn't mean to push any buttons Peter. If you'll allow me one more suggestion, it would be to contact tech support and start an incident. Your post has strayed considerably from the OP.

BryanLynn

I am having the exact same problem with our new locators. Did you ever find a solution for this?

Thanks

BryanLynn

After a little more testing, I found that if I set the option "Match with no zones" to true, my match rate goes from 13% to over 80%. I am not sure why this matters since I am not using the city, state, or zip code in any of the addresses but it made a huge difference. The addresses left unmatched were actual problem addresses.

JoeBorgione

There was talk some time ago about changing the default value to 'TRUE' so you wouldn't need to. I can't remember reason it didn't materialize. Even though you don't use zones in your matching data, the locator 'looks for them and responds accordingly: It wants 1234 S Main St SomeCity, SomeState, SomeZip and when it can't find all that it dings you if you just have 1234 S Main St.

Nimm an der Diskussion teil

Angemeldete Mitglieder können Beiträge verfassen, Updates folgen und mehr. Neu hier? Registriere ein kostenloses Konto.

Schnellzugriffe

Community Help
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.