Address Inputs With City/State When Locator Refrence Data Has No Zone Information

[BrittJohnson]

We have a point address locator (built off of an ESRI template we got from a white paper some time ago) for handling point addresses with unit numbers. It works quite well for our needs, one thing in particular that we like is how it matches addresses whether or not they have a City/State as part of the address. This is an important feature; as our address reference data (both points and block ranges) does not include any City/State information to be mapped as a zone for the locator templates.

For Example, if we input "144 Tichenor Av" (a valid address in the reference data); it will return that address with a score of 100. Now if we input "144 Tichenor Av, Auburn, AL"; the locator returns "144 Tichenor Av" with a score of 90. It appears to treat the City/St information as a spelling hit on the score, but will still return the valid address.

The issue has arisen is that our line locator is built off the default USAddress Dual-Range template included with ArcGIS. With the line locator built from this template, any address that is input with a City/State at the end of the string will return no matches; even if the street number and street parts of the string are valid for a good address in the reference data. In conversations with Tech Support they indicated that this is expected behavior from the USAddress templates due to the fact that our reference data has no zone information. Also, in their opinion our point locator is working "incorrectly" when it returns matches that do have the City/State as part of the input address string. While that might be the case from a design standpoint; for our needs this is exactly how we need our locators to function.

Has anyone had any luck in customizing the default USAddress templates to "disregard" City/State parts of an address string and return matches; instead of this default functionality of not returning any matches in this case? I have tried commenting out various parts of the zone information in the XML template; but this usually results in a locator that will not match any addresses. Admittedly, I am very new to customizing locators at the XML schema level though.

Britt

GIS Technician

City of Auburn, AL

[JeffWard]

A workaround might be to create two dual range locators and put them in a composite locator.  One that matches zones, one that doesn't.  You can specify whether zones are required on the properties of the individual locators.

[SeanMurphy1]

From what I understand of your problem, here's what you want to do:

1. Copy and paste the style file under C:\Program Files (x86)\ArcGIS\Desktop10.2\Locators" so that you can customize.

2. Open the new style file in Notepad or another text editor.

3. Change the <name> of the style so you can distinguish when creating address locator.

4. Find (ctrl+f) "Top Level Elements".

5. In the Top Level Elements section, scroll down to "FullNormalAddress" definition.

6. Change the weight of "NormalAddress" to "100" and "Zone" to "0".

7. Repeat step 6 for "FullIntersection" if desired.

8. Save and close. Open ArcMap and create new address locator.

9. Select your customized style file. Make sure the city, state, and zip code fields have street data associated with them.

The address locator should return results with a matched city, state, and zip code, even if the geocoded address entry does not have those elements. Essentially, you gave the zone elements less say/weight in finding the location, but the zone elements are still returned in the results.

Hope this helps.

[BrittJohnson]

Sean,

That was actually one of the first changes we tried to the locator XML. When making those changes in addition to changing the "Match with no zones" parameter to Yes in the Locator Properties after build it still will not match an address input formatted like "144 Tichenor Av, Auburn, AL." Without changing the Match with No Zone parameter it will not locate any addresses.

I think a part of why this solution will not work is that our block range data does not have any fields for zone information. We have Left/Right From and To fields in addition to the street name and that is it. We are trying to have it return a simple address match "144 Tichenor Av" even if the input string has City and State values added on to it.

Britt

GIS Technician

City of Auburn, AL

[JeffWard]

Is the address table consistent in having the address separated from the city and zone by a comma?  It's not ideal, but you could run it through a script that would strip out the address portion. Or in the field calculator you could use python - !ADDRESS!.split(',')[0]

[BrittJohnson]

Jeff,

The address reference data tables do not have any zone information at all. However, some addresses using our locators are pulled from other software systems (billing, etc) that have a City/State added to the end of the address string. It may not be feasible to change up how those systems report addresses; hence why we are looking at customizing the address locator first.

[SeanMurphy1]

Since your reference data doesn't have the zone information, you should process the table you are geocoding as Jeff suggests. Remove the zone information from the input table before you geocode. Like Jeff suggested, the split() function might be useful for that.

The problem with creating a style file modification to fix problem is that there is nothing to set the zone information to (in the reference data) when creating the address locator. When you run the created locator, it thinks that that info is missing by default (since that's what you set in reference data), even if the zone information is in the address you're trying to geocode. In other words, the locator thinks that the house number, street, city, state is all part of the house number, street.

It sounds like getting street data with zone info is most ideal...

Sorry I couldn't be more help.

[JoeBorgione]

I've been following this thread and am drawing some parallels with one I authored a couple weeks ago:

10.2.2 Alternate Names Geocoding Does Not Return Matches

Jeffs first suggestion of creating a composite was the first work around that was suggested to me for my problem.

I wonder if the same sort of work around that I ended up with can be added here; add the zone fields to the data you are matching to but calculate the values to empty.  ( "" doublequote doublequote instead of null.)  Might be worth a shot.

[BrittJohnson]

Thanks for the ideas guys. Adding some blank zone fields possibly could be a solution for us, I will have to test that out and see how it works with our data. As for the input addresses; those are coming out of our financial and billing software systems through Cityworks (where the locators are being consumed). It isn't a certain that we couldn't change how the addresses are stored in those other systems, but that would have to be last resort for sure.

Sean, you mentioned:

"In other words, the locator thinks that the house number, street, city, state is all part of the house number, street."

That seems to be how our point locator (built off a different XML template) does work. Our address points also do not have any zone information, and any valid address fed into that locator will match to an address. If it is formatted without the City/St it returns a score of 100; if the same address is supplied with the City/St it returns with a score of 90. Now I can totally see how Tech Support would say that locator is functioning incorrectly, as "144 Tichenor Av, Auburn, AL" and "144 Tichenor Av, Oakland, CA" both match to the same address with a score of 90. That behavior isn't an issue for us, and that is how we were hoping to get this line locator to work.

On the line locator that we are having this issue with, one other thing I have noticed is that it doesn't have to be a formatted City/St added to the address sting for it not to return any matches. Including an apartment our suite number on the end ("500 Webster Rd 300" for example) gets no matches; but "500 Webster Rd" matches perfectly with a score of 100.

[JeffWard]

Ah, I thought you were using intermediate data that you could manipulate before geocoding.