One of the ways to connect to ArcGIS Server is through Web services. When you make an Internet connection to the server, you will use a URL in this format: http://<server name>/<instance name>/services
This is an endpoint to your ArcGIS Server service catalog url.
Where <server name> is the name of your server, which can be an IP address, a domain name (serverx.esri.com), or simply “localhost”. The <instance name> is the name of your ArcGIS Server instance. The instance gets defined when you install ArcGIS server. You can review it by looking at server properties at your root folder in ArcCatalog.
So what can I do with this services catalog URL? This URL can be used to establish an Internet connection to an ArcGIS Server instance in ArcCatalog. It can be used as a connection in the ArcGIS Server Web ADF. It can also be used in custom applications that work with Web services. Today I am going to build a simple web application using the Microsoft .NET Framework in ASP.NET that consumes the catalog URL for my ArcGIS Server instance and lists the services, types, and service URL in a simple web page.
The first step after creating your new web site is to register the services catalog URL for your ArcGIS Server Web service. To do this you need to add a web reference to your project (in VS2005 right click on the project name and Add Web Reference). In the web reference dialog enter your server catalog URL.
Once we have registered the Web service we just need to use it.
//Create an instance of the service catalog web service
WebCatalog.Catalog webCat = new WebCatalog.Catalog();
//Set the url to your ArcGIS Server services url
String serverUrl = “http://localhost/arcgis/services”;
webCat.Url = serverUrl;
//Get the all the service descriptions from the Catalog
WebCatalog.ServiceDescription sds = webCat.GetServiceDescriptions();
//extract the name, type, and URL for each service in the
foreach (WebCatalog.ServiceDescription sd in sds)
Response.Write(“<b>Service Name</b> = “ + sd.Name + “<br>”);
Response.Write(“<b>Service Type = </b>” + sd.Type + “<br>”);
Response.Write(“<b>Service URL = </b>” + sd.Name + “<br>”);
So try it out here: http://serverx.esri.com/InterrorgateServer
You can download the Visual Studio project here.
Over the next few weeks I will explore working with the Web services for some of the ArcGIS Server service types (MapServer, GPServer).
One of the exciting new aspects of ArcGIS Server 9.2 is the ability to publish geoprocessing models and scripts to the server. A model can be published either as a tool that can be used directly on top of any map service, or it can be published with an associated map service so that you can control the symbology of the generated layer.
To illustrate the power of geoprocessing on the server, I built an example that uses a map service and an embedded model that allows users to execute an interpolation on the server and view those results in the web mapping application. The map service contains a point dataset describing the potential water yield from water wells drilled in Douglas County, Kansas (data courtesy of the Kansas Geological Survey and the Kansas Geospatial Community Commons). The model takes in the water well dataset and a user-defined cell size. This information is passed as input parameters to the Natural Neighbors GP tool. The output is a raster dataset. The output is then rendered using a predefined layer symbology file (a layer file).
If you looked closely, you may have noticed that the model includes an embedded Python script. This script allows me to put a limit on the input cell size parameter. I want to allow the user to set the cell size (in meters) of the output raster dataset from within the web application. However, I want to make sure that the user does not enter so small of a cell size that it will negatively affect the speed of the web application. The script ensures that if the user enters anything less than 30 meters, the application will default to a cell size of 30 meters. I will have more on this in a future post.
Here are some key steps to remember when publishing a geoprocessing tool embedded in a map service.
- Create an MXD with the input layer and any other background layers that you want in your map service.
- Create a toolbox in your project directory.
- Add a new model to your new toolbox.
- The model should use one of the layers in the map document as an input parameter.
- Ensure that your map document and input map layers are at the same projection.
- Your output dataset should be written to the scratch workspace.
- Set your toolbox scratch workspace environment variable equal to a directory that is visible to your ArcGIS Server Object Container (SOC) account.
- Move your finished model to your ArcMap table of contents. This is called a tool layer.
- Execute the model from within ArcMap and verify the results.
- Turn off the output layer in ArcMap and publish to the server.
The easiest way to publish a map service with an embedded geoprocessing service is to publish the map document (using the right-click option on the map document, “Publish to ArcGIS Server”). ArcGIS Server will see that the map service has a tool layer and will load that tool as a geoprocessing service.
Once deployed to the server, it is relatively straightforward to deploy the map service and associated geoprocessing task as a web application using ArcGIS Server Manager.
Check it out here: http://serverx.esri.com/interpolationexample
Try building and publishing your own models.
What do you think?
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?