Latest Contributions by SterlingQuinn

Esto quiere decir que estás tratando de publicar un servicio demaciado grande para tu cuenta. Puedes recibir este mensaje si tu data incluye muchas entidades o estás trantando de crear muchisimas teselas de cache (por causa de incluir escalas grandes o una amplia extensión de mapa). Sugiero que pruebes un MXD mas básico al principio, con escalas chicas si intentas crear teselas de cache. Sterling ... View more

Hello Travis. For a variety of reasons related to performance and reliability, it's not recommended that you include an ArcGIS map service within another map service (aka "cascading" services). ArcGIS Server 10.1 won't even let you publish a service like this. Instead, your client application should connect directly to the services. So you might have a layer in your web map that refers to your imagery basemap web service and a separate layer that refers to your business data such as snowplows, ATMs, homes for sale, or whatever it is you're mapping. If you play around with the ArcGIS.com map viewer, you'll see how this works. The viewer loads a basemap service for you. And then you connect to other services and place them on top. You're able to make a nice mashup without embedding any service within another service. Sterling ... View more

The files that you listed only exist in 10.0. The migration checklist suggests that you make a backup of them before you migrate to 10.1. There are a couple of reasons for this. You might want to apply these files if you decide to roll back to 10.0. You can also use them as a reference when setting properties on your new 10.1 services, since you must republish all services at 10.1. The 10.1 equivalent of these files is the "configuration store", although you should not edit the configuration store files manually. Sterling ... View more

Steve, At 10.1, an ArcGIS Server site is composed of one or more GIS Server machines.  Each GIS server in the site has some intelligence about what the other GIS servers are doing. Therefore, the site is able to balance the load among the available machines. This also makes the site elastic, such that when you add or remove a machine, the site can automatically adapt. You can access any service directly from any GIS server machine in the site. So if you have two machines in the site, there are potentially two URLs you could use to access a service. However, in practice, most people will use one URL. Production deployments of ArcGIS Server should use the Web Adaptor, which provides a single point of entry for your GIS server. This is what you would reference in your Flex apps, etc. The Web Adaptor passes the requests on to the GIS servers. When you publish a service, a copy of your map is placed in the server directories (which are located at a path you specify when you create the site). See these deployment scenario diagrams for options of where you can put the server directories and your GIS datasets: http://resources.arcgis.com/en/help/main/10.1/0154/015400000488000000.htm  Best wishes, Sterling ... View more

The way to avoid data copying is to register your data locations with ArcGIS Server. This is a new concept in 10.1 that is explained here: http://resources.arcgis.com/en/help/main/10.1/0154/015400000505000000.htm The automatic data copying can sometimes be useful if you don't have the means to log into the server. But most users will register data locations to prevent the copying. If you're interested, the copying behavior is described here: http://resources.arcgis.com/en/help/main/10.1/0154/0154000003rn000000.htm As you discovered, ArcGIS 10.1 for Server keeps its own copies of the MXD, MSD, and SD for each service, and you'll see them if you dig around enough. There is no way around this, but these files aren't meant for you to modify. They're used internally by the server. If you make changes to your source MXD, you need to go through the publishing wizard again but choose the option to "Overwrite an existing service". See http://resources.arcgis.com/en/help/main/10.1/0154/015400000297000000.htm   If you registered your data locations, then no data copying will occur during the overwrite. It will only overwrite the server's copy of the MXD. Sterling ... View more

Fabrice- I am wondering if you noticed or tried this step in the build instructions, which are found about halfway down in the link you referenced: "1. In the Solution Explorer, right-click the SpatialQueryREST.Manager project, and click Build. If your project fails to build and you are running ArcGIS 10.0 Service Pack 1, you might need to add one more string argument, serviceTypeName, to LoadConfigurator in your Configurator.cs code file. For example, the C# implementation of the line of code defining LoadConfigurator looks like the following: public string LoadConfigurator(ESRI.ArcGIS.Server.IServerContext serverContext, . . ., string servicesEndPoint, string serviceName, string serviceTypeName)." This applies to any service pack with 10.0. Best wishes, Sterling ... View more

This article on the wavelet compression error has some good insights: http://help.arcgis.com/en/arcgisdesktop/10.0/help/00sq/00sq0000000t000000.htm   What you did with building the test cache is the right approach. But as long as you stay with the SIDs, it will probably take 17 days. Depending on how much space and imagery you're dealing with, a faster alternative might be to create JPEG or TIFF copies of your imagery and then cache that (as JPEG). Although JPEG is a lossy format, the loss cannot be easily spotted by the untrained eye if the compression quality is high enough. (In our experience, you can get away with a quality down to even about JPEG 55 before you really start seeing a difference- but if you're caching a JPEG of a source JPEG, you should run your own tests on quality to find the most acceptable level). If the imagery copies are going to be for visualization only, then some loss of data doesn't matter. If you're going to do some kind of analysis or processing on the imagery, you can go back to the source SIDs. Sterling ... View more