Address locator "skips" over a known address

[Danielle_Journey]

I have an address locator built from a feature class that contains all of our address points down to the suite level.  The address locator works perfectly for finding the suite addresses in a building, but will not find the main building address.  For example, it will find 412 VILLAGE DR 200, but will not find 412 VILLAGE DR.

I've tried the follow with no luck:

• Checked all the fields in this address's record to look from spelling errors, trailing spaces, etc.  
• Rebuilt and recreated the address locator several times, even tried adding a duplicate address point "from scratch" before building the address locator.  
• The new address locators have been built inside and outside of a file geodatabase.  
• I exported out the address point feature class and built an address locator on the new feature class
• Rebooted & crossed my fingers.

Has anyone had this happen?  I am completely stumped as to what else to try..  

I'm using 10.3.1 with the locator style attached.

[JoeBorgione]

I don't see your locator attached. Is it custom or out of the box?

[Danielle_Journey]

Hi Joe, I attached the locator to the question.  I don't remember the source of the locator. 

[JoeBorgione]

Let me take a look at it. 

Here's a shout out to sbritt-esristaff‌ ESRI geocoding hero....

[Danielle_Journey]

Thanks Joe.  I found this geonet feed and I think this is where the locator style came from:  https://community.esri.com/thread/26594 

Looking through this thread, someone else had the same issue of the locator finding the suite address but not the main building address, which was suppose to be "fixed" according to this thread... maybe because the locator is older it just needs to be updated a bit?

[JoeBorgione]

That's a pretty old thread, and geocoding has changed considerably with 10.3 and beyond.  That said, I'm not getting anywhere with the locator you provided or even with the out of the box locator;  yours returns no results for me (although I may have set it up incorrectly), and the ESRI locator matches them all but neglects to recognize my Unit number field. 

My address table has two fields:  Address & Unit.  When I get my results back none of them are 100%, but rather 93%.  I've always been skeptical of geocoding with unit numbers so I've never used them.  Sorry I'm not help here; you may want to get tech support on the line and see if they can help.

[MichaelVolz]

I have an Address Locator built from address points that uses the US Address - Single House Subaddress Locator Style that I believe builds off of USAddress.lot.xml that is installed by default in the Locators folder.  I am able to find both the main address and suites associated with this address locator built from my address points. (e.g. If I type in

1 E First Av I get 1 E First Av;  1 E First Av, Ste 1;  1 E First Av, Ste 2;  and 1 E First Av, Ste 3)

I do not have a USAddressWithUnit.lot.xml file in my Locators folder, so I'm unsure where USAddressWithUnit.lot.xml would have come from as I use lot files from the default ArcGIS for Desktop install.

[Danielle_Journey]

Michael - when you geocode with this locator style do you use the single line input or multiple field input?  I created a locator with it, and zero where matched.  In fact, none of the out of the box ESRI locator styles work for me.  The locator style created by @BrianOevermann in this thread (https://community.esri.com/thread/26594 ) is the only locator that has worked, besides the addresses without units.

[MichaelVolz]

I use the single line input because those are the only kind of address locators that AGOL will accept and my organization wants the ability to use our address locators in geocode services that are used in AGOL.

Do you have Match with no zones set to Yes (The default value for this address locator is No and by default I was not getting many address matches - Tech support helped me out with that configuration setting).

[Danielle_Journey]

Thanks Michael, I'm not familiar with that setting, where do you configure that?