Raster result names and locations

627
4
12-23-2011 07:00 AM
JohnHak
New Contributor
I'm in the process of trying to convert a script that worked wonderfully in V9.3.x to V10 and am really starting to hate how V10 is handing results.

For example,

In V9.3.x my line would be:

GP.Divide_sa(base1_euc, v30i, base_euc3)

and it creates a raster, base_euc3, in my predefined workspace.

In V10 my line is:

base_euc3 = Divide(base1_euc, int(v30i))

and it does not create my raster as I've predefined it, it creates one called divid_ras in my workspace, but not until I run my next statement

base_max = Con(base_euc3, div, base_euc3, "VALUE < 1")

Which, annoyingly, creates a raster call con_divid_ra1, not base_max.

Is it possible to have V10 just do what I ask?  create my rasters the way I define them, when the process runs and not create it's own names?
Tags (2)
0 Kudos
4 Replies
curtvprice
MVP Esteemed Contributor
and it does not create my raster as I've predefined it, it creates one called divid_ras in my workspace (snip)
Is it possible to have V10 just do what I ask?  create my rasters the way I define them, when the process runs and not create it's own names?


If your scratch workspace is the same as the grid where you want to write things, when you run the .save it will simply rename your raster to what you want. If the scratch workspace and the workspace you're writing to are in different places, it will have to copy the output (which could be slow with large rasters).

It's not all bad -- you don't need to worry about output names at all until you save the raster.

base_max = Con(base_euc3, div, base_euc3, "VALUE < 1")
base_max.save("mygridname")


Also:

but not until I run my next statement


This is because the first grid isn't created until the you ask for it in a new map algebra statement or by calling the save method. This allows the python raster engine to optimize your processing as much as possible behind the scenes.
0 Kudos
JohnHak
New Contributor
Unfortunately, my frustration with these changes stems from the the .save function.  In my script when I hit that particular line it blows up PyWin and my error traps fail to document why.  It makes it hard to debug the script when there is nothing to work from.  I have an "if" decision statement prior to my save I'm wondering if that may be my issue.  Maybe, the process dumps the temp raster when the if runs and it's just not available when my .save statement is run.
0 Kudos
MichalisAvraam
New Contributor III
Unfortunately, my frustration with these changes stems from the the .save function.  In my script when I hit that particular line it blows up PyWin and my error traps fail to document why.  It makes it hard to debug the script when there is nothing to work from.  I have an "if" decision statement prior to my save I'm wondering if that may be my issue.  Maybe, the process dumps the temp raster when the if runs and it's just not available when my .save statement is run.


Jon,

I have the same problem. I run my Con statement, and when I try to save the result I get an unexpected error. Not sure how to deal with it at all. Tried a few things, including verifying the result is a raster, and checking it has a min and max values, but no luck.
0 Kudos
curtvprice
MVP Esteemed Contributor
Unfortunately, my frustration with these changes stems from the the .save function.  In my script when I hit that particular line it blows up PyWin and my error traps fail to document why. 


Just a thought: Is arcpy scratch and current workspace set to a folder with a "safe" path name? (no spaces or "-" characters etc in the pathname)?  Raster tools often don't play well with pathnames like that. (Fun, since in Windows XP the default TEMP - often what you get if you don't define the workspace explicitly.)
0 Kudos