Skip to main content
Solved

How to avoid setting numbers manually as double in the feature writer

  • December 14, 2022
  • 3 replies
  • 77 views

mferber

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

Best answer by evieatsafe

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!

View original
Did this help you find an answer to your question?

3 replies

virtualcitymatt
Celebrity
Forum|alt.badge.img+34

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...

 

 


mferber
  • Author
  • December 14, 2022
virtualcitymatt wrote:

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


evieatsafe
Safer
Forum|alt.badge.img+18
  • Safer
  • Best Answer
  • December 14, 2022

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!


Cookie policy

We use cookies to enhance and personalize your experience. If you accept you agree to our full cookie policy. Learn more about our cookies.

 
Cookie settings