10.2.2 Alternate Names Geocoding Does Not Return Matches

4193
11
Jump to solution
02-09-2015 09:39 AM
Highlighted
MVP Esteemed Contributor

After a quick search of the forums, I didn't see this particular problem listed, which is surprising to me as it was brought to my attention from a colleague using 10.2.1.

 

I created dual range address locator based on centerlines data.  We have named and numbered streets in Utah, and every named street has a numeric alias:  I created an alias table and it is part of the locator.  Both the centerlines data and the alias table have a join item called of all things 'joinitem'.  Initially I built the locator with out indexing the joinitem, and when it failed for the first time, I then retreated and added the index.

 

The alt-names table is ignored.  My colleague created separate dual range locator using the numeric values as the street names and then put it together with the original as a composite and that works for him.  I want it (as he does) to work the way it's supposed to.

 

The only changes I made to the default settings is I Added YES to Match with no zones (I heard that was a bug at 10.1) and changed the Presort input table by (fields) to City, Zip State, but I have even used an input table, I've just tested the locator interactively.

Reply
0 Kudos
1 Solution

Accepted Solutions
Highlighted
MVP Esteemed Contributor

Here's the answer:

In the AltNames table 10.2 REQUIRES that you have a  PRE_TYPE and ST_TYPE field to map to.  Even if you don't have those fields in your data, you 'll need to add them.

What I did for my situation is add them as text type of one character, then calculated them to equal "" (doublequote doublequote so they are empty  but not <null>)  If you use these two fields as shown above, when you create your locator it will map to them by default.

View solution in original post

11 Replies
Highlighted
MVP Esteemed Contributor

Here's the answer:

In the AltNames table 10.2 REQUIRES that you have a  PRE_TYPE and ST_TYPE field to map to.  Even if you don't have those fields in your data, you 'll need to add them.

What I did for my situation is add them as text type of one character, then calculated them to equal "" (doublequote doublequote so they are empty  but not <null>)  If you use these two fields as shown above, when you create your locator it will map to them by default.

View solution in original post

Highlighted
New Contributor II

Hi Joe

I came upon this post researching the same issue ( in 10.2.2). I set up my Alternate Name table based on the directions above and have all the field mapping in the Locator properties set correctly (as far as I can tell) but still can't get the Alternate addresses to work (my alias table works).

I've gone over the help and tutorial information, tested the join and seem to have all the settings right in my Locator.

I thought I would post here to see if there was anything I may have missed. I can share my Locator if that helps.

Thanks

Reply
0 Kudos
Highlighted
MVP Esteemed Contributor

Sorry Vicky, 11 months ago I set up a 10.2.2 box, but because of a third party software I'm dependent upon, I'm stuck using 9.3 locators.  I can't remember anything else than what I posted back then.  Perhaps one of the ESRI geocoding folks can chime in.

Bruce HaroldBrad Niemand

Highlighted
Esri Regular Contributor

Vicky

Are you able to provide a screen shot of the entire field mapping showing all of the primary and alternate table parameters, as well as the Geocoding Options? When I'm testing the alternate name to see why I may not be getting the expected results I add the reference data and the alternate name table to a Map and create a relate using the fields that you would map as the JoinIDs when building the locator. Then use the Identify button on a feature that has an alternate name and check the related info in the Identify Results Window to see if the information is correct. If you would like me to look at your locator and data you can send it to me at sbritt@esri.com.

-Shana

Highlighted
New Contributor II

Hi Shana,

I had tested the join/relate between the reference data and alternate table and it works fine. I will send you the locator data at the address listed above.

Thank you

Reply
0 Kudos
Highlighted
New Contributor II

In the field mapping settings I was using the same field for my Primary Table FeatureID and primary table joinID. This was affecting the Alternate name search success. By using ObjectID (or another unique field in the data) I solved this problem.

Thank you Shana for you help!

Reply
0 Kudos
Highlighted
MVP Esteemed Contributor

I was using the same field for my Primary Table FeatureID and primary table joinID.

So the bottom line is your were using incorrect field mapping?

Reply
0 Kudos
Highlighted
New Contributor II

Actually my initial field mapping worked fine with test data in a file gdb but when I tried to use SDE data as the data source I needed to make the above noted changes to the field mapping for the Alternate Name search to work. Thanks for helping to clarify.

Highlighted
MVP Regular Contributor

Was also just dealing with the locator not returning proper results when using the alias table.

The piece of Joe's answer that I was missing, in case it helps anyone else, is that you need those two extra fields so that your field mappings on the alias table match the field mappings on your primary table (road centerlines in my case). These fields themselves don't matter, just that the two sets of field mappings match. So in my case, I removed all those extra fields and just made a FULLNAME field on the alias table because that was all I was mapping to on the road centerlines.

Reply
0 Kudos