Skip to main content
I am using inspection point before and after the CoordinateRounder transformer to notice that only few coordinates are rounded while others are left untouched.

 

 

Is it something others have noticed?
if I put x and y to be rounded at decimal 2 thats what the transformer do:

 

 

-68.469999999999999, 48.520000000000003

 

 

weird?
If you want to decrease the number of coordinates to store a liteweight geometry into a database, this is not helping at all. Is it really impossible to round coordinates in FME?
Hi Burton,

 

 

I also noticed that, and asked Safe's support a few months ago.

 

Their answer was:

 

The transformer does its job in that there are no significant values after the precision value specified. However, since these numbers are internally represented as floating point, and there isn't a one-to-one correlation between decimal and binary representations, we can't guarantee they will be precisely the same.

 

Currently, values such as 1.0000 are rounded to 1, and values with significant values after the decimal are displayed in full. What can be done is allowing the user to display these values differently.  We already have a feature request for this. When writing out to a format that supports floating point precision, the output will of course honour this setting.

 

 

FYI.

 

 

Takashi
Hi,

 

 

this site does a good job at explaining the part in Safe's answer where they mention the problems in representing binary represenations of floats as decimals:

 

 

http://floating-point-gui.de/errors/rounding/

 

 

David

 

 

(edited link)
Thanks both of you for those precisions. That make sense. The new feature would be interesting. Until then, maybe using OGR library outside FME could be the best workaround to round coordinates for files format that allow it. For database, doing the rounding inside the database is not a problem neither.

I am using inspection point before and after the CoordinateRounder transformer to notice that only few coordinates are rounded while others are left untouched.

 

 

Is it something others have noticed?

I have the same problem. When exporting from oracle to gpkg CoordinateRounder goes crazy. In the inspector i can see coordinates X, Y (after CordinateRounder to 3 places), same coordinates written in GPKG:
-743759.503, -1176600.902 → -743759.5029993765, -1176600.901995358
-743752.291, -1176586.212 → -743752.2909993764 -1176586.2119953525

And that is sad. This is not coordinate rounding.


I am using inspection point before and after the CoordinateRounder transformer to notice that only few coordinates are rounded while others are left untouched.

 

 

Is it something others have noticed?

I have the same problem. When exporting from oracle to gpkg CoordinateRounder goes crazy. In the inspector i can see coordinates X, Y (after CordinateRounder to 3 places), same coordinates written in GPKG:
-743759.503, -1176600.902 → -743759.5029993765, -1176600.901995358
-743752.291, -1176586.212 → -743752.2909993764 -1176586.2119953525

And that is sad. This is not coordinate rounding.

Do you by chance have a different projection defined in your Geopackage Writer? This does seem a bit weird.


I am using inspection point before and after the CoordinateRounder transformer to notice that only few coordinates are rounded while others are left untouched.

 

 

Is it something others have noticed?

I have the same problem. When exporting from oracle to gpkg CoordinateRounder goes crazy. In the inspector i can see coordinates X, Y (after CordinateRounder to 3 places), same coordinates written in GPKG:
-743759.503, -1176600.902 → -743759.5029993765, -1176600.901995358
-743752.291, -1176586.212 → -743752.2909993764 -1176586.2119953525

And that is sad. This is not coordinate rounding.

Do you by chance have a different projection defined in your Geopackage Writer? This does seem a bit weird.

GPKG Writer is set to:

  • Version: 1.2
  • Coordinate System: EPSG:5514 ..This is correct in our country (X and Y are negative)

    This is input data in Inspector before CoordinateRounder:

This is Inspectora after CoordinateRounder:
 

And this is final result loaded GPKG via FME to Inspector:
 

So i have no idea what hapend.


I am using inspection point before and after the CoordinateRounder transformer to notice that only few coordinates are rounded while others are left untouched.

 

 

Is it something others have noticed?

I have the same problem. When exporting from oracle to gpkg CoordinateRounder goes crazy. In the inspector i can see coordinates X, Y (after CordinateRounder to 3 places), same coordinates written in GPKG:
-743759.503, -1176600.902 → -743759.5029993765, -1176600.901995358
-743752.291, -1176586.212 → -743752.2909993764 -1176586.2119953525

And that is sad. This is not coordinate rounding.

Do you by chance have a different projection defined in your Geopackage Writer? This does seem a bit weird.

GPKG Writer is set to:

  • Version: 1.2
  • Coordinate System: EPSG:5514 ..This is correct in our country (X and Y are negative)

    This is input data in Inspector before CoordinateRounder:

This is Inspectora after CoordinateRounder:
 

And this is final result loaded GPKG via FME to Inspector:
 

So i have no idea what hapend.

OK so I did a bit of testing and it seems that this is either happening in the Geopackage writer or the Geopackage reader. I was also able to reproduce this.

Strangely, What I did find to help was using the FME name coordinate system instead of the EPSG code.  

 

Here using the EPSG code to define the coordinate system resulted in different coordinates.

 

By contrast using the FME coordinate system name does not result in changed coordinates. 

My assumption here is that there is some kind of small reprojection happening somewhere. 

I’m not sure if you are able to work around the issue like I have. Either way it seems like an issue which should be reported to Safe


@virtualcitymatt Thank you so much! You were absolutely right. I set the WRITERs output GPKG coordinate system to Czech/JTSK.Krovak (previously it was set to EPSG:5514), and now I'm getting the correct coordinate rounding.


Reply