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.
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.
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:
- savvy enough to understand they can’t provide data from their web map as input to the service
- OK with selecting their input from a static list of input layers, and
- 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.
Let’s investigate the first option and build a new tool using Python.
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.
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.