Select to view content in your preferred language

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

2526
12
08-15-2019 01:43 PM
CynthiaParker1
Occasional Contributor

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!

Tags (2)
0 Kudos
12 Replies
ShanaBritt
Esri Regular Contributor

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?

0 Kudos
MichaelVolz
Esteemed Contributor

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

0 Kudos
CynthiaParker1
Occasional Contributor

Yes, and nothing comes up.

0 Kudos
CynthiaParker1
Occasional Contributor

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

0 Kudos
JoeBorgione
MVP Emeritus

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.

That should just about do it....
0 Kudos
CynthiaParker1
Occasional Contributor

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?

0 Kudos
JoeBorgione
MVP Emeritus

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.

That should just about do it....
0 Kudos
CynthiaParker1
Occasional Contributor

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?

0 Kudos
JoeBorgione
MVP Emeritus

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.  

That should just about do it....
0 Kudos