Solved

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

  • 14 December 2022
  • 3 replies
  • 16 views

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

icon

Best answer by evieatsafe 15 December 2022, 00:30

View original

3 replies

Userlevel 4
Badge +26

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

Userlevel 1
Badge +15

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