Recently we took a call from a user who could not see the legend for one of the feature classes in one of our services. (Precambrian Bedrock in http://mgsweb2.mngs.umn.edu/arcgis/services/state/mnbdrkgeology )
After trying some standard things–restarting the service, checking the source .MXD–I turned to The Google Machine and quickly found help from ESRI: http://support.esri.com/zh-cn/knowledgebase/techarticles/detail/33741 .
Turns out the default number of legend items ArcMap will display from an ArcGIS Server map service layer is 100 and we had 102 in the problematic layer. (I plead innocence, blame the geologist for needing that many categories).
The solution was to edit the Windows registry and change the setting for “Maximum Legend Count” from 100 to something higher than 102. After doing that (see path note below) and restarting ArcMap, the legend showed for us.
The path turned out to be a little different on Windows 7 than the paths indicated in the help article.
ESRI indicated that the path varied by ArcGIS version:
- ArcGIS 9.3.x: HKEY_CURRENT_USER > Software > ESRI > MapServerLayer
- ArcGIS 10.0: HKEY_CURRENT_USER > Software > ESRI > Desktop10.0 > ArcMap > Server > MapServerLayer
- ArcGIS 10.1: HKEY_CURRENT_USER > Software > ESRI > Desktop10.1 > ArcMap > Server > MapServerLayer
I actually changed this in a number of locations–presumably once for each user profile on my machine. Each followed a pattern something like:
Out of cursiousity, I wondered if the 100 item limit was a per service or per layer limitation so I set my limit at 103. Because the service has several other layers, the total number of layers in the legend was about 130. Everything drew OK so it appears the limit applies per layer.
Testing one of our geodata services, we discovered that it allowed us to extract a portion of our feature class but when we tried to extract the entire data set, we received this Data Extraction error: Data extraction failed. Proxy or Gateway Server did not allow the URL. Check with your LAN administrator that Proxy or Gateway server is configured to allow the URL.
The fact that I was able to extract a portion of the data and I could see the entire geodatabase get made and zipped led me to believe it was more of time-out issue.
Reading through this thread at ArcForum led to some good information. But Thomas’ comment that he was using “IIS7 for my reverse proxy server” and had to change one more setting led me to the solution. In Server Manager, the default Proxy Time-Out is set at 30 seconds by default. I bumped that up, 60 seconds shown below but I ended up going to 300 seconds and the problem was resolved.
Someone mentioned an idea on ArcIdeas for making various display settings on a feature classes scale-dependent. Right now some of that can be accomplished by loading a feature classes multiple times, adjusting the settings, and setting the visible range. Working more and more in ArcGIS Server, I can see the value of increased scale-dependent settings.
I’m not sure how rapidly ESRI takes “Ideas” into consideration but if you feel like it would benefit you, why not promote this idea: Scale Range, SQL Query and Symbology Rendering in ArcMap.
Have a good weekend, all!
In building our Enterprise GIS Database, we need to support users with different needs. Some of our users just need to see the data on a map while others may want to download a copy of the data so they can use it within their own desktop system.
After doing some exploring, one of the options that looks like it will feel the bulk of our internal needs is to create a Map Service/Geodata Service pair–by creating a Map Service, we can make an easy-to-use visual representation of our data. Combining that with a paired Geodata Service–a Geodata Service with the same name as the Map Service–we can accommodate those users who want to extract the data to their hard drive.
A user who has added paired Map & Geodata Services to an ArcMap dataframe can use the Distributed Geodatabase Toolbar to extract data to a local geodatabase. The Extract Data button is on the far right of the Distributed Geodatabase Toolbar.
Unfortunately, my first attempts at testing this did not work. It would look like it was processing, I would end up with a .mdb or .gdb file on my hard drive but I could not open it. I would get a “Failed to connect to database. This release of the GeoDatabase is eitehr invalid or out of date. [Unknown GeoDatabase release.] The Microsoft Jet database engine cannot find the input table or query ‘GDB_ReleaseInfo’. Make sure it exists and that its name is spelled correctly.” error.
When exporting to an .mdb file, I could open it in Access and see the data.
Luckily the error is fairly helpful–I was getting an ArcGIS 10 Geodatabase even though I am running ArcGIS 9.3.1 on my desktop. I was able to open the exported geodatabases using a copy of ArcGIS 10 on another machine. The reason for the inconsistency is pretty interesting. Our office is, and for the foreseeable future, running in a mixed-version environment. We have a mixture of 9.3.1 and 10 desktops, a 9.3.1 ArcSDE server and a 10 ArcGIS Server. The Extract Tool is a server-side function apparently that creates a version 10 Geodatabase.
The way to get around this is to extract the data to XML and then import the XML workspace into a geodatabase. Not sure if that will work for all schemas but it was successful for me.