Skip to main content
  • EN
Is there any way I can pass a non numeric attribute to the RasterExpressionEvaluator?

 

 

Specifically I want to pass a conditional statement.

 

ex.

 

If(AI0]==somevalue || A|0]==someothervalue,0,255)

 

 

I can't really build the statement in the expression evaluator directly because I don't know in advance how many parts the conditional will have.

 

 

I keep getting the error Expression Evaluator: Attribute '_Recode' has non-numeric value, but if I hardcode the resolved expression directly in the RasterExpressionEvaluator it works exactly as expected.

 

Hi,

 

 

If "somevalue" and "someothervalue" are attribute names which are held by the input raster feature A, I think the expression should be shown like this in the Raster Expression editor. @if(A(0]==@Value(A:somevalue) || A 0]==@Value(A:someothervalue),0,255)

 

 

Takashi
ah... the question was a way to pass non-numeric attribute. However, I think that the value which will be compared to a band value (i.e. A[0]) should be numeric value. Even if it could be possible to pass non-numeric value, the condition (A[0]==<non-numeric value>) would be always false since A[0] is a numeric value. I'm not sure what is the purpose to pass non-numeric value...
Sorry I wasn't clear.

 

 

I want to pass an attribute that contains the full condition statement

 

 

If(AI0]==2 || A|0]==3||A30]==27,0,255)

 

 

The RasterExpressionEvaluator would have just A:expr

 

 

Joanna
I understood your question, but couldn't find a solution... It seems that there is not a way to make the RasterExpressionEvaluator interpret a character string as an executable expression.
I'm trying to do something similar. I would like to take numeric values being created in another transformer (value1) and pass them into the raster expression evaluator as the value to be tested for, so (A[0] == value1
I'm trying to do something similar. I would like to take numeric values being created in another transformer (value1) and pass them into the raster expression evaluator as the value to be tested for, so (A[0] == value1

@ajbaum77, I think it's possible with this syntax if the attribute value is numeric.


@if(A[0]==@Value(A:value1), ...

You can insert "@Value(A:value1)" by double-clicking the attribute name in the left pane of the expression editor (or drag-and-drop from the left pane to the editor).

For the original question (which I know is an older one now), would this work:

 

 

If you try this and it fails, then let me know. Seems no point in having that option if it doesn't work.

 

 

You can circumvent the need for the expressionevaluator by going the colormap-way.

 

If you look at your expression and would stack a couple of lines you almost can see your colormap....

 

It should be easy to use stringfunctions to build your map and apply it.

 

Forum has colormap examples.

 

Ans Takashi can surely show u the way 😉
addendum

 

 

You cannot use a attribute to pass the expression. Indede because FME will interpret as an raster variable...

 

 

But you can pass it using a (user)parameter... strangely inconsequential but who cares.

 

So, this opens a workspacecaller psossibility.
For the original question (which I know is an older one now), would this work:

 

 

If you try this and it fails, then let me know. Seems no point in having that option if it doesn't work.

 

 

I'm going to have to go archive diving to see what project that was about.

@markThat does not work because, at least it seems so, it adds the "A:" to the attribute name and then expects a numeric value.

 

Whereas it does not do that (add the "A:") if u use a parameter.

 

 

Seems easy to fix the code, yes?
@markThat does not work because, at least it seems so, it adds the "A:" to the attribute name and then expects a numeric value.

 

Whereas it does not do that (add the "A:") if u use a parameter.

 

 

Seems easy to fix the code, yes?

Yes, I shall log this with the developers to see what they can do. Thanks for checking it out.

@markThat does not work because, at least it seems so, it adds the "A:" to the attribute name and then expects a numeric value.

 

Whereas it does not do that (add the "A:") if u use a parameter.

 

 

Seems easy to fix the code, yes?

It's filed with the development team as PR#54026 - it has a high priority so hopefully it will be worked on shortly.

Is there any updates concerning this issue? I am also trying to sum several raster using an attribute as expression but FME failed to recognize the expression. This expression needs to be created with PythonCaller as I can not know before the FME process how many raster are summed up. Indeed my raster number is dependant on several seamlines.

Using a hard-coded user-parameters will be correctly interpreted by FME but is not a solution for automated workflow.

I tried a workaround by putting the rasterExpressionEvaluator in a custom transformer which instantiate a user-defined parameter with an attribute from my main workflow but FME still failed to understand the expression.

Why is a string within an attribute not understand by the RasterExpressionEvaluator?

@Mark2AtSafe Any news regarding this transformer? It would be fantastic if it was possible to a) pass an attribute value containing an expression, and b) reference attributes inside the expression, making the transformer more coherent with the other transformers.

I would also be interested in an answer to this - even in 2018.0 we cannot pass this transformer an expression as an attribute.

I would also be interested in an answer to this - even in 2018.0 we cannot pass this transformer an expression as an attribute.

In case anyone else needs a workaround.

 

 

Ideal situation = I store expressions in a spreadsheet or database and pass them to the transformer as an attribute.

 

 

Workaround = I created a scripted (private) parameter containing a load of if statements. Then returned the expression based on the result of these if statements. The transformer accepts a private parameter, as pointed out by gio below.

 

To answer the folks asking about this, it's still waiting for development. The priority is already set as high as is possible, so I can't really push it higher. If this (or any issue for you) is really important, and you haven't contacted Safe directly, then do so. The number of support cases added to an enhancement request helps to decide which is implemented first. Also check if it's an idea on this site and if so be sure to vote it up. Like I said, it's a got a high priority, so I expect it will get done, but I can't guarantee when that would be. I'll do my best to advocate on your behalf though.

Reply


Community Stats

30,132
Posts
114,380
Replies
37,769
Members
Terms & ConditionsCookie settings
A product of
Safe Software respectfully acknowledges that we live, learn and work on the traditional and unceded territories of the Kwantlen, Katzie, and Semiahmoo First Nations.