AnsweredAssumed Answered

Can't export a tile package from a map service cache using a geoprocessing service

Question asked by geonetadmin on Nov 19, 2013
Latest reply on May 8, 2014 by geonetadmin
Original User: jbailey.spatialbridge

The following (long) post describes the steps that we've taken to do something that should be fairly straightforward: using a geoprocessing web service, export a user-defined portion of a map service cache to a tile package. This seems like it should be a common use case, and there are various tools available for exporting a map service cache, but we've as yet been unable to do this.

If anyone can provide suggestions, they would be greatly appreciated!




Our client has an instance of ArcGIS Server that hosts a number of cached map services that are designed to be used as basemaps in a variety of applications. We have created a Silverlight Viewer for ArcGIS application that allows end users to browse and explore the collection of available basemaps.

From time to time, our client's end users will need to extract tile packages from these cached map services to be used as basemaps in ArcGIS Runtime applications. Typically, the user will define an area tens or hundreds of kilometres across to extract for one or more basemaps. 

In most cases, these end users will not have access to ArcGIS for Desktop. To accommodate these users, we intend to make this capability available as a geoprocessing service accessible as a tool in the Silverlight Viewer for ArcGIS application.


The first step to make this tool available in a web application is to publish it as a web service to ArcGIS for Server. This document describes three approaches that we attempted to create a geoprocessing service to export a map cache in ArcGIS for Server, and the problems encountered with each method.
The following map shows the test area that we used for these tests. It is a 1km x 1km area centred at 421 Richmond Road, Ottawa, Ontario, Canada. 


To avoid any potential issues with permissions and security settings, we ran ArcMap as the ArcGIS Server user (i.e., the same user that runs the ArcGIS Server processes) on the server machine hosting ArcGIS for Server. We also created a shared folder on this machine to which the ArcGIS Server user has Full Control permissions (both on the network share and on NTFS) to store the generated tile packages, and used the UNC path to this folder when specifying the output location.

Export Map Server Cache

The Export Map Server Cache tool allows a user to extract tiles from a cached map service to a tile package. It's located in the Caching toolset in the Server Tools toolbox. 

To begin, we ran the Export Map Server Cache tool in ArcMap to generate a valid geoprocessing result. the following screenshot illustrates the parameters used.


Following is the Python snippet that represents this instance of running the tool:

arcpy.ExportMapServerCache_server("GIS Servers/GEO-ARC-DMZ/World_Street_Map.MapServer","//GEO-ARC-DMZ/ExportMapCacheOutput","TILE_PACKAGE","DO_NOT_COPY","COMPACT","591657527.591555;295828763.795777;147914381.897889;73957190.948944;36978595.474472;18489297.737236;9244648.868618;4622324.434309;2311162.217155;1155581.108577;577790.554289;288895.277144;144447.638572;72223.819286;36111.909643;18055.954822;9027.977411;4513.988705;2256.994353;1128.497176","5","Feature Set","#","OVERWRITE") 

Initially, running this tool caused a crash in background processing. Turning off background geoprocessing and running the tool again crashed ArcMap. To resolve this problem, we restarted the server machine (including the ArcGIS Server instance hosting the cached map service). After restarting the server, we were able to run this process successfully. It finished in about 8m30s, and produced a valid tile package as output.

Next, we attempted to publish the result to ArcGIS Server. In the geoprocessing Results window, we right-clicked on the result, and clicked Share As > Geoprocessing Service.

On the first dialog in the wizard, we clicked Next.

We clicked Next to accept the default server connection and service name.

We clicked Next to publish to the root folder.

On the Service Editor dialog, we clicked Analyze to check the service definition before publishing. 

The following warning was generated:

SEVERITY STATUS CODE DESCRIPTION NAME TYPE DATA FRAME  High Unresolved 24032 Data source used by Task Export Map Server Cache is not registered with the server and will be copied to the server: GIS Servers\GEO-ARC-DMZ\World_Street_Map.MapServer ExportMapServerCache Tool Unknown 

This seems to indicate that the service can't be published because the server can't access the GIS Server connection file.  So, we copied the ArcGIS Server connection file to the c:\temp directory (ensuring that the ArcGIS Server user had access to the c:\temp directory), and re-ran the geoprocessing tool, this time using the ArcGIS Server connection file that we just copied to the c:\temp folder.

We then attempted to publish the new result to ArcGIS Server. However, the same warning was generated when analyzing the new service definition, indicating that the ArcGIS Server connection in the c:\temp folder isn't accessible. To remedy this, we registered the c:\temp folder with ArcGIS Server, and re-ran Analyze. The same warning occurred. Since it was only a warning, we elected to attempt to publish the service anyway. When publishing the service, the dialog indicating that data will be copied to the server was displayed.

Attempting to publish the service resulted an Error dialog with the message "Failed to create service definition."

Thinking that the problem might lie with using an ArcGIS Server connection file, we attempted to use the map service's REST URL to specify the map service. We believed that this shouldn't work, because the REST URL isn't the correct data type for this input, and because an administrator connection to ArcGIS Server is required to export a map cache. In fact, pasting the REST URL for the map service in the Input Service parameter text box in the geoprocessing tool resulted in an error.

Export Cache

Next, we attempted to use the Export Cache tool, located in the System\CachingTools folder in ArcGIS Server. This tool appears to be a worker tool, and not intended for end users, since it appears to have no associated documentation. However, we attempted anyway. The following figure shows the parameters used when we attempted to run this tool.


Running this tool resulted in an error on the server. Following is the error message displayed in the geoprocessing Results window:

Submitted.  Executing...  ERROR 999999: Error executing function.  ArcGIS Server requires a service type (ParentType) and a server object extension type (Type).  Failed. 

Export Tile Cache

Finally, we attempted to export the tile cache directly (bypassing the map service) using Export Tile Cache tool found in the Tile Cache toolset in the Data Management Tools toolbox.  The following figure illustrates the parameters that we used when running this tool.


The messages generated by this tool appear to indicate that there would be 2 parallel processes performing the work:

Messages  Executing: ExportTileCache \\ARCGISDATAAPP\cache\World_Street_Map\Layers \\GEO-ARC-DMZ\ExportMapCacheOutput World_Street_Map TILE_CACHE COMPACT 591657527.591555;295828763.795777;147914381.897889;73957190.948944;36978595.474472;18489297.737236;9244648.868618;4622324.434309;2311162.217155;1155581.108577;577790.554289;288895.277144;144447.638572;72223.819286;36111.909643;18055.954822;9027.977411;4513.988705;2256.994353;1128.497176 "Feature Set"  Start Time: Tue Nov 19 13:12:39 2013  Exporting tile cache using 2 parallel instances.  Exporting tile cache for feature with OID: 1.  Exporting cache for scale: 591657527.591555. 

The Resource Monitor indicated that there were, in fact, 2 Runtime Local Server processes running, but it appeared that only 1 instance was doing anything.

At the time this document was written, this process was still executing. We estimate that it will take roughly 7.5 hours to complete export a 1km x 1km tile package using this tool, so clearly this doesn't seem to be viable solution.