How can I get Raster Layers to the right folder using python/ModelBuilder?

[PaulSimpson]

I have automated a series of map making steps to generate and display 4 desired layers in ArcMap 10.0.  Everything ???works??? and displays in ArcMap, but in the List By Source view my raster layer displays as sourced in:

    ???C:\DOCUME~1\simpsonp\LOCALS~1\Temp\???. 

I built the tool in ModelBuilder originally and it displayed the same behavior.  When performing the steps by hand all 4 layers are listed within the same file GDB, and that is the desired behavior. 

Here is the Python code segment used to generate the raster layer:

    # Process: Natural Neighbor     outpath = Output_GDB     arcpy.env.workspace = outpath     arcpy.gp.NaturalNeighbor_sa(v_route, pmname, v_raster )     v_raster = os.path.join(outpath, v_raster)      # Process: Make Raster Layer     outpath = Output_GDB     arcpy.env.workspace = outpath     arcpy.MakeRasterLayer_management(v_raster, v_conc)      arcpy.SetParameterAsText(6, v_conc)

I know MakeRasterLayer generates a virtual layer, which will be saved when the .mxd file gets saved, but I thought it would point to the raster in the Natural Neighbor step, which resides in Output_GDB, since that is the behavior of MakeFeatureLayer.  We don't want anything stored on local drives, and we certainly don't want anything sent to Temp directories.

What am I missing to get my Raster Layer in the right place on the TOC?

Thanks

Paul

[curtvprice · Accepted solution]

What am I missing to get my Raster Layer in the right place on the TOC?

When you create a raster object with a Spatial Analyst tool, it is normally created in the current scratch workspace (arcpy.env.scratchWorkspace). When you apply the .save method, it is then saved using the pathname you give it. Windows %TEMP% is the default place if you don't specify the scratchWorkspace, which is why your datasets are being written there.

I think a better approach would be something like this. Note my use of arcpy map algebra instead of the Arc-9-ish arcpy.gp syntax. (Doing it the "new way" really pays off when you want to nest raster tools like Con, IsNull and SetNull within a single expression.)

# Process: Natural Neighbor outpath = Output_GDB arcpy.env.workspace = outpath arcpy.env.scratchWorkspace = outpath from arcpy.sa import * v_raster = NaturalNeighbor(v_route, pmname) v_raster.save("nnraster") # saves to outpath + "/" + "nnraster" arcpy.SetParameterAsText(6, v_raster)

If this is run as a script tool, and parameter 6 is set in the script tool parameters to be an output parameter of type "Derived" and data type "raster dataset," a raster layer will be created in the arcmap document from which you ran the tool. That raster layer, of course will source to the raster saved to <outpath>/nnraster.

A nice benefit of having the current and scratch workspace being the same is that when you save the raster, it can be simply renamed to the output name instead of copied - which can save a lot of time with large rasters.

Hope this helps.

[PaulSimpson]

It worked!  I was surprised since the scratch workspace was already set to the correct file GDB in ArcMap, and since the raster itself already (apparently) resided in that GDB, according to ArcCatalog.

I'm also going to switch to the arcpy map algebra.  It feels much more intuitive to me.  Thanks for introducing it to me.

Paul

[curtvprice]

It worked!  I was surprised since the scratch workspace was already set to the correct file GDB in ArcMap, and since the raster itself already (apparently) resided in that GDB, according to ArcCatalog.

That sounds strange. Script tools should pick up the geoprocessing environment settings unless you set it explicitly within the script. However, it's a huge advantage to set it in your script so you can for example, ensure your scratch workspace is a folder rather than a gdb. Any changes to these GP environment settings inside a script tool do not migrate "up" to the application, they only apply to your script.

I'm wondering if your script is running "in process" or not. I wouldn't think it would make a difference.

[PaulSimpson]

That sounds strange. Script tools should pick up the geoprocessing environment settings unless you set it explicitly within the script. However, it's a huge advantage to set it in your script so you can for example, ensure your scratch workspace is a folder rather than a gdb. Any changes to these GP environment settings inside a script tool do not migrate "up" to the application, they only apply to your script.

I'm wondering if your script is running "in process" or not. I wouldn't think it would make a difference.

It is running in process.  This is a recent install of version 10.0 though, and there are some very strange things happening with it - layer files used as symbology templates losing their symbology, entire directories disappearing from ArcMap and ArcCatalog, random inability to access any Excel files via ArcGIS - none of which happen on other computers I have tested.  I wouldn't be surprised if this environment setting behavior is just another sign of a problem with this machine.