I have a Python toolbox with a single tool designed for 10.2. The tool is intended to be a geoprocessing service on a server. So I run the tool, and after it succeeds, I right click the result and choose Share As --> Geoprocessing Service. In the wizard, I choose "Save a service definition file" and move through the wizard until it switches to the dialog where I can set service properties. I Analyze, and there are no errors or warnings.

At this point, I notice that my parameters are being given default values. In particular, they get the values that I used when I ran the tool to create the results file. ArcGIS's dialog will not let me modify the default parameters; the text boxes are read only.

I want to prevent this. Ideally, my parameters would have no default values, but empty string default values would also be acceptable. All my input parameters happen to be strings. How can I prevent ArcGIS from using the result's parameters as the defaults?

2 Answers 2


Unfortunately, there isn't any way to change the parameters' values you've used when running the tool for publishing its result later on. I usually deal with these situations in an ugly way but it works. I work with ArcPy, but these should concepts should apply to a Python toolbox tool, too.

  1. Specify an input parameter in your script (eg inputDate).
  2. Use a variable in the code later that will assign some other value to this parameter (realDate = "2012/12/12" >> inputDate = realDate)
  3. When you author a script tool, make the tool parameter not required and leave it blank when running the tool. The tool will execute as needed since you get the variable value substituted.
  4. After the tool will get published as a GP service, go to the newly published service folder (X:\arcgisserver\directories\arcgissystem\arcgisinput\Service.GPServer\extracted\v101\foldername) and edit the .py file: delete the row where inputDate is assigned from a dummy variable realDate.

Now you have the GP service with blank input parameter published.

  • This may be a good way of dealing with the problem when you have full control over the ArcGIS server. Unfortunately, in my case, I don't. I'm a developer, and these services will be published by someone else in an environment I don't have access to. Not only that, but I have to write the instructions for how to release it. I can't imagine an admin being very happy at instructions that involve remoting into the server and manually modifying published files. =)
    – jpmc26
    Mar 8, 2014 at 1:21
  • Ah I see :) I've just recalled that you might be able to unpack the .sd file (which is just a zipped folder), modify the .py file to get rid of the dummy variable and zip it back to .sd file. Maybe give it a shot? Mar 8, 2014 at 9:16
  • Yeah. It is some kind of compressed file. I can open it with 7-zip, but I'm not exactly sure what the compression format is. 7-zip lists the compression method as "LZMA:16", whatever that is. (I know LZMA is a better algorithm than the deflate of ZIP, but I don't know what the 16 is.) On top of that, the file structure is rather confusing. I think messing with the SD file is probably a bad idea, if for no other reason than I don't know how to recompress the contents back together. I was looking at the contents of a definition draft file to see if I could do it from there, but again, no luck.
    – jpmc26
    Mar 10, 2014 at 20:15

As @AlexTereshenkov noted, there doesn't seem to be a way to prevent this.

So, I have come up with the following work around: I have revised my services so that bad inputs will generate empty output. (For me, this was an empty shapefile or geodatabase.) This is far, far from ideal. An error message would be more useful to users, but my particular scripts can live with this workaround since end users will never call them directly. All calls to this service come from a web application (It's not even publicly accessible.), and the web app can ensure the input is correct.

By generating empty results for bad inputs, I can run the tool on a desktop with nonsense inputs and generate an empty data set. Using this run to generate the service definition file, my services now have nonsense defaults and generate empty output if those defaults are used. This lowers the risk of someone getting the wrong output because of a programming error.

As I said, this isn't ideal, but it does do roughly what I need without modifying anything after publishing. I wouldn't recommend this solution in all cases, but I think it's workable in cases where some external service can filter the inputs.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.