nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Rebuilding address locators

MikeAdams

I am using ArcGIS 9.3.1. I created several address locators, but when I attempt to rebuild any of them, ArcCatalog tells me "You cannot rebuild this address locator. The address locator was created using a release of ArcGIS previous to ArcGIS 9.2. Please create a new address locator." All of these address locators were made using ArcGIS 9.3.1.

Find more posts tagged with

Accepted answers

All comments

JasonMcKeefry

Maybe I missed it somewhere in here, but I just had this problem on a locator I know was made prior to 9.2. Therefore, the error message was not accurate. Instead, something had corrupted the locator. In my case, I noticed that all the other locators alongside this one had a file named <your locator name>.lox , except the locator that cause this error. My workaround was to copy one of the other .lox files and rename it to have the same name as the broken locator. That allowed me to rebuild the broken locator.

CarmenGonsalves

Hi Wesley,

I had a similar problem. I had opened the Geocoding Toolbar at the top of 10.5 to make it easier to access the functions. I discovered for whatever that I had to open the <Manage Address Locators> option and remove the locator I wanted to rebuild. If I didn't remove it from the list first, it would error and tell me I could not rebuild it. Hope this helps!

KatieBrander

I tried for months to get an automated python process going to update address locators similar to the method you described. If you haven't yet discovered, the bug that corrupts address locators when attempting to rebuild an empty table still exists in ArcGIS 10.2.2. Furthermore, even when there is data in the source table, I found that using the arcpy function to rebuild the address locator would inevitably corrupt them sooner or later! In the end we decided it was safest to do a manual rebuild in ArcCatalog - but even this fails sometimes with an error message simply stating "Can't rebuild address locator". Sadly, it seems the only reliable method is to manually delete and re-create address locators every time.

MatthewBaker2

I'm having the same issue with 10.1 SP1.

I started the thread linked to above about slow performance of locators in SDE, so following the answers to that thread, built all my locators in a simple folder, and have been having great results for some time.

However, suddenly yesterday all our locators are corrupt with the error mentioned in the posts above and subject of this thread.

There seems to be no reason why this is happening...?

-m

AnthonySchaffer

Well, I took the advice and now store address locators on a local drive on the ArcGIS server, rather than in a database.

However, I am getting the same error that "You cannot rebuild this address locator.   The address locator was created using a release of ArcGIS previous to ArcGIS 9.2.   Please create a new address locator."

My address locator was created using ArcGIS 10.1 SP1, which hopefully is not "previous to ArcGIS 9.2".   I had to create it from scratch to place it outside of the SDE database.   Once created, the locator works fine; it participates in a composite locator that in turn is used by our published geocode service.

I have a nightly python script that rebuilds all of the contributing address locators (yes, it first stops the geocode service before running the rebuild).   The first locator rebuilds fine; the second fails in the script and again when I try it manually in ArcCatalog (thus the message above).    I don't know whether the rebuild attempt causes corruption - or how, since it uses the standard Python arcpy.RebuildAddressLocator_geocoding(locator) function.

Update: I noticed that the when this happens, the feature class that the locator is based on was empty (a bug in a separate script that refreshes it).   The feature class did exist in SDE, but had no records/features.   Apparently attempting to rebuild a locator against an empty source dataset will corrupt the locator and the only solution is to delete then recreate it from scratch.   To the ESRI folks, it would be preferable for the RebuildAddressLocator_geocoding function to return an error or perhaps a warning in this situation rather than the current result; has this been fixed in 10.2?

JanelleLuppen

"I have received the same message about the locator having been created from an earlier version, even though I created it last week in 10.1. Also, it was not created inside a geodatabase, just in a regular directory, and no SDE was involved at all."

KimOllivier

Maybe we get lulled into placing the output in the same database when the message "All sources must be in the same database" pops up? It does make a tidier workspace to put it with the sources. The locator is 3 files not just one, but in ArcCatalog you only see one entry. But I am now straightened up to place them in a plain old folder.

Also note in the fine print that you need the locator in a folder to use multiple threads. Since we all have multicore processors why would we not use them all to get better performance, especially on large datasets?

BradNiemand

I forgot to answer one of your questions:

We don't have any official documentation on this as of right now but we will definately add it for the next release. Here are some forum posts that suggest the same thing.

http://forums.arcgis.com/threads/92913-slow-geocoding-on-locator-stored-in-sde

http://forums.esri.com/thread.asp?c=93&f=1113&t=269905

Brad

BradNiemand

Anthony,

You can think of a locator as a database in itself. It contains data records and indexes that are all within the locator (.lox file). When storing it in a GDB, the .lox file is stored as a blob in the database with a field in another database table that links to that blob. So essentially you have a database that is stored in another database. As you can see, there is really no use for that locator to be in the database because it is already optimized with indexes and therefor it doesn't need to use the benefits of a database, it's own indexes.

Now to address your other comments which are valid:
a) it will be backed up along with the source data
    - This can be useful but is it worth the performance hit?
b) one less data store to register with ArcGIS server (including security credentials)
    - You are correct but this is a one time thing
c) security of the locator data is controlled through the database, rather than separate file level security, so one less thing to manage/debug
    - Once again you are correct. The security can be managed at the database level as opposed to having to manage it at the OS level as well.

Let me also state that there is no restriction, at this time, to storing locators in GDBs but we just suggest, for performance reasons, not to do it.

Hopefully I have clarified some of your concerns but feel free to respond with any others.

Brad

AnthonySchaffer

Anthony,

There is really no benefit with storing a locator in a geodatabase because a locator is all inclusive (it is a snapshot of the data). Also, the database overhead with storing it there has no benefits and will also cause a significant performance slowdown.

Brad

Brad,

If that's the case, then again, where is this documented? It is not in the ArcGIS Help regarding address locators. Also, why then the right-click option to create one in the geodatabase? Do you see the inconsistency here: your answer implies that ESRI software is condoning a practice that ESRI Support recommends against.

You state that doing this will cause a "significant performance slowdown".... based on what? Database access can be as fast or faster than simple file access. Databases do not exist only to store dynamic data; storing relatively static database (i.e. snapshot) in a database is very common.

I can think of several benefits to storing a locator in a geodatabase:

a) it will be backed up along with the source data
b) one less data store to register with ArcGIS server (including security credentials)
c) security of the locator data is controlled through the database, rather than separate file level security, so one less thing to manage/debug

BradNiemand

Anthony,

There is really no benefit with storing a locator in a geodatabase because a locator is all inclusive (it is a snapshot of the data). Also, the database overhead with storing it there has no benefits and will also cause a significant performance slowdown.

Brad

AnthonySchaffer

So you are creating a locator within an SDE geodatatbase? I would suggest you not do that, but rather keep it in it's own directory. No problem to access or point to data in the SDE database, but it's much better practice not to store a locator as an object of any flavor of geodatabase; SDE, file, or personal. You've already made a case supporting this, right?

Why is it not good practice to place an address locator within a geodatabase? I have never seen such recommendations in any product literature. And creating an address locators is one of the options available when right-clicking on a geodatabases connection in ArcCatalog.

BrianOevermann

Kim, and Wesley, and Katherine, and ...

Joe's remarks are spot on.

Kim, your workaround of copying the locator out of your file geodatabase to package it up sounds like a huge time-waster if you plan on doing this more than once. I would suggest taking the time to re-create your locators outside of the geodatabase (or perhaps you can copy the existing locators out permanently).

To do so:
- Create a folder wherever you want to store the locator(s). It should go without saying that this folder should have permissions set to allow access to whichever users need these locators, including the ArcGIS Server account if you want to register this folder with Server.
- In ArcCatalog, navigate to the folder and open it up.
- Right-click and select New-->Address Locator (or Composite Locator...)
- Construct your locator

I have my locators in a folder on my map server , which I can access via a mapped drive for administrative tasks like rebuilding as well as consuming them in ArcMap. This folder is registered with Server, so the individual locators do not need to be copied to ArcGIS Server when publishing them. Only my composite locator is copied to ArcGIS Server (because that is by design).

I am operating with a single map server, so your architecture may prevent you from using this methodology. You could put the folder anywhere on your network that allows your ArcGIS Server account to access it.

Regarding rebuilding the locators: I haven't used the ArcToolbox tool to do so, but use the right-click context menu option, which basically runs the same underlying process. I have found that successful index rebuilding is hit-or-miss unless any map services containing the data used by the locators have been stopped. No errors are thrown, I simply can't get new addresses to be successfully found without stopping the map services first. The locator indexes never seem to get re-written otherwise. [Maybe Joe has a solution for MY issue?]

KimOllivier

I have never got the locator rebuild tool to work. Ever. I wonder what the tool is for!

My solution is to save the result tool that creates the locator in the first place and re-run it again from scratch.
I put the results into a small script with a copy-as-a-python-snippet and then use that.
It only takes a few minutes to build a new one so you are not saving much time.

I write the locator into a local file geodatabase, but this does not package properly for someone else, so I copy the locator into a file before packaging it to copy it into ArcServer.

JoeBorgione

I did not create locator in the sde geodatabase, created with the User SDE in my geodatabase.

Not good practice at all to use the SDE for anything other than administrative purposes.

WesleyAntal2

I did not create locator in the sde geodatabase, created with the User SDE in my geodatabase.

JoeBorgione

I try with user sde and it's work.

must be something about permission!!!

So you are creating a locator within an SDE geodatatbase? I would suggest you not do that, but rather keep it in it's own directory. No problem to access or point to data in the SDE database, but it's much better practice not to store a locator as an object of any flavor of geodatabase; SDE, file, or personal. You've already made a case supporting this, right?

WesleyAntal2

I try with user sde and it's work.

must be something about permission!!!

BenDrury

I am experiencing this same issue with ArcGIS Desktop 10.2.

I initially tried to rebuild an existing locator that was created with 10.1 and received the error "Can't rebuild locator". So I deleted it and tried recreating it. It initially appears to have successfully created the locator, however, if I try to rebuild it kicks out the error "The address locator was created using a release of ArcGIS previous to ArcGIS 9.2. Please create a new locator." And if I try to use it to create a composite locator it will not populate any 'Field Map' values.

Anyone else having these issues?

WesleyAntal2

I'm also with this problem, but used ArcMap 10.2

Join the Conversation

Signed in members can post, follow updates, and more. New here? Register a free account.

Quick Links

Community Help
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.