Buffer and %scratchfolder% - "Error 000210: Cannot create output..."

Question

This is happening on Windows 2008 R2 Enterprise SP1.

I have built a model in ModelBuilder that (in summary) takes a feature set, does a whole load of spatial unions, buffers the input feature set to 2 miles and then does a final spatial join with that on another feature set.  All the union results are parameters, as is the buffered shape.  I have all the results outputting to %scratchfolder%\quads, %scratchfolder%\project_buffered, etc.  Everything apart from the buffering runs fine.  I am seeing the following when I get to the running of the buffer tool:

ERROR 000210: Cannot create output C:\Users\frank_mclean\Documents\ArcGIS\scratch\project_buffered
Failed to execute (Buffer).

1. The project_buffered shapefile actually seems to be created just fine.
2. I am running ArcMap as an administrator.
3. If I change the buffer output to be something like 'C:\Temp\project_buffered', the model runs fine.  With the issue then, of source, that if I rerun the model, it basically won't, because 'C:\Temp\project_buffered' already exists.

So, my questions are:

1. What's going on? 🙂
2. I'm going at all this to get a result so I can publish the model as a service.  If I do a hack like point 3, above, will I be able to publish the service and not worry that whenever it runs it won't use an appropriate scratch area?  By which I mean can I be assured of this, not just try it and see it works and then bet the farm? 🙂

Thanks,

Frank

FrankMcLean · Answer

Hi Wayne,

I went with %scratchworkspace% for the buffered area and it now works, with your tip about the 'Overwrite' setting in place.  Thank you.

I've published my service and all is well so far.  Though now I have to dig about layer symbologies in the output results...

Thanks again,

Frank

T__WayneWhitley · Answer

No problem...there's the same setting at the model 'level' I think, or else with geoprocessing options, setting to overwrite outputs.

Can't test it right now, but I'll look it up, particularly being able to establish the overwrite setting particularly for this model (or even anything going to the scratch workspace).  How about in_memory workspace?  You can write to that from within ModelBuilder too, right?...I think that's more or less the same as 'scratch', maybe faster.

This...
http://resources.arcgis.com/en/help/main/10.1/index.html#//00210000000q000000

..and maybe this, about 'level' establishing env settings like overwrite - maybe not the most comprehensive doc about it, but interesting graphic depiction:
http://resources.arcgis.com/en/help/main/10.1/index.html#//001w00000036000000

As to how exactly to best administer this geoprocessing service, I don't know, but they usually run in high isolation - in fact that's what the Note says here if you haven't already been here:
http://resources.arcgis.com/en/help/main/10.1/index.html#//00570000007z000000

I'm interested because I'm going to be building a attribute-query-buffer-selection-export-table geoprocess service if I can get it to run at once (otherwise, I'll have users click more buttons to get what they want, so the task will be broken up, with 'intermediate' output passed to the next process) --- that is, if I can make it work.

FrankMcLean · Answer

So do you want to overwrite the existing output?

If so, set the overwriteOutput property on:

arcpy.env.overwriteOutput = True  # long day I guess, oh boy, I had this set to False!

Hi Wayne,

Thanks for the reply, which made me realize that I didn't specify that my model is built in ModelBuilder - of Python I know nothing. 🙂  I do want to overwrite the result, kind of, but it's the scratch folder I'm most interested in.

My understanding of specifying outputs to go to %scratchfolder% is that this is guaranteed by Arc to be available wherever you deploy and also (my understanding again) allows a published geoprocessing web service to create new scratch folders for each service call, so 2 simultaneous service calls are guaranteed not to collide.  I'm worried that just specifying C:\Temp (or similar) will force every service call to use that folder, leading to contentions and race conditions and lord knows what else.  Like to avoid those.  🙂

As the whole 10.1 geoprocessing service publishing process is nothing short of a dream come true (though, y'know, my dreams might be a bit on the unambitious side) it's a royal PITA to have my model hiccup and not let me get on with life.  I was flying there, for a while.

Thanks,

Frank