Skip to main content
  • EN

 

Hi,

 

I am using a pythoncaller in FME to convert the KML color from the linestyle (a string, hex ABGR) to a C# Color (ARGB 32 bits integer) (see workbench)

 

 

KML doc Colorstyle (https://developers.google.com/kml/documentation/kmlreference#colorstyle):

 

For example, if you want to apply a blue color with 50 percent opacity to an overlay, you would specify the following: 

<color>7fff0000</color>, where alpha=0x7f, blue=0xff, green=0x00, and red=0x00. (ABGR !)

 

 

 

With FME Desktop under Windows (2021.2.4), this works well.

=> 2022-03-29 18:00:28|  0.6| 0.0|INFORM|Attribute(32 bit integer)     : `line_color' has value `-16733441'

  

  

Running this workbench on the Linux FME server (docker install!) gives different results.

=> 2022-03-29 16:01:14|  0.2| 0.0|INFORM|Attribute(64 bit integer)     : `line_color' has value `4278233855'

 

I have some questions here:

 

1) Why does this happen?

2) How do I solve this?

3) Is there a more elegant and consistent way to accomplish this conversion? I do need to process the kml style element, and cannot rely on the fme_color attribute...

 

Thanks,

 

Richard.

It's actually exactly the same (bit for bit) underlying value, the difference is whether the bits are interpreted as signed or as unsigned, and whether they are interpreted as 32- or 64-bit integers.

See https://onlinetoolz.net/unsigned-signed#base=10&value=4278233855&bits=32

What happens if your use your result as-is?

Hi,

Thanks for the link (and the swift reply). I will look into this a bit.

I'm expecting a (signed) int both under windows and under linux, since this will be eventually be stored in Postgres (int4 datatype). However, under linux (fme server) the feature is silently dropped by the writer : "Value of attribute 'line_color' could not be converted to type 'int4'. Feature will be logged and skipped" . This results in an incomplete translation...

Hi,

Please find attached an adjusted version of the test workbench. This works both in FME Desktop (windows 2021.2.4) and on the FME Server (linux host / docker 2021.2.4). Questions remain, however:

 

  • What is causing this ? FME version change (e.g. upgraded python modules) or a platform change (from windows to linux)?
  • Is there documentation/articles that might help me spotting similar issues in advance?

 

Regards,

Richard.

I'm wondering if it may be the Python code. If I understand correctly the requirement is simply to change the hexadecimal number to a decimal one, so I've tried that with a BaseConverter to convert from Base 16 to Base 10 and it yields 4294945280 on both Windows and Linux (FME Cloud)

Hi, 

Thanks for the link (and the swift reply). I will look into this a bit. 

I'm expecting a (signed) int both under windows and under linux, since this will be eventually be stored in Postgres (int4 datatype). However, under linux (fme server) the feature is silently dropped by the writer : "Value of attribute 'line_color' could not be converted to type 'int4'. Feature will be logged and skipped" . This results in an incomplete translation...

You can force the result to always be a 32-bit signed integer using the following technique in your PythonCaller:

>>> import ctypes
>>> color = 4278233855
>>> number = color & 0xFFFFFFFF
>>> print(ctypes.c_long(number).value)
-16733441

 

Reply


Community Stats

30,157
Posts
114,473
Replies
37,802
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.