Extract pixel

You can use the RasterExpressionEvaluator for this.

Something like A[0] = if(A[0]=3 || A[0]=8 || A[0]=9 , A[0] , 0)

A[0] is Raster A with band 0.

So if the cell value = 3 or 8 or 9 keep the value. Else set it to zerro. Or pick the nodata value your raster already has.

Hi,

Unfortunately, nothing worked.

I tried many other expressions, but none of them worked properly.

Could you help me?

Attached follows my raster file

This expression work, but the result is not good

if (A[0]==3 || A[0]==8 || A[0]==9 , A[0] , 0)

The result image is all black 

Indeed!

(results of RasterToPolygonCoercer)

But there seems to be something wrong with the || in the if-expression.

A[0]*25  , if (A[0]==5 , A[0]*25 , 0) , if (A[0]>=4 && A[0]<=5, A[0]*25 , 0) and if (A[0]<7 , A[0]*25 , 0) all work like a charm.

@geomancer What expression does not work? Because I did not see anything unexpected.

if (A[0]==3 || A[0]==8 || A[0]==9 , A[0] , 0)  This will result in an all black image with everything to 0 because there is no ‘true’-cell.

if (A[0]==4 || A[0]==5 || A[0]==6 , A[0] , 0) gives all 0 values as well.

Preserve = if(A[0]==4||A[0]==5||A[0]==6,A[0],0)

works like a charm:

Using 2021.2.6

Sorry,

It works very well! @jkr_wrk mentioned it correctly!

My file does not have pixels 3, 8, and 9...

I’m very grateful for your help.

Many thanks. @jkr_wrk @geomancer 

I'm glad the problems of mr_fme are solved.

But still, something strange seems to happen in version 2023.1.

It appears the ‘logical or’ || is not working correctly here.

Hi, @geomancer ,

Thanks for your answer.

Yes, I had already seen it. It happens in version 2024.0 too.

I solved this problem as shown below:

The II does not work properly.

Thanks again for your attention.

@fmelizard could you report this as a bug?

This question (from - at this moment - 8 years ago) contains an aswer that states that this problem is caused by the presence of NoData. The answer suggests to remove the NoData value, and add it back after the RasterExpressionEvaluator.

I can confirm this works in 2023.1:

It still looks like a bug though...

That's the reason it worked for me. I did not add NoData before the Evaluator, set everything within the Evaluator to 0 and then set the 0 to NoData after.

But this could have been a problem I ran into in the past without knowing.

Hi, all.

Thanks for posting @mr_fme.

This behavior is expected, not to worry. The result of (almost) any operation involving Nodata will be Nodata (e.g. nodata + 1 = nodata, nodata || 1 = nodata, etc.). The only exception is the @isnodata function which can be used to check for Nodata (e.g. if(@isnodata(A[0]),<true value>,<false value>). If you have any more questions, don't hesitate to ask; happy to help!

Thanks for your answer, @AliAtSafe . I'm still a bit worried though...

Let's take a pixel with value 4, and apply some expressions.

I would expect the last expression to return A[0] (i.e. 4). I think there is no nodata involved here, only True or False or False (which should result in True).

The presence of nodata elsewhere in the raster should have no influence on the results of the expression for this pixel.

Could it be that A[0]==5 results in False which results in nodata because both nodata and 0 and False are all binary 0?

So FME reads as if( True || Nodata || Nodata, A[0] , Nodata)

I still think it's a bug when a cell that contains data is evaluated to nodata because of an OR statement.

My point exactly 😉

Good thinking!

When I use a RasterBandNodataSetter to set 99 as Nodata I have no problems with || (logical or).

So indeed, only setting 0 to Nodata gives unwanted results when using || (logical or).

Like you say, when 0 is Nodata, False is interpreted as Nodata.

I still say this is a bug… 

Hi, all!

Thank you for your patience.

There is a related note in the documentation about this:

Nodata and Zero (0) Values: Expression evaluation often involves changing interpretation types of values, and can sometimes result in unpredictable behavior particularly in the case of zero (0).

A recommended workaround for a nodata value of 0 is to just remove the nodata value with a RasterBandNodataRemover before the RasterExpressionEvaluator and restore it with a RasterBandNodataSetter afterwards.

We would like to hear your feedback/suggestions on how this scenario could be improved/helpful in FME (have seen some mentioned).

Potential improvement we could make:

• Log a warning when nodata value of 0 is present to let the user know they may get unexpected results.

Let us know your thoughts/suggestions. Thanks all!

Thank you for your reply.

FME 2023.1 gives this warning:

Expression Evaluator: Applied operation to a nodata value and a valid value. The result will be set to nodata. Consider using the RasterBandNoDataRemover or RasterBandNoDataSetter if this is undesired

This confused me for a while, as I had no idea where this Nodata value was coming from.

 I think it may be improved to something like:

Expression Evaluator: Applied operation to a nodata value and a valid value. The result will be set to nodata. This may be caused by using 0 as Nodata. Consider using the RasterBandNoDataRemover or RasterBandNoDataSetter if this is undesired

But overall I think the best improvement would be that FME makes a distinction between False and 0 (and between True and 1 as well). Using 0 as Nodata really should give the same results as using any other value as Nodata.

Raster has Nodata = 0. Then (False || True) will result in Nodata. (True && True) will be 1.
Raster has Nodata = 1. Then (True && False) will result in Nodata. if(True && True, 5,10) will result in Nodata.

Setting Nodata to 1 is not very usual, but could happen.

Could be the fix in the code needs to be if(Value===Nodata) and not if(Value==Nodata)?

Hello all!

Thanks for your patience. We have made an enhancement request based on feedback here [FMEENGINE-83716]. The enhancements should be in the next release of FME Form 2024.2 beta.

Best and thank you!

Thanks for the update.