topic Re: Geoprocessing Services - Directory Parameter in ArcGIS Enterprise Questions

Geoprocessing Services - Directory Parameter

AmySmith3 — Thu, 01 Nov 2012 14:34:59 GMT

Hello,

I have a script tool that processes multiple files in a directory specified by the user. The user also defines the output directory. When shared as a Geoprocessing Service, it seems as if the user is unable to browse for and/or enter these folder locations, perhaps because they fall into the "container" group of input data types. One way around this might be to change the parameter type to "string"; however, this makes it less intuitive for the user, as they have to enter the exact path as text. Is there any way to allow them to navigate to a folder on the file system using a geoprocessing service?

Thanks!

Amy

Re: Geoprocessing Services - Directory Parameter

KevinHibma — Thu, 01 Nov 2012 15:14:47 GMT

The workspace input parameter isn't supported with a GP Service (as a parameter). We do support "strings" though as you pointed out.
At 10.1 we map the unsupported parameter to either string (user defined) or hardcoded it (constant).

It sounds like you're consuming the Service inside Desktop? When you open the tool dialog inside ArcMap you just have a string box to put a path in. I can't envision another way around this as the Service now has STRING as input. You could write a little script tool and distribute that to your Desktop users. The tool would take a folder as input and pass the string representation of that to the Service.
Or if you're using a web application that you've built - you can build in a file open dialog and just get the value of that and pass it to the service.

Re: Geoprocessing Services - Directory Parameter

AmySmith3 — Thu, 01 Nov 2012 17:30:02 GMT

The workspace input parameter isn't supported with a GP Service (as a parameter). We do support "strings" though as you pointed out.
At 10.1 we map the unsupported parameter to either string (user defined) or hardcoded it (constant).

It sounds like you're consuming the Service inside Desktop? When you open the tool dialog inside ArcMap you just have a string box to put a path in. I can't envision another way around this as the Service now has STRING as input. You could write a little script tool and distribute that to your Desktop users. The tool would take a folder as input and pass the string representation of that to the Service.
Or if you're using a web application that you've built - you can build in a file open dialog and just get the value of that and pass it to the service.

Thanks for your response!

Yes, the service would be consumed inside Desktop. I would like the service to copy all files in the first user-defined directory to a temporary directory on the server, process them, produce output files, archive them in a zip file, and transfer them to the second user-defined directory.

Ideally, this tool would be shared as a geoprocessing service to allow for central access and speedy processing. It sounds like there is not a straight-forward method to do this with ArcGIS for Server 10.1. Do you have any suggestions? Any thoughts or advice would be greatly appreciated!

Amy

Re: Geoprocessing Services - Directory Parameter

KevinHibma — Thu, 01 Nov 2012 21:26:04 GMT

Amy,

This is a sort of "classic" GP Server problem: how can GP Server work with "user supplied data". GP Server can only execute against data that it has access to.
Typically thats either "project" data: data which is essential to the service that the server has access to and doesn't change.
Or user supplied input, generally are simple strings, numbers, or digitized features for example.

In your situation you want to get more complex data / project data / multiple datasets over to the Server for it to crunch.
This is where you have to really define your workflow to achieve desired results.

As I said, Server needs the data to act on, so the problem is how to get the data to the Server. There is no mechanism to pass a "folder" to the Server and say "upload everything in here".
Since you're using Desktop as the client, you can pass a fileto Server. The best way I can think to do this would be to have your user zip up the files on their harddrive, then have the GP Service accept a file input (instead of a folder). Desktop has the ability to send the file to the Server, and the service with a few lines of Python code could unzip the contents of the file to a local directory, perform some operations, then zip up the output.

An alternative approach if your users share a common folder that the Server has access to would be to move their data to this folder manually. Then in the Service they submit the path to the data (as a string), and because the Server has access to that path, it finds the data and crunches it.

I personally like approach #1, but your users, internal network and deployment criteria will determine which method works best for you.

I hope this helps.

Re: Geoprocessing Services - Directory Parameter

KyttMacManus — Thu, 29 Nov 2012 12:40:55 GMT

I have a similar question, please let me know if it should be restated in a separate thread.

I am running a GP Service and want to save my outputs to a local File GDB. I have tried hard coding the output file paths as a parameter, but it seems they are automatically replaced by the Scratch.GDB in an individual job directory.

Is it possible to save the outputs from a GP Service to a local folder? I have already registered the folder with the data store and that seems to be working alright.

Thanks for your help.

Kytt MacManus
Geographic Information Specialist
Columbia University CIESIN

Re: Geoprocessing Services - Directory Parameter

AmySmith3 — Wed, 26 Dec 2012 19:32:15 GMT

Desktop has the ability to send the file to the Server, and the service with a few lines of Python code could unzip the contents of the file to a local directory, perform some operations, then zip up the output.

A very belated thank you for your response!

I was wondering if you could point me in the direction of some help documentation on returning an output file to the user.

Thanks,

Amy