Essential vocabulary for geoprocessing services

This document introduces vocabulary that is essential to understanding geoprocessing services.

Term	Description
Result map service	When publishing a geoprocessing service, you can choose to view the result of your task as a map (in addition to any other results of your task). The map is created on the server for passing to the client as an image (a .jpeg, for example).
Project data	Project data is a term used by geoprocessing to describe input data that is not a parameter; that is, the data is not supplied by the user of the tool or task, but is used internally by the tool or task. For example, the San Francisco Network Dataset variable in the model below is project data because it is used by the model but not exposed as a parameter. Essentially, a model's project data is a blue oval without a P next to it. Project data can appear in scripts as well, as shown in the Python code snippet below. import arcpy # The inputPoints variable is considered to be project data # since it is not an input parameter. # inputPoints = r"c:\data\Toronto\residential.gdb\shelters" arcpy.Buffer_analysis(inputPoints, 'shelterBuffers', '1500 Meters')
Data store	A data store is a catalog of data that can be found on the server. The data store is a way for you to give the server a list of data locations that the server can access. When the data can be accessed by the server, the data found on your local machine will not be copied to the server when publishing. Typically, you use the data store for your project data.
Input mode	When you create a geoprocessing task within a geoprocessing service, you decide how the client will input values for each task parameter by choosing an input mode for the parameter value. There are three input modes: User defined value—The client provides a value for the parameter. Choice list—The client is given a list of strings (the choice list) and must choose one or more of the strings from the choice list. Depending on the data type of the input, the strings in the choice list can be the names of layers or simple keyword options. Constant value—The task will use the value you supplied for the parameter when you created the result. Since the value is constant, the client can't change it, so it will not become a task parameter when the service is published.
Non-transportable data	A GIS service has to work with the simplest of all clients: a web browser running on a computer that does not have any GIS capabilities. Such simple clients know only how to transport (send and receive) packets of simple data to a server, such as text, numbers, files, and geographic features and their attributes (fields). In the context of geoprocessing tasks, GIS datasets can be divided into two distinct categories: transportable and non-transportable. Transportable datasets are features, rasters, tables, and files. Parameters containing transportable datasets support the User defined value input mode. Non-transportable datasets are anything other than features, rasters, tables, and files. There are two categories of non-transportable datasets. Complex datasets are datasets such as geometric networks, network datasets, topologies, TINs, and so on. These data types are known as complex datasets because they model complex relationships between simple features. Container datasets are items such as folders, file and personal geodatabases, and map documents (.mxd). These data types contain a mixed collection of other datasets—hence their name, containers. Complex datasets and container datasets are non-transportable and do not support the User defined value input mode.
Asynchronous versus Synchronous execution mode	Asynchronous and synchronous define how the client will submit parameters for execution and get the result from the task. When a service is set to synchronous, the client waits for the task to finish. Typically, a synchronous task executes quickly—5 seconds or less. An asynchronous task typically takes longer to execute and the client must periodically ask the server if the task has finished, and if it has finished, get the result. A web application using an asynchronous task must have logic implemented to check the status of a task and handle the result once execution is finished.