Sterling Quinn of the ArcGIS Server team contributed the following post. This information will ultimately end up in the ArcGIS Server Help site in a few weeks.
ArcGIS Server for the Microsoft® .NET Framework has a scalable architecture that allows you to distribute its components among multiple machines. When you set up a distributed installation, there are a number of post installs, accounts, and operating system groups that you’ll need to configure. These requirements have changed at 9.2, so even if you have configured a distributed installation in the past, you may not be familiar with the latest requirements.
Below is a guide that shows what you’ll need to do on each machine. Each machine in the diagram contains some green text denoting which post install you must run on that machine. Items in blue are accomplished by the post install. Items in red are things that you must do. Note especially that you must manually add the ArcGIS Web services account on each dedicated SOC machine.
In the ESRI Web ADF for the Microsoft .NET Framework the default behavior for the mouse scroll wheel is to zoom in to the map control as you move the scroll wheel forward. Enter the following code snippet in the Default.aspx after all the Web ADF control declarations in your web application if you would like to change the behavior of the scroll wheel so that it zooms out as you move the mouse wheel forward (which is also how ArcGIS Explorer behaves).
mouseWheelAwayZoomIn = false;
Here is an example of the default behavior: http://serverx.esri.com/bendenaquadsp/
Here is an example of the changed behavior: http://serverx.esri.com/bendenaquadspreversescroll/
Welcome to the first of many posts on building, using, consuming, and deploying ArcGIS Server services. Today I want to touch on building a simple web application in the Web ADF for the Microsoft .NET Framework with cached data and a couple of Geoprocessing Tasks.
Have you ever developed a really nice TIN dataset? TINs are nice in that they can be built quickly, contain a lot of detail, and can be used to perform traditional GIS analysis. Let’s take the TIN dataset to the next step. Say we want to publish an application that uses a TIN in the new Web ADF but we want it to perform lightening fast AND be able to do analysis on it?
I have a TIN that I created with tagged vector contour data that I downloaded from the GIS Clearinghouse for the State of Kansas.
This TIN took about 20 seconds to draw to the screen from ArcMap. That is too slow to be useful for web mapping applications. Fortunately we can take advantage of ArcGIS Server 9.2 caching capabilities. The steps to publish data to server are as follows:
- Set up map document in ArcMap with featured dataset(s) rendered appropriately,
- Publish MXD to Server,
- Build fused map cache.
The map cache option in ArcGIS Server 9.2 is a really powerful feature. This allows you to create high performance web applications. Look for many more posts in the future about designing, building, deploying, and using map caches. It is a fascinating subject.
Back to work. The map cache that I created contains the following specifications:
- Tile size 256×256 pixels
- Image type PNG
- Fused map cache
- Cached at the following scales: 100k, 75k, 50k, 24k, 12k, 6k
Now that the service is ready we can build the web mapping application to consume it. The team has really done a lot here to help the developer AND the non-developer build web applications. The web application can be completely built and deployed remotely from the ArcGIS Server Manager. If the default application does not meet your needs you can customize the application in MS Visual Studio 2005.
It is really as easy as that. Try it out here:
Now while we get the performance of the cached TIN elevation data in the map service, we don’t want to lose the analytical capabilities of the original data. This is where Geoprocessing (GP) Services come into play. With GP services we can build models that run off of the original data using model builder and then publish those models to ArcGIS Server which can then be used in our web applications. In this example I want to build a line of sight GP service. This will take in as input the original TIN dataset along with a feature set input (allowing the user to draw points, lines, & polygons as input to the model). Here is the model:
Once we deploy the model to the server, we can then access the GP service directly from the web mapping application. Again just like map caching, GP services are very powerful yet require careful consideration. When you publish a GP toolbox to the server everything has to be set up to allow the web user to give input, execute, and visualize. The process must do everything for the user. That includes assigning layer files to the output of the model for rendering. We will be revisiting this in detail in future posts.
I want to add one more model to the application that allows users to draw linear features on the map, extract the vertices from the points of the line, and then add elevation values from the original TIN to the point data set. Check out the model here:
The real test is in the deployment of the application. Give it a try here.
So, what do you think?