topic Re: Address Locator does not always find address if not searching with street type in Data Management Questions

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

CynthiaParker1 — Thu, 15 Aug 2019 20:43:19 GMT

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!

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

ShanaBritt — Fri, 16 Aug 2019 06:19:27 GMT

Cynthia:

What version of ArcMap are you using? Is using ArcGIS Pro an option for the dispatchers?

Must the dispatchers use a local locator or can they use a geocode service if you were to publish your locator to ArcGIS Server?

Does the same behavior occur if you build the locator without mapping the street type address component?

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

MichaelVolz — Fri, 16 Aug 2019 10:17:14 GMT

Have you tried changing the scores in the parameters section of the address locator?

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

CynthiaParker1 — Tue, 20 Aug 2019 00:34:57 GMT

I am creating the locators in ArcMap 10.6 and I publish them as a geocoding service to a 10.6 Server (no Portal). The service is then consumed by the third-party dispatching program.

I haven't had a chance to make the locator yet without adding the street type field. I should also mention that the same street that doesn't show up in the Address Point locator as well (the geocode service is a composite locator of several different points, this particular street doesn't show up in the individual locators or the composite locator).

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

CynthiaParker1 — Tue, 20 Aug 2019 00:35:26 GMT

Yes, and nothing comes up.

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

JoeBorgione — Tue, 20 Aug 2019 12:56:27 GMT

Is your thrid parth CAD Spillman? I worked at a call center for many years that deployed it and used an extensive alt names table for my streets that virturally eliminated any guess work.

Consider the street S MAIN ST;

Each of the name components are parsed out in thier own field: PreDir, Name, SufType.

AltName1 = S MAIN

AltName2 = MAIN ST

AltName3 = MAIN

It was a bunch of work, but my hit rate was better than 99.7%, with a call volume of 1500-2000 calls per 24 hours.

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

CynthiaParker1 — Tue, 20 Aug 2019 15:03:40 GMT

It is Spillman! We use Alt Names that are the first three letters of every street so they can type names out faster. Our main table of data has everything broken down like that already, should I be doing so again with the alt names?

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

JoeBorgione — Tue, 20 Aug 2019 15:23:19 GMT

That's your call, but it sure worked well for me; at one 9-1-1 call center I created 3 letter alt names for 'speed' too. Personally I think that's over kill as what if you have three streets:

Skyview Dr

Skyridge Ln

Skyline St

Making a choice on 'Sky' more or less kills the speed factor, but that's just mho. It's all in numbers I guess...

However, in your particular case, it's curious that the problem occurs with an address on Rincon in both your address points and your centerlines. You may want to take a closer look at the actual data source(s) and see what's going on there.

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

CynthiaParker1 — Tue, 20 Aug 2019 15:29:12 GMT

At this point I don't even know what to look at with the data. That street and those lines/points have been around forever. Their geometry is fine. Everything is filled out. My Spillman support folks are at a loss too. Trying adding all kinds of alt names now to test that out. I've also got my county's version of the data with the same street, so I am going to make a locator based off of that and see what happens.

May as well bring this up since you're familiar with Spillman. We are also having another issue where some intersections are showing the display address long. Example: We search "Sixth & Fuller" and while all the other fields and match addresses are correct, the display address shows up instead as "Fuller & Fuller". Any ideas?

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

JoeBorgione — Tue, 20 Aug 2019 15:52:17 GMT

For intersections, I'm assuming you are using your street centerlines as the locator? That's how I recommend it any way; I shy away from 'intersection points' Do any of your intersections display correctly? If so, create a locator with just the streets of Sixth and Fuller: for that matter, are you sure they intersect in the data? They may look like they do, but zoom waaay in and make sure they do.

For trouble shooting locators, I suggest using just the problem children as the basis (data) of your locators. Make a locator based just on the streets named Rincon as well as just the address points with Rincon as the street name. That may show the problem in the data itself.

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

ShanaBritt — Tue, 20 Aug 2019 17:06:31 GMT

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-intersections-with-planarize.htm.

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

JoeBorgione — Tue, 20 Aug 2019 17:27:52 GMT

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...

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

KariRandall-Secrest — Mon, 17 Aug 2020 18:25:25 GMT

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”