Designing Geoprocessing Services

The task of making a model, publishing it as a geoprocessing service, and building a web application can be straightforward. Designing a service that is easy to understand and use can be more complicated. Many of us resort to the trial and error approach when building geoprocessing services, but this usually leads to frustration and a poor experience for those running our services. If you take a few moments to consider what your service will do, and the audience who will consume this service, you can reduce your iterations and end up with a useful and user-friendly service.

Model tool selecting features

Let’s start by working on a common task: you want to create a service where the user specifies a query to select features before performing some further analysis. Hopefully you thought of the Select Layer by Attribute or Select Layer by Location tools. You’re a GIS expert, a master of databases and a geoprocessing wizard; this will be an easy task. Your tool probably looks similar to the Select Census Tracts tool.

You’ve run the tool to ensure it works correctly in ArcMap, and published it as a service. Next, you created a web app using Web AppBuilder, and configured a geoprocessing widget that allows your users to perform analysis. This widget inside the web application looks very similar to your tool inside ArcMap.

Selecting features from a layer in the web app using a geoprocessing widget

The first parameter, a drop-down list allows the user to select a layer. When using the layer input parameter, the list of layers in the published service gets set to the same list of layers that you had in your map when you originally published the service. This set list inside the geoprocessing service will most likely be different than the layers in the associated web map. The inability to select the layers in the map and provide them as input to the service could be a source of confusion to your users.

Another significant issue is the query Expression parameter in the web application’s geoprocessing widget is now a basic textbox. The more advanced and user-friendly SQL Query control you used in ArcMap only exists inside your Desktop GIS application; as such, the parameter gets turned into a simple string when published as a service.

If the people who will be using your service are:

  1. savvy enough to understand they can’t provide data from their web map as input to the service
  2. OK with selecting their input from a static list of input layers, and
  3. able to write SQL queries without seeing the attribute table or any syntax help

…then your work is done! At this point you’ve probably identified how silly it is to expect someone to provide a SQL query without knowing anything about the data. It is time to step back and think about how we could re-design this service.

Time to Design!

One thing we could have done during publishing was to change the input mode on the input layer to a constant value. Essentially, this hard codes the service to using one layer, in this case, the census layer. As shown in the geoprocessing widget, the user no longer has the ability to choose a layer. This should reduce some confusion from trying to select a layer in the web map when the service should only function against the census data. When configuring a widget in Web App Builder, you can also update parameter labels to provide more information on how to use the widget. As shown, the Expression label was updated to explain that the user must provide a query.

Each parameter can be configured inside the service editor at publish time

Overall, the experience is better, but not great. At this point we’ve exhausted all of the useful changes that can be made during publishing and while configuring the widget inside Web AppBuilder. To make the user experience any better, we have two choices: re-configure the tool and republish it, or build a custom application using the ArcGIS API for JavaScript.

Let’s investigate the first option and build a new tool using Python.

Building a script tool to help query features

Now, instead of expecting your users to construct SQL queries, you can create a series of string inputs that aids the user in building a query. The script tool is responsible for bringing the SQL elements together, no longer burdening the service user with making guesses or searching for help. Once published, the service user would enter values exactly as they would when using the tool inside ArcMap or ArcGIS Pro. This might make the service slightly more user-friendly, but still, it requires that the person using it understands selection operators. Can we make this even better? Absolutely! We can create a better service by making a string parameter where the user can choose easy to understand natural language statements. Consider the following script tool and geoprocessing widget example.

Build a script tool that takes the guess work out of using the service

The string parameter “What do you want to select?” has a value list filter that allows you to define acceptable options to choose from. The list you built inside the tool provides the exact same drop-down list of options inside the widget. The set list of choices will make this tool usable by anyone! The code inside the script tool makes use of a dictionary to take the easy-to-understand choice and turn it into a proper SQL query. We accepted the trade-off of restricting the service to a few queries, instead of having users guess to get the service to work.

While this example was fairly simple, it highlights how you can build a better tool and provide a better user experience through thoughtful design. Of course if you’re a JavaScript ninja you could have taken the very first service and created an intuitive web application that provides the same user experience as we just made using the natural language SQL queries inside the script tool. There are many ways to get to that great geoprocessing service experience; identify what that experience should look like and set a plan to get there by applying your ModelBuilder, Python or JavaScript knowledge.

About the author

Kevin Hibma

Kevin Hibma has almost two decades of experience building Esri software and works as a product engineer on the ArcGIS Enterprise team.

Notify of
Inline Feedbacks
View all comments

Next Article

Visualize your Mission Responders Activity with Tracklines

Read this article