Raster Calculator Requires Cell Size and Extent with Trig Functions

[TimWhiteaker]

I'm reporting an issue and solution involving the Raster Calculator tool in ArcToolbox for ArcGIS 10.  Raster Calculator works fine until I include a trig function such as Cos().  When my expressions include a trig function, I get this error message upon execution:

ERROR 000539: Error running expression: rcexec() <type 'exceptions.RuntimeError'>: No CellSize and Extent set

A simple expression which produces this error is Cos(0)*"myraster".

To resolve the issue, I click Environments in the Raster Calculator window, and then set the Extent (under Processing Extent) and Cell Size (under Raster Analysis) to be "Same as layer myraster."  The tool then executes correctly, although it does warn me that the input and output datums don't match (even though they do appear to match).

I'm curious why using Cos() requires extents and cell sizes to be explicitly set.  But at least there's a workaround.

[PatrickTaurman]

I just ran the following statement in the Raster Calculator, and did not receive any messages:

Cos("test_elevation")

When I tried

Cos(0) * "test_elevation"

I got the same message you get.  Next I tried

"test_elevation" * Cos(0)

and still get the error, so the order of inputs does not matter.  I am not sure if this is expected or not.  I would log an incident with Support to verify if this should be functioning like this since Cos("test_elevation") works without error.

[PatrickTaurman]

Hi Bill,

Well considering Cos("test_elevation") works without specifying extent or cellsize, I would expect "test_elevation" * Cos(0) or Cos(0) * "test_elevation" to work also. 

Correct me if I am wrong, but Cos(0) is simply 1, so "test_elevation" * Cos(0) or Cos(0) * "test_elevation" is simply "test_elevation" * 1 or 1 * "test_elevation". 

If the Raster Calculator can get the cellsize and extent information for Cos("test_elevation"), it really only makes sense that it can also get it for "test_elevation" * Cos(0) or Cos(0) * "test_elevation", considering it is just multiplying the raster by 1. 

That is where I believe the bug is.  Please let me know if I need to clarify for you further.

Patrick

[DanPatterson_Retired]

From the the help for the function

http://help.arcgis.com/en/arcgisdesktop/10.0/help/index.html#//009z000000n8000000.htm

to quote:

In order to use a number as an input for this parameter, the cell size and extent must first be set in the environment.

which is in keeping with the intent of the tool/function and I suspect that all inputs for all expressions are checked for cell size and extent to ensure that the outputs meet the environment settings, hence, Cos(0) will fail since it has no extent or cell size and I would not want it to assume one.  This is not a bug, it is a wakeup to the user to delve into the problem further or use a numeric value for Cos rather than the tool/function.

[PatrickTaurman]

Hi Dan,

Interesting, I missed that in the syntax at the bottom of the Cos help.  Good catch.

Patrick

[PatrickTaurman]

Bill,

It can never hurt to contact Support and at least get the enhancement in.  This could also be posted over on the Ideas website (haven't checked to see if it exists there yet).

Patrick

[DanPatterson_Retired]

better still, request that the math module functionality be available within the interface so you could generate code in the raster calculator such as

import math
"SomeGrid" * math.cos(somenumber)

kind of like field calculator syntax

[RyanDeBruyn]

Thank you to all for your interest in this issue.

So currently the complex map algebra expression,

out = Raster("myraster) + Cos(0)

requires a cellsize and extent to be set because the Spatial Analyst function arcpy.sa.Cos() requires it when using a scalar input. Using this or any other local function in your map algebra expression would have this requirement because the function result is a raster not a scalar.

Mr. Huber and Mr. Patterson are correct in there interpretation of the problem and provided a good explaination as to why. With that said, this expression should "just work", as it did work in workstation, and I think all share the same frustration.

We acknowledge this is a defect and are currently working on the solution for supporting scalar values in Spatial Analyst local functions when used in a complex expression.

Workarounds for ArcGIS 10.0 (service pack 1)

1. set cellsize and extent environment if using Spatial Analyst arcpy.sa.Cos(0)


2. use the python math.cos(0) to return scalar (note the python uses lowercase for cos() function)

Thank you again for you time and consideration.
-Ryan DeBruyn
ESRI - Spatial Analyst

[DanPatterson_Retired]

Ryan
Thanks, I think some of us still miss the simplicity  of SA knowing an extent (whether it was right or wrong)...aka Avenue's    0.AsGrid