Layers fail to draw when generating tile cache in AGS

Question

I recently created an MXD-based map service on AGS 9.3.1 SP2. The map seems to render fine as a dynamic service, but when I convert to a cached service and attempt to generate tiles, the operation fails:

ERROR 000569: Failed to generate cache. All server contexts failed to cache map.
Failed to execute (ManageMapServerCacheTiles).

The following lines show up in the server error log:

<Msg time='2011-06-30T17:27:25' type='ERROR' code='103800' target='service.MapServer' methodName='Map.Draw' machine='hostname' process='3248' thread='2756'>Streets 1-2: The operation was attempted on an empty geometry.</Msg>
<Msg time='2011-06-30T17:27:25' type='ERROR' code='10003' target='service.MapServer' machine='hostname' process='3248' thread='2756'>Failed to draw layer Streets 1-2</Msg>

Frankly I'm not sure where to go from here. As I said earlier, the service renders fine in a dynamic configuration. Any ideas?

Answer 1

You need to check the scale settings in your MXD/MSD file for your various scale levels. As you move through the various scale factors you want to have buffer. So if you are building using WebMercator and say you are at scale 1:4,622,234 then set you max scale to be 7,000,000 and your min scale to be 3,750,000. This way as AGS is moving through the scales it will not get to a exact scale and see null layers since they are between factors.

Answer 2

I've seen error messages similar to those in your log about empty geographies. I would check the underlying dataset (Streets 1-2) for features with empty geography, delete them and see if that helps. Add the dataset to a geodatabase, sort on the shape area field and delete those that have 0 area. As to why things work as dynamic service but fail during caching I have no helpful ideas.

Answer 3

This link from the ArcGIS Desktop 10 help lists the reasons for the Error 000596. It is applicable for the 9.3.1 version as well.

Whenever I've run into this error, it was because of point one, 'Ran out of memory'. To counter this, I've always set the number of map service instances creating cache to be one less that the number of cores (unless you have only one core; then just set one instance). This is because every service instance creating cache maxes out usage of a CPU core (especially if you have low clock speeds). I keep one core free just so I can do other tasks when cache is getting created. The GP tool 'Manage Map Server Cache Tiles' used to create cache has the option to the set number of instances to create/update cache tiles.

Esri recommends number of cores + 1. Unsure about the reason for this but since it is a recommendation, you can try this out as well. Hope it helps.

Answer 4

Thank you for all the thoughtful responses. The solution was rather different from anything mentioned, so I will describe it here.

As it turns out, my data frame's extent was much larger than the extent of the data. In fact, all my data was clustered in the far SW corner of the data frame's extent. After defining a more appropriate extent, I was able to build the tiles with no problem whatsoever.

If anyone can explain this, I would love to hear it.

Answer 5

What type of data source are you using for the Streets 1-2 layer? If it is not and SDE geodatabase, run Data Management Tools > Features > Check Geometry against your source data. If you encounter any problems, try Data Management Tools > Features > Repair Geometry

One way I can think of that this can occur is if you have a multipart feature where one part has an empty geometry. This is impossible in an SDE geodatabase, but very possible to do in other source data types. This would make it possible for the empty part to have a spatial extent and be drawn when creating cache tiles, but still be an empty geometry that cannot be rendered. In dynamic rendering, the entire feature, rather than just the part, could be pulled, avoiding the empty geometry error; or maybe an empty geometry is not a fatal error for dynamic rendering.

Or, you may simply have an empty geometry sitting at the false origin. While it never gets rendered in a dynamic service call, it is rendered for tile caching. You could test this by generating an empty cache and updating only a specific spatial extent. If this works successfully, you probably have an empty geometry feature sitting at the false origin.

Either way, you can find these problems with Check Geometry on the source data.

To add to this, after seeing what the original problem was:

I think that geometries are also simplified when drawn at small scales. If you had polygon geometries (maybe polyline too), and your data frame extent was much much larger than the extent of your data, then it is possible that the simplification of the polygon geometry turned it into a single point. Thus, there was no outer ring and the polygon had a null geometry, throwing the error that you encountered.