It all comes down to mathematics, geometry precision (number of decimals used) and decimal to binary (and reverse) conversion.

A computer stores decimal numbers as binary (1 and 0) with a given precision (integer, float, double, signed/unsigned). When you convert from dec to bin and back to dec, if you use enough decimals, you get a different number. Generally the last decimal is different.

The same thing applies to CRS reprojection. Each operation introduces a very small conversion error, and they accumulate fast.

But it is a big problem not to have the posibility of manage decimals used into the reprojection transformer, because if you need a high precision you are in trouble.

And I also have tried a similar translation with Arcgis and it doesn´t happen. The library that uses Arcgis to reproject the information seems to work with fewer decimals then.

Thanks

Why do you transform from geographic to projected and back to geographic? Can you maybe get away with using a GeometryExtractor to store the geometry in an attribute first, then transform to projected, do whatever you need to do there and then use a GeometryReplacer to replace the projected geometry with the original (geographic) one, thereby avoiding the second transformation alltogether?

I can´t do that, beacause in between the projection transformations I will change the geometry splitting many features. And after splitting features I need to get back to geographic coordinates.

But I think I´ve found the solution. There is a transformer called "esrireprojector" that works good, without displacement after the reprojections . This transformer seems to use Arcgis reprojection library, and as I said in Arcgis there wasn't any problem with the sequence of reprojection.

Thanks.