Lookup function in v10.0 Map Algebra: implementing dot notation in v10.0?

[ChrisSnyder]

I have a need to do analysis on a multi-field raster dataset in ArcMap v10.0. I am accustomed to using "dot notation" that was natively supported in ESRi products for the last 20+ years...

In this thread (http://forums.arcgis.com/threads/16689-Using-raster-attribute-other-than-value-in-map-algebra), it seems that there is now a function called Lookup(), which you can now use to emulate the old fashioned .notation functionality. Great.

However, what I seem to be unable to do is to use the Lookup() function in Map Algebra... It works fine via the toolbox, but not if building complex Map Algebra expresions.

So, basically this is an example of a v9.3 SOMA expression I want to use in v10:

con([gnn].CANOV >= 70 & [gnn].STNDHGT >= 23, 1, 0)

According to the help, this should be the analogous statement in the new Map Algebra

con(((Lookup("gnn", "CANCOV")) >= 70) & (Lookup("gnn", "STNDHGHT")) >= 23), 1, 0)

But it errors out on the Lookup() command...

In fact I can't even run this through the raster calculator:

Lookup("gnn", "CANCOV")

The error message for both these v10.0 examples is:

ERROR 000539: Error running expression: rcexec() <class 'arcgisscripting.ExecuteError'>: Failed to execute. Parameters are not valid.
ERROR 001000: Lookup field: Field C:\Users\csny490\Documents\ArcGIS\Default.gdb\CANCOV does not exist
Failed to execute (Lookup).
Failed to execute (RasterCalculator).
...which is pretty interesting because my raster "gnn" is not stored in the Default.gdb, and, why would it be concatenating the field I want to lookup with the stupid path to Default.gdb anyway!


This leads me to belive that either:
1. I am doing something wrong
or
2. The Lookup() spatial analyst functiona can't be accessed via the "new and improved" map algebra, even though the Help topic indicates it can.

How can I implement this traditional "dot notation" functionality in the new v10.0 Map Algebra?

[JeffreySwain]

It looks as if the syntax change to reference rasters is causing the problem. In testing here, this syntax worked:
Lookup(Raster("RasterName"),"Value").

Can you try to change your syntax to:
Lookup(Raster("gnn"), "CANCOV").

For the new Raster Calculator to recognize the raster, it needs this syntax.

[ChrisSnyder]

Hi Jeff,

Thanks for the info, but I get the same error when I use the syntax you provided:


The expression

Lookup(Raster("gnn"), "CANCOV")

yeilds this error message:


Executing: RasterCalculator Lookup(Raster("gnn"), "CANCOV")


C:\Users\csny490\Documents\ArcGIS\Default.gdb\rastercalc3
Start Time: Thu Jan 12 16:40:31 2012
Lookup(Raster("gnn"), Raster(r"CANCOV"))

ERROR 000539: Error running expression: rcexec() <class 'arcgisscripting.ExecuteError'>: Failed to execute. Parameters are not valid.
ERROR 001000: Lookup field: Field C:\Users\csny490\Documents\ArcGIS\Default.gdb\CANCOV does not exist
Failed to execute (Lookup).

Failed to execute (RasterCalculator).
Failed at Thu Jan 12 16:40:32 2012 (Elapsed Time: 1.00 seconds)


An interesting note in that error message is this part:

Lookup(Raster("gnn"), Raster(r"CANCOV"))

I'm not sure what to make of it other than... why, in the error message, is it putting the "raster()" tag around the field name component?

I'm using v10.0 SP3 BTW...

[ChrisSnyder · Accepted solution]

Okay... I got it to work with the help-system advertised syntax of:

Lookup("gnn", "CANCOV")

The trick is (which makes sense to me now): Using the RasterCalculator toolbox tool, you MUST first set the workspace (geoprocessing envr. setting) to where the input raster datasets is located. If the Workspace remains set to it's default (that stupid Default.gdb thing), the tool will fail with the error message in my post aabove. Now that I think of it, the error message kinda makes sense now.

Prior to v10.0 you did not have to set the Workspace to get the map algebra (executed via ArcMap) to function properly... now you do!

I guess this is the difference between a toolbox-exectuted tool (RasterCalculator) and the now defunct pre-v10.0 Raster Calculator that was accesible through the Spatial Analyst toobar.

This is the correct syntax then:

Con((Lookup("gnn", "CANCOV") >= 70) & (Lookup("gnn", "STNDHGT") >= 23), 1, 0)

Too bad it now takes a way longer time to execute now that it has to extract the "CANCOV" and "STNDHGT" fields to seperate grids... When all it actually needs to do is build a cross reference table between the user-specified field value and the "Value" field, which is what the old "dot notation" syntax did.

But at least I got it to work...

ESRI: Please bring back native dot notation functionality... the kind that builds a crosstabulation table, not this new hokey kind that has to extract the field values out to seperate rasters.

[curtvprice]

 
Too bad it now takes a way longer time to execute now that it has to extract the "CANCOV" and "STNDHGT" fields to seperate grids... When all it actually needs to do is build a cross reference table between the user-specified field value and the "Value" field, which is what the old "dot notation" syntax did.

Lookup is a local operator, so I'm not so sure why they are creating a temp raster -- in theory they shouldn't have to -- are you sure it's doing this?

MOMA is much faster with this kind of thing because it didn't have to support projection on the fly or multiple formats.

I also discovered today that Lookup does not support joined fields -- which is too bad!

[ChrisSnyder]

According to the help, the lookup tool "Creates a new raster by looking up values found in another field in the table of the input raster."

I assume this is true based on the extraneous time it takes to run the tool, as well as the scratch raster I can see it creating when I run the lookup tool.

Seems a simple "behind the scenes" search cursor to pull out the appropriate "VALUE" field values (the "VALUE" values that match the dot notation query) would be what needs to happen... as I am guessing this is how the old dot notation worked with INFO tables.

[curtvprice]

Seems a simple "behind the scenes" search cursor to pull out the appropriate "VALUE" field values (the "VALUE" values that match the dot notation query) would be what needs to happen... as I am guessing this is how the old dot notation worked with INFO tables.

Yes, but the cell value had to be pulled cell by cell (or block by block if you were lucky and your grid was simple).

I pushed for the grid.item syntax too because then the field would be a property of the raster, very pythonseque -- but I'm guessing this was difficult to implement. Remember in grid and in 9x they were only (really) supporting one raster format, now we have native read-write which makes some things better for us -- but I'm sure it complicates the development picture.

The local operator stuff I was talking about has to do with ALL local operators. From what I've heard from the raster team, Lookup, being a local operator, should not have to create a real raster if it is embedded in a map algebra expression of only local operators.

I guess I'm not as wound up about this, the way I see it is the 10.0 map algebra changes are not all bad news -- native read write is nice and leveraging python is great, and I'm all for one syntax replacing three (SOMA, MOMA, Raster calculator) each with its own set of quirks.

But I sure wish Lookup supported joined fields and entered a incident with support on that. If grid.item is not feasible, I can live with that, but if so, Lookup needs more work. I put an incident request in on that. (UPDATE: Esri tells me it should be supported, hopefully they can reproduce my problem and we can fix whatever I'm doing wrong...)

I don't miss docell at all, but if I need it, workstation (and SOMA nad MOMA, if you're willing to open a 9.3 GP in your python script) still work in Windows 7, so I'm good until retirement 🙂

[DianeMcConnaughey]

Using 10.0 SP4 Windows.   Can the Lookup tool and Combine Tool be nested together in raster calculator - or is there a better approach to what I am trying to do.  Combine(Lookup("testy_fire_1988","FIRE_YEAR"),Lookup("testy_fire_1988","FIRE_YEAR")) .  I get an Error 00059.  The attribute is text, I added another attribute as short, and got the same error.   I would like to create a raster from fire history that has values for each year.  Fires overlap, so any area could get burned 1 -10 or more  times over the time period.  I made separate GRIDS for each year's fire history, and set NODATA = 0.

[ChrisSnyder]

Since it's a year value, it may be "cleaner" to ensure your FIRE_YEAR field is an integer value, but I think a text value "should" work as well. Maybe I'm missing something, but I'm not sure what combining the same attribute from the same raster will accomplish. Are these two different rasters?

Combine(Lookup("testy_fire_1988","FIRE_YEAR"),Lookup("testy_fire_1988","FIRE_YEAR"))

Normally the Combine tool is used to basically intersect two or more different rasters. The output is a single raster composed of at least three fields: one field for the VALUE of the new raster, one for the original VALUE of the 1st input raster, and another for the origional VALUE of the 2nd input raster.

[DianeMcConnaughey]

That was a typo, and I was trying to combine two different rasters. Testing the syntax first. I Have  about 35 that I will be combining, and the combine is limited to 20, so I will need to do in 2 batches, then combine the batches.
Combine(Lookup("testy_fire_1980","FIRE_YEAR"),Lookup("testy_fire_1981","FIRE_YEAR"),Lookup("testy_fire_1982","FIRE_YEAR"),Lookup("testy_fire_198x","FIRE_YEAR"),Lookup("testy_fire_199x","FIRE_YEAR"),Lookup("testy_fire_200x","FIRE_YEAR"),Lookup("testy_fire_201x1","FIRE_YEAR"))