Skip to main content
  • EN

Hi,

 

I would like to force FME into treating my numbers as double before sending it to the feature writer transfomer. This allows me to make use of the automatic user attribute functionality, otherwise I would to manually define each attribute, which is cumbersome.

 

For example:

I have calculated the difference between reported and measured plot sizes. The result is stored in a colum as number, but it seems that FME interprets the number as string ... no matter if I use the @Evaluate() function or any other math function ... also string replacer cant change that. The result is always the same: i have to change the format in the feature writer, which I would like to avoid.

 

2022-12-14 13_29_39-Windowmain_plot_diff is left aligned, showing that FME interprets the data as string.

 

 

2022-12-14 13_30_15-Windowstring replacer is powerless...

 

 

2022-12-14 13_30_54-Window... and the feature writer also interprets the data as string

This was claimed to be added back in FME 2020, however, there are quite clearly still some inconsistencies with it. (https://community.safe.com/s/question/0D54Q000080hgdqSAA/attribute-data-type-preservation-in-fme-2020).

 

A silly workaround which I found was to use a RandomNumberGenerator to define first the attribute earlier in the workflow. you can use something like a tester to test where 1 = 2 so that the fake data never pass. It's not a real solution by any means or a very good workaround for that matter but it does help to highlight the issue.

 

imageYou can see in this screen shot I even replace the value with a string in the AttributeCreator but the type in the output schema is still 'double'.

 

Whats even more fun is that there are no warnings or ERRORS in the logfile but the output shapefile has 'missing' values...

 

 

This was claimed to be added back in FME 2020, however, there are quite clearly still some inconsistencies with it. (https://community.safe.com/s/question/0D54Q000080hgdqSAA/attribute-data-type-preservation-in-fme-2020).

 

A silly workaround which I found was to use a RandomNumberGenerator to define first the attribute earlier in the workflow. you can use something like a tester to test where 1 = 2 so that the fake data never pass. It's not a real solution by any means or a very good workaround for that matter but it does help to highlight the issue.

 

imageYou can see in this screen shot I even replace the value with a string in the AttributeCreator but the type in the output schema is still 'double'.

 

Whats even more fun is that there are no warnings or ERRORS in the logfile but the output shapefile has 'missing' values...

 

 

Thanks for illustrating the issue with even brighter colours

Thanks for bringing this up @mferber​ & @virtualcitymatt​ this now being supported with the AttributeCreator & AttributeManager in 2023.0 which you can now download the beta, there are a couple of issues with it right now but hopefully they can all be found and addressed before official release. Let us know if the new version works for you!

Reply


Community Stats

30,126
Posts
114,374
Replies
37,766
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.