topic Re: Publishing a composite locator- registering data store in ArcGIS Enterprise Questions

Publishing a composite locator- registering data store

BrianOevermann — Wed, 22 Aug 2012 20:06:29 GMT

I have a folder on the server containing the individual locators that make up the composite locator, as well as the composite locator itself. The folder is registered and I have successfully published the individual locators with no issues.

When I attempt to publish the composite locator, the Analyze result informs me that the "Composite locator will be copied to the server" with a Code ID of 30009.

Is there a reason the individual locators can be published without copying but the composite locator cannot? I must be missing something.

Re: Publishing a composite locator- registering data store

MarcWeinshenker1 — Mon, 28 Jan 2013 15:46:12 GMT

Did you ever get an answer or other resolution on this issue?

Re: Publishing a composite locator- registering data store

BrianOevermann — Mon, 28 Jan 2013 17:06:14 GMT

Marc,

After not getting any response through the forum post I opened a support request with tech support. The response was, to paraphrase, that composite locators get copied to the server by design. There is no way to publish a composite locator that is pointed to another location on your network, unlike the locators that are participating in the composite.

Sorry that I neglected to follow up with my own solution. I guess with no response that I didn't feel anyone else cared to know the solution.

Re: Publishing a composite locator- registering data store

MarcWeinshenker1 — Mon, 28 Jan 2013 18:33:25 GMT

Brian,

Thanks. You didn't mention it, but does publishing your composite locator also copy the individual locators even if they are already published? That's what happened to me.

Marc

Re: Publishing a composite locator- registering data store

BrianOevermann — Tue, 29 Jan 2013 13:45:50 GMT

Marc,

So, a little background...
When I created my locators (including the composite), I saved them in a folder called 'Locators' (original, I know) on the map server. As an aside, I also have a folder there that has all of the .mxd projects that create all of my map services. The data is on SDE or in a file gdb library area, all registered with the server.

Just like you, I have published each of the individual locators separately, then I publish the composite locator which gets copied to the map server.

On the map server, my composite locator is sitting here:
\arcgisserver\directories\arcgissystem\arcgisinput\geocode_services\<my_composite_locator_name>.GeocodeServer

Inside that folder, like all map services, I have an 'extracted' folder that contains an 'esriinfo' folder.

There are folders for each of the locator services in the 'geocode_services' folder with the same structure as above. In the composite locator folder, however, there is an additional folder called 'v101' that contains the .loc and .loc.xml files.

These two files make up the actual locator. These files exist in my 'Locators' folder mentioned above for the rest of my locators. I don't believe it is simply because I happen to have them in a folder already on the server itself that they are not copied into the same structure as the composite locator. I think they could easily be anywhere on the network as long as the folder is registered with the server.

So with all of that said, are the .loc and .loc.xml files getting saved to a 'v101' folder for your other locators or are you simply seeing the individual folders that are normally present? I am assuming that you have registered your locator folder location, otherwise you would see the obvious warning message that the locators will be copied to the server (like you see with the composite).

Re: Publishing a composite locator- registering data store

MarcWeinshenker1 — Tue, 29 Jan 2013 16:57:05 GMT

Brian,

Thanks for the detail. My individual and composite locators are all in SDE, which is registered. My first attempt at publishing was just the composite locators and I was warned that the individual locators would be copied to the server along with the composite locator. This can be seen as well by running Analyze. The other day I decided to see what would happen if I published the individual locators first. That worked well and no data was copied to the server. But when I next published a composite, it insisted on again copying the composite and both individual locators to the server. So, I stopped that process, deleted the locator services and went back to the way I did it the first time.

Looking at the composite locator service files under extracted\v101 I do see the .loc and loc.xml files for the composite and then folders named 00 and 01 for the individual locators. Those folders have .loc, .loc.xml and .lox files, where the .lox file is large and I assume is an index file for the locator.

While the copying of the data does not bother me, what does is having to remember to republish every time I update the locators. Updating a feature class does not require updating all services using that feature class (good thing, eh?), so this is annoying.

Marc

Re: Publishing a composite locator- registering data store

BrianOevermann — Tue, 29 Jan 2013 17:15:15 GMT

Marc,

I wonder if your experience is due to the fact that these are SDE locators. I have no idea--maybe an ESRI employee will lurk by and have some knowledge to impart regarding that.

When I upgraded Server from 9.x to 10.0, I completely rebuilt my locators because of the new underlying structure. And when I upgraded to 10.1 I again completely rebuilt my locators.

So, all of the info and experience I have shared is based on locators created using 10.1. The underlying data those locators reference is in SDE.

The "republish after rebuild" is a complete pain. My plan is to script a nightly process that takes care of this and other Server-related maintenance headaches but I haven't had a moment to do that. Fortunately, we aren't adding streets and site addresses by the boatload right now so it is reasonable to keep up.

Re: Publishing a composite locator- registering data store

MarcWeinshenker1 — Tue, 29 Jan 2013 17:27:02 GMT

Brian,

It's a mystery. Another possible factor is that my SDE is still at 9.3.1 and will be there until all clients are up to 10.1, and that's a ways off. Anyway, at least it works, unlike other Server 10.1 problems I'm dealing with.....

Marc

Re: Publishing a composite locator- registering data store

ScottKearney — Mon, 09 Dec 2013 19:20:24 GMT

Did this issue change for the better in 10.2? Another words, do you still have to rebuild the composite geolocator in sde and republish to AGS? The non-composite locators only require rebuilding.

Re: Publishing a composite locator- registering data store

BrianOevermann — Mon, 09 Dec 2013 19:52:54 GMT

Scott,

I have yet to move us to 10.2 so I cannot answer your question. The other contributor to this thread--Marc--seems to have been lagging even further behind (he indicated he was on 9.3.1 with his locators). Maybe someone else will view this thread and be able to comment. I am looking to upgrade after the first of the year if I can juggle the schedule enough. If I remember, I will respond with my experience after.

And to clarify, my locators are built from within ArcCatalog against SDE data. I believe Marc's locators were built within SDE.

Re: Publishing a composite locator- registering data store

LeightonWedderburn — Thu, 17 Apr 2014 14:57:44 GMT

I think I have found a work around for this problem.

After encountering the same problem some of you have come across I did the following.
1. Published all the individual locators using a windows authenticated database connection(not sure if it matters if all are windows or database authenticated but I made sure they were all created the same way... more likely a matter of have permissions configure properly but could be an issue with either or both I'm not sure).
2. From a remote connection to the server where the services reside. I then created the composite locator(in the same manner), making sure that the composite locator functioned properly in ArcMap after creation, then I made the needed property changes. Note: When I Created the composite locator I limited the custom field changes only using the default fields when they were brought in to create the composite address locator from the tool in catalog:' singlekey, city, state, and zip'.
3. I then published a service definition .sd file which copied the locator(s) data/information to a server accessible folder.
4. Opened ArcGIS Server Manager and published form there using the .sd file.
5. Bam!! I had a Composite Geolocator Service that worked.

Re: Publishing a composite locator- registering data store

TomResh — Fri, 08 Aug 2014 16:23:21 GMT

I was not able to publish a composite locator when I was trying to publish it from the ArcGIS server computer but when I published it from my workstation it was successful. The composite locator is in sde.

Re: Publishing a composite locator- registering data store

BugPie — Wed, 03 Dec 2014 15:12:13 GMT

Has anyone heard from ESRI or know what the best practice is for storing locators? I have read that it is recomended that you store locators in a file folder and not the SDE? Any truth to this?

Re: Publishing a composite locator- registering data store

MarcWeinshenker1 — Wed, 03 Dec 2014 15:55:05 GMT

When I last spoke with Esri about this (don't recall how long ago), I was told that keeping locators in SDE was not good. I have since moved my locators to a file GDB, with the location registered in ArcGIS Server as a data store, and all my problems with geocoding were resolved. I'd prefer if they would do what it takes for locators to work properly when stored in SDE, though.

Re: Publishing a composite locator- registering data store

BugPie — Wed, 03 Dec 2014 16:01:37 GMT

Hi Marc, thanks for your response. I'm not sure why locators would be better if you do not use the SDE, seems a little backwards to me. ? In any event, I have mine stored in a standard file folder, registered as a data store and things run well.

Thanks agian for your input. Happy mapping.