Geocoding -- 10 vs 10.1

5872
24
Jump to solution
07-10-2012 11:22 AM
MarkParr
New Contributor
I am running 10.1 ArcDesktop Standard and testing geocoding of some existing Shapefiles.  I have some previous 10 locator files that still exist and that work when I do an address FIND search.  I am defining my 10.1 locator files using the exact same paramaters/fields previously used for the original 10 locators.  However, when I do an address FIND with my new locator, the results consistently return nothing back.  If I search using the older 10 created locator I get results. 

Any ideas?
Tags (2)
0 Kudos
1 Solution

Accepted Solutions
ShanaBritt
Esri Regular Contributor
A standard practice that I have seen when it comes to geocoding addresses at the local level is to create an address locator that does not include zonal attributes (city, state, zip, emergency service number, community name.... are not mapped in the field mapping) and just find or geocode a list of addresses with just the house number and street name. The reason that the locators created without zone field mappings based on the Dual Range locator style at 10.1 do not find any matches is because the default setting for the 'supportsOptionalZone' property in the rules is set to false/no. This property determines whether or not addresses will be found or matched if a zone is not included in the input address in the geocoding toolbar, find tool, or batch geocoding.

To enable the supportsOptionalZone property of an existing address locator created at 10.1 use the following steps. Setting this option to "yes" will affect the performance for larger geographies.

1. In ArcCatalog or the Catalog window, right-click the address locator
2. Click Propertiesâ?¦
3. In the Geocoding Options section change 'Match with no zones' from â??noâ?? to â??yesâ??



Locator performance properties

-Shana B

View solution in original post

24 Replies
MarkParr
New Contributor
Just an update:  I have a new set of shapefiles that I have not done any processing with in either 10 or 10.1 before today.  I was not having any luck w/ these shapefiles while trying to geocode/find addresses using 10.1 which is why I tried some other shapefile data w/ version 10 locators previously defined.  I copied these shapefiles files over to a PC still running ArcView 10, created an address locator using the the US Streets - Dual Range locator type and same field names that I was using with the 10.1 locator that continually does not find anything.  The version 10 location successfully returned a test address point when doing an address find from within ArcView 10.
0 Kudos
BruceHarold
Esri Regular Contributor
Hello Mark

Please log a support call on this issue, and if you can, share the shapefiles you are using.

Regards
0 Kudos
SergeyBayshev
New Contributor
Experiencing same kind of problem using a composite locator built of 4 custom address locators. Everything is working fine and we are getting results with ArcGIS 10.
In ArcGIS 10.1 the locators are building without any errors, but only 1 of 4 locators returns results. No results returning for the rest 3 locators.
0 Kudos
MarkParr
New Contributor
Experiencing same kind of problem using a composite locator built of 4 custom address locators. Everything is working fine and we are getting results with ArcGIS 10.
In ArcGIS 10.1 the locators are building without any errors, but only 1 of 4 locators returns results. No results returning for the rest 3 locators.


I created an incident w/ Support last Fri.  Still waiting on a resolution but the word from the intial tech was that he was seeing the same issue.  Post from him yesterday made it sould like the issue was being pushed up to someone higher in the support process................
0 Kudos
MichaelRivera
Occasional Contributor II
I am also having big problems geocoding in 10.1
I wasn't sure if factors like the roads shapefile road name field being in upper / lower case so I added a new field in the roads all upper case road name. I then did the same with road type.  These roads have a issue where some road ranges are correct with a from-left of 1 and a to-left of 99 for instance, some are reversed.  I don't know why the address ranges are like that.  I built a dual range address locater in 10.1 and only 2 adresses matched out of 30,621.

A co-worker built an address locater in 10 and she ran it against the crime database using the same roads and she had a 58% match.

I used her 10 locator in 10.1 and I got a 53% match.

Why did her 10 locator work so much better than my 10.1 locator?
0 Kudos
MarkParr
New Contributor
Michael:

Not sure what is going on w/ the locators between 10 and 10.1 -- I am still waiting on an answer from ESRI support.  Still haven't spoken to the second tier support person that the first tier person indicated might be calling.

As a test, I created a centerline/street layer shapefile from scratch consisting of 2 intersecting streets and 4 line segment (1-100 and 101-200 N MAIN ST and 1-100 and 101-200 W ELM ST), created a dual range street locator for these segments, and could not find any address that I typed..................

That was with 10.1 -- I have not moved that layer over to 10 yet to try.

I would suggest create your locator in 10 and use it in 10.1 if you need to proceed w/ anything that you are doing.
0 Kudos
MarkParr
New Contributor
Just got off the phone w/ ESRI technical support.

Turns out this problem is a bug or two that will be resolved in 10.1 SP1 when it's released.  No ETA on that release at this point.

In the meantime, the solution is to provide a City and State (even if it's just dummy values) as part of your Dual Range locator creation and use those during your address search and the geocoding should work.
0 Kudos
MarkParr
New Contributor
Just tested the recommended solution and it worked.  I was actually able to create a locator w/ just the "City" as part of my Address Locator in 10.1 and have the Find command find the address.  City, State also worked when I included that in the locator and the Find/Search.
0 Kudos
MichaelRivera
Occasional Contributor II
That is great news.

Glad there is a workaround and glad it will be addressed in the next service pack.
0 Kudos