Address does not match but then it does in rematching

[JoeBorgione]

Using ArcGIS Pro 2.7.2 and a composite locator.

I'm seeing what I feel is odd behavior when geocoding. (See image below).  This address 9113 W MAGNA MAIN ST initially shows as unmatched, but there are two 100% match options available to me.  What's up with that?  I sure would hate to plow through 3500 'unmatched' records just to find out they really are valid...

@BradNiemand 

This problem I've mentioned in the past has reared it's ugly head again, where you adjust an address in the Single Line Input field, only to be bounced back to record #1.  The strangest thing about this is yesterday I didn't get this problem, and today, using the same locator but a different file of addresses I am...

and towards the end of the day...

Notice  the address 3215 S Valley St went unmatched yet I can use the find tool with the locator I used (CityWorks2) and it hits on an address point...I have the locators set to Match With No Zones = YES....

[ShanaBritt]

Do you only see this behavior with composite locators? Do you see the behavior with multirole locators?

The jumping behavior is something we are looking into for a future release of ArcGIS Pro.

[JoeBorgione]

@ShanaBritt -  I will do a little more testing for you, but the initial problem was exposed in a composite locator.

The jumping problem is very weird;  when I first re-matched the addresses, everything worked fine.  Then I closed down for the day and when I picked up where I left off the next day, the problem manifested.  As a test, I created a new Pro Project and ran the same addresses against the same locators, and rematching worked just fine.

Then I got the great idea to upgrade from 2.7.2 to 2.8 and that opened up a whole new can of worms for me, unrelated to geocoding.  I'll need to straighten that mojo out before I get back to geocoding.

[JoeBorgione]

@ShanaBritt ;  I can replicate the unmatched while geocoding but shows up during rematching with just a multirole locator only, not a composite:

[ShanaBritt]

@JoeBorgione When on the Unmatched tab in the Rematch Addresses pane, does clicking the Auto Rematch button match the unmatched addresses?

[JoeBorgione]

@ShanaBritt   It doesn't appear to have any effect on them:

Stepping through them I see a few addresses that have unit numbers that are listed as unmatched but resolve:

and others that are unmatched, but show up with a good score and IMHO should have matched to begin with:

I have the locator properties to match without zones and a min match score of 85.

[ShanaBritt]

@JoeBorgione It looks like your input addresses have no zone info, but the locator was built with zones and the match with no zone setting set to 'Yes'. I'm wondering if you would get different results if you built the locator w/o zones and geocode the addresses. When the locator is built w/o zones the "match with no zone" property is set to 'Yes' by default. Is the city info required for the match candidate? To fully investigate and determine why this unmatched behavior is happening we would need the reference data, locators, and sample of just the addresses w/o any identifying info. If you want to reach out to me with this info or log a new case with Support is up to you. 

[JoeBorgione]

@ShanaBritt -

It looks like your input addresses have no zone info, but the locator was built with zones and the match with no zone setting set to 'Yes'.   In my area of operation, I am blessed with a single address grid which means no address is repeated across zones.  There is one and one only 1234 S Main S for example.  Consequently, my M.O. for geocoding has always been to simply geocode the address and forget about jurisdiction or other zone. So it's only logical that when I create a locator the match with no zones setting = Yes.  Brad and I have arm wrestled over this multiple times, and while I would like to see that property exposed to arcpy I don't anticipate that happening, at least between now and December 24, my anticipated retirement date. (Merry Christmas to me...)

I brought this up here in forum  more or less as an FYI, and to see if anyone else has experienced it.  I'll probably start a support case and I'll let you and Brad know when I do.

[ShanaBritt]

@JoeBorgione If there is one and one only 1234 S Main S in the reference data used to build the locator, then building the locator w/o zones would be the suggested workflow. I'd be curious to see what your results are if you build a locator w/o zones and geocoded your table of addresses to see if you get different results than with the locator that was built with zones.

[JoeBorgione]

@ShanaBritt If I build a locator that requires some sort of zone, be it a city, county, zip, whatever and pass addresses to it without zones, I'm pretty sure I won't get any matches.  That's what I discovered early on with the new style locators.