Workspace and scratchWorkspace doing strange things when using arcpy.sa?

4580
3
Jump to solution
10-26-2011 02:34 AM
XanderBakker
Esri Esteemed Contributor
Workspace and scratchWorkspace doing strange things when using arcpy.sa?

An odd thing just happened. I was working on some analysis using arcpy.sa when a simple Focal Statistics:

>>> AHN2CFILL2FM2 = FocalStatistics("AHN2CFILL2",NbrRectangle(3,3,"CELL"),"MEAN","DATA")

â?¦ resulted in the following error:

Runtime error File <string>, line 1, in <module> File c:\program files\arcgis\desktop10.1\arcpy\arcpy\sa\Functions.py, line 4788, in FocalStatistics File c:\program files\arcgis\desktop10.1\arcpy\arcpy\sa\Utils.py, line 47, in swapper File c:\program files\arcgis\desktop10.1\arcpy\arcpy\sa\Functions.py, line 4782, in wrapper File c:\program files\arcgis\desktop10.1\arcpy\arcpy\geoprocessing\_base.py, line 490, in <lambda> <class 'arcgisscripting.ExecuteError'>: ERROR 000875: Output raster: C:\Project\_Wetterskip\data\Wetterskip.gdb\C:\Project\_Wetterskip\data\py\py\Wetterskip.gdb\FocalSt_AHN21's workspace is an invalid output workspace. ERROR 000581: Invalid parameters. Failed to execute (FocalStatistics).

Apparently, for some reason my workspace was set to a non valid location. When I listed the workspace and scratchworkspace I noticed this:

>>> print env.workspace
C:\Project\_Wetterskip\data\Wetterskip.gdb

>>> print env.scratchWorkspace
C:\Project\_Wetterskip\data\py\py\Wetterskip.gdb

My workspace was still defined correctly, but for some strange reason my scratch workspace (normally the same location as my workspace) had been set to a non existing subfolder \py\py, where obviously it wasnâ??t going to find any geodatabaseâ?¦ But why would my output workspace been set to a combination of my workspace and my scratchWorkspace?

The only thing that I can imagine being the reason for this, is that shortly before executing the Focal Statistics command I had used the option "Save Asâ?¦" from the context sensitive menu, shown when clicking the right mouse button in the python window. On saving I had created a new folder "py" (but only 1 "\py" subfolder and not "\py\py").

Also, when opening the Focal Statistics tool in the toolbox, the default output location was pointing to the non existing location (see Screenshot_FocalStatisticsTool). Investigation the Environment setting (through Geoprocessing menu, option Environmentsâ?¦) also showed the wrong location for scratch workspace.

I closed the tool and the environment setting, went back to my python window and set my scratchWorkspace to my current workspace:

>>> env.scratchWorkspace = env.workspace
>>> print env.scratchWorkspace
C:\Project\_Wetterskip\data\Wetterskip.gdb

Next step was to perform the Focal Statistics again (through Python), which this time resulted in:

Runtime error File <string>, line 1, in <module> File c:\program files\arcgis\desktop10.1\arcpy\arcpy\sa\Functions.py, line 4788, in FocalStatistics File c:\program files\arcgis\desktop10.1\arcpy\arcpy\sa\Utils.py, line 47, in swapper File c:\program files\arcgis\desktop10.1\arcpy\arcpy\sa\Functions.py, line 4782, in wrapper File c:\program files\arcgis\desktop10.1\arcpy\arcpy\geoprocessing\_base.py, line 490, in <lambda> <class 'arcgisscripting.ExecuteError'>: ERROR 000622: Failed to execute (Focal Statistics). Parameters are not valid. ERROR 000628: Cannot set input into parameter in_raster.

What in the worlds name was happening with my "in_raster"â?¦ :confused:
I took a closer look at my TOC and noticed that for a really strange reason all the datasources had become invalidâ?¦ (see Screenshot_TOC).

Fortunately, using the Repair Datasource option fixed all the datasource errors. 🙂
I Think Iâ??m going to restart my system, and see if it happens againâ?¦

Anyone with similar experiences?
0 Kudos
1 Solution

Accepted Solutions
RyanDeBruyn
Esri Contributor
xander:

The environment settings (in the GP dialog) seem to be messing up the python window. Please make sure these geoprocessing environments set in the application (dialog) are pointing to a correct and exisiting location.

Is your map document saved with relative paths? Please let me know if yes? We have had cases where geoprocessing environment workspaces get altered when opening an exsiting MXD document that has relative paths.  This may be your cause.  If so, to remedy, set the workspaces (or clear to default) and change the document to not contain relative paths and save the mxd again.  We are investigating this.

Please note you can use the function arcpy.ResetEnvironments() in the python window to reset to the application settings (what is set in the geoprocessing environment dialog).  Once you change an environment in the python window it should persits for that session or until you reset. You may have different environments for the python window and the GP tools, so be aware.  Use the ResetEnvironments() to synch back with the application.

By default the output raster in your map algerbra expression will be created in the scratch workspace. If the environment dialog shows an incorrect path the GP tool will too.

Hope this helps.  If you have a clear reproducible case please let me know.

Thank you,
-Ryan

View solution in original post

3 Replies
RyanDeBruyn
Esri Contributor
xander:

The environment settings (in the GP dialog) seem to be messing up the python window. Please make sure these geoprocessing environments set in the application (dialog) are pointing to a correct and exisiting location.

Is your map document saved with relative paths? Please let me know if yes? We have had cases where geoprocessing environment workspaces get altered when opening an exsiting MXD document that has relative paths.  This may be your cause.  If so, to remedy, set the workspaces (or clear to default) and change the document to not contain relative paths and save the mxd again.  We are investigating this.

Please note you can use the function arcpy.ResetEnvironments() in the python window to reset to the application settings (what is set in the geoprocessing environment dialog).  Once you change an environment in the python window it should persits for that session or until you reset. You may have different environments for the python window and the GP tools, so be aware.  Use the ResetEnvironments() to synch back with the application.

By default the output raster in your map algerbra expression will be created in the scratch workspace. If the environment dialog shows an incorrect path the GP tool will too.

Hope this helps.  If you have a clear reproducible case please let me know.

Thank you,
-Ryan
by Anonymous User
Not applicable
Original User: xander_bakker

Hi Ryan,

Thanks for the explanation regarding the arcpy.ResetEnvironments() function. I will give it a shot.

The environment settings (in the GP dialog) seem to be messing up the python window. Please make sure these geoprocessing environments set in the application (dialog) are pointing to a correct and exisiting location.


I'm not sure if my env settings (GP dialog) are messing up the python settings. What I normally do is this:


  • the env setting are default pointing to ...\username\My Documents\ArcGIS\Default#.gdb

  • through ArcCatalog "Make Default Geodatabase" I set my filegeodatabase to the one I want to use

  • when I look at the env settings, both current and scratch workspace will point to the one indicated in the previous step.

  • since I normally save the scripts I start in python by import the env (from arcpy import env) and then set the env.workspace to the one I'm using (dragging it from ArcCatalog to the python window)

  • for the rest I import * from arcpy.sa, set my snapraster and cellsize and start to execute the calculations required.

  • I didn't use any GP dialog until the FocalStatistics threw the errors and didn't let me execute the command.

  • I think it will be difficult to reproduce since I have done this many times, and it is the first time it happens.


Is your map document saved with relative paths? Please let me know if yes?


I'm using the default: relative paths unchecked (->absolute path)


We have had cases where geoprocessing environment workspaces get altered when opening an exsiting MXD document that has relative paths.  This may be your cause.  If so, to remedy, set the workspaces (or clear to default) and change the document to not contain relative paths and save the mxd again.  We are investigating this.


This issue is not related to opening a MXD (with relative paths), since it was working fine and all of a sudden the errors occured.


Please note you can use the function arcpy.ResetEnvironments() in the python window to reset to the application settings (what is set in the geoprocessing environment dialog).  Once you change an environment in the python window it should persits for that session or until you reset. You may have different environments for the python window and the GP tools, so be aware.  Use the ResetEnvironments() to synch back with the application.


Thanks for the advice!


By default the output raster in your map algerbra expression will be created in the scratch workspace. If the environment dialog shows an incorrect path the GP tool will too.


That makes sense.


Hope this helps.  If you have a clear reproducible case please let me know.


As I wrote before, I don't think I'll be able to reproduce.


BTW; is there a way (perhaps a setting) that will force the output raster name to be the one used in the command? At this moment I have to follow each command with myRaster.save("myRaster") to force it to have a name I want it to have.

See also thread: http://forums.arcgis.com/threads/42427-Define-the-output-name-of-a-raster-using-SA-and-Python


With kind regards,
RyanDeBruyn
Esri Contributor
Thank you.


BTW; is there a way (perhaps a setting) that will force the output raster name to be the one used in the command? At this moment I have to follow each command with myRaster.save("myRaster") to force it to have a name I want it to have.

See also thread: http://forums.arcgis.com/threads/42427-Define-the-output-name-of-a-raster-using-SA-and-Python


see my reply to the respective thread.

-R
0 Kudos