Address Locator does not always find address if not searching with street type

[CynthiaParker1]

Hello!

I am having a big problem with my address locator that I have been trying to make, I'm hoping someone can help.

I have a dual-range locator based off of my centerline data. If I use it to search "100 Main" it will easily find "100 Main St". However, with some streets, if I do not add the type at the end of it, it simply will not find the address. So far this only seems to be happening with one street that we know of, named Rincon St. When I do a search for "2100 Rincon" it comes back with nothing. If I search for "2100 Rincon St" it will give me a match. This is true for all addresses on this streets with 9 different segments. Any ideas as to why this is happening? It doesn't happen when I create the locator with the 9.2 version of the locators, but those bring up even worse bugs.

This locator is used by our emergency dispatch, so I can't easily ask them to just start using the street types all of the time, they need to work fast and it's unrealistic that they can memorize every street in the city like that.

Thanks!

[ShanaBritt]

Using the Planarize tool can help with ensuring the lines are snapped together where they intersect. I would select the line features that represent the intersection, run Planarize, then create a locator based on the planarized lines to see if the behavior changes. https://desktop.arcgis.com/en/arcmap/10.6/manage-data/editing-existing-features/splitting-lines-at-i...  

[JoeBorgione]

Yep.  But for the sake of discussion.....

I'm always just little hesitant though with planerize, integrate, etc being applied to a complete feature class because those tools are just that: tools, and setting the correct tolerances is really critical so you don't end up with intersections where you don't want them.  On one centerlines feature class I used in dispatch there were a number of bike/walk paths that did not truly intersect the actual streets, but we put address ranges on them just like any other street.  (Spillman is address centric; it needs a valid address to ensure how it manages records of calls.)  I sure didn't want my network analysis routing utility to put a 90,000 lb rescue engine crossing a 5,000 lb pedestrian bridge...

[KariRandall-Secrest]

Hi Cynthia - Have you found a solution for this?  I'm having similar issues with our street centerline locator in Spillman.  We also use a first 3-letter shortcut and a first word in the street name shortcut in the alt names table of the locator.  Often, but not always, a search using "ST" for the street type doesn't work when searching the street centerline locator.  For example:

“2nd St / E St” doesn’t work, but the following do: “2nd / e”, “2 / e”, “2nd Street / E Street”
"46039 Baker Dr" doesn’t work, but the following do: “46039 Bak”, “46039 Baker”, “46039 Baker Drive”
"320 E Fir St" doesn’t work, but the following do: “320 Fir”, “320 E Fir Street”, “320 East Fir Street”