Skip to main content
  • EN

Hi,

I tried to optimize an existing workflow by replacing all RasterCellCoercers by their PointCloud equivalent as described in:

https://knowledge.safe.com/content/idea/22245/spatial-statistics-on-raster-data.html

I however noticed that there is a small difference in the way the raster values are returned

Example:

My original raster value is equal to 23.835

The RasterCellCoercer returns 23.835.

The PointCloedCoercer however returns a value of 23.834975...

When I round these values to 2 digits I get 23.84 and 23.83, depending on the method that was used to extract the raster values.

I think this has something to do with the fact that the data type of the components is changed to 'Real64', as described in the logfile:

'PointCloudCoercerFactory: Converting component 'z' from type 'Real32' to 'Real64'. If this conversion is undesired, consider changing the type explicitly'

Has anyone experienced a similar issue? Any suggestions on how to tackle this problem? I tried using the PointCloudComponentTypeCoercer but so far it did not do the trick.

Hi @kd thanks for posting your question!

 

What version of FME are you using? Would you be able to provide your workspace and some sample data (or both together as a workspace template)? A logfile of the translation would help analyze the issue, too!

 

Thanks,

 

Nathan

You should round the PointcloudCoercer result to three digits first!

You should round the PointcloudCoercer result to three digits first!

Hey, that was my initial idea aswell but unfortunately it does not always work.

 

When my original value is for example 2.834, I want it to be rounded to 2.83. The PointCloudCoercer sometimes however returns a value of 2.8345... which rounds to 2.835 (3 digits) and afterwards to 2.84 (2 digits).

 

 

Hey @NathanAtSafe ,

 

 

I am currently using FME 2015.0 - Build 15250 - WIN64.

 

I added a small sample dataset and workspace to this comment.

 

pointcloud-issue.zip

 

 

Hello @kd,

I've tried your example workspace in the latest version of FME Desktop 2017.1

As you can see the last tester shows no differences between the values.

Please upgrade to the latest version of FME!

Hello @kd,

I've tried your example workspace in the latest version of FME Desktop 2017.1

As you can see the last tester shows no differences between the values.

Please upgrade to the latest version of FME!

Hi @stalknecht,

 

 

Thanks for your reply. I used the latest version of FME and tested your method.

 

It seems that the RasterCellCoercer changed its behaviour in the latest version of FME.

 

When you take a look at the pixel with count = 273, you see that the RasterCellCoercer, just like the PointCloudmethod, now also extracts a value that is different from the original raster (namely 10.9549.... instead of 10.955 as it used to do). So when I round this value I get 10.95 instead of the 10.96 I was looking for (and got in previous versions).

 

 

So even though the PointCloudCoercer and RasterCellCoercer now give the same result, I still prefer the old RasterCellCoercer's method since it extracts the rastervalues in a 'better' /not rounded way.

 

 

Thanks for the help!

 

 

 

 

 

Hi @kd, I think the different results you have observed is caused by the difference in precision between single precision floating point numbers and double precision floating point number.

The band interpretation of your sample raster was REAL32, so the values extracted by the RasterCellCoercer will have single precision.

On the other hand, coordinate values of vector features generally have double precision, in FME processing. Since you have used the @ZValue() function to get the z-coordinate values of the points created from the point cloud, the resulting values will have double precision.

If you coerce the raster interpretation to REAL64 with the RasterInterpretationCoercer at first in the workflow, extracted z values on the both flows could exactly match, even without rounding.

Hi @kd, I think the different results you have observed is caused by the difference in precision between single precision floating point numbers and double precision floating point number.

The band interpretation of your sample raster was REAL32, so the values extracted by the RasterCellCoercer will have single precision.

On the other hand, coordinate values of vector features generally have double precision, in FME processing. Since you have used the @ZValue() function to get the z-coordinate values of the points created from the point cloud, the resulting values will have double precision.

If you coerce the raster interpretation to REAL64 with the RasterInterpretationCoercer at first in the workflow, extracted z values on the both flows could exactly match, even without rounding.  

Alternatively, you can cast the z-coordinate values extracted from the point cloud to single precision with the @real32 function, so the values match the single precision values extracted with the RasterCellCoercer.

 

@Evaluate(@real32(@ZValue()))

0684Q00000ArMOXQA3.png

Hi @kd, I think the different results you have observed is caused by the difference in precision between single precision floating point numbers and double precision floating point number.

The band interpretation of your sample raster was REAL32, so the values extracted by the RasterCellCoercer will have single precision.

On the other hand, coordinate values of vector features generally have double precision, in FME processing. Since you have used the @ZValue() function to get the z-coordinate values of the points created from the point cloud, the resulting values will have double precision.

If you coerce the raster interpretation to REAL64 with the RasterInterpretationCoercer at first in the workflow, extracted z values on the both flows could exactly match, even without rounding.

Thanks @takashi,

 

 

I managed to cast the z-values to single precision and both methods now return exactly the same result. Thanks for the help!

 

 

Reply


Community Stats

30,187
Posts
114,579
Replies
37,853
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.