I am using Proj4Net to convert between coordinate systems. I've noticed that when I convert from one coordinate systems (CRS) and them back to the original CRS, the coordinate Y values have changed when I convert back to the original CRS.

E.g. Original EPSG 2105 X: 372893.221 Y: 809590.1314

Convert to EPSG 3857: X: 19420845.9813353 Y: -4410280.07002807

Convert back to EPSG 2105 X: 372893.221025973 Y: 809590.123207413

I have since used several different EPSG values with the same sort of results.

Its always the coordinate Y values that are distored from the original.

The coordinate X values seem to convert relatively correctly.

Here is the code from my method that converts between CRS:

            var cs_from = SridReader.GetCSbyID(from_epsg);
            var cs_to = SridReader.GetCSbyID(to_epsg);

            var ctfac = new CoordinateTransformationFactory();
            var trans = ctfac.CreateFromCoordinateSystems(cs_from, cs_to);

            var from_TopLeftCorner = new double[] { bbox_from.Min_X, bbox_from.Max_Y };
            double[] toTopLeftCorner = trans.MathTransform.Transform(from_TopLeftCorner);

            var from_BottomRightCorner = new double[] { bbox_from.Max_X, bbox_from.Min_Y };
            double[] toBottomRightCorner = trans.MathTransform.Transform(from_BottomRightCorner);

            var converted_bbox = new BoundingBox_Model
                Min_X = toTopLeftCorner[0],
                Max_Y = toTopLeftCorner[1],
                Max_X = toBottomRightCorner[0],
                Min_Y = toBottomRightCorner[1]

Is this behaviour expected or am I doing something wrong?

As I am inserting the image to use for GIS the image's location needs to be extremely accurate.

Is this possible when converting between CRS?

  • 4
    The accuracy of an image has little to do with the precision of its coordinates. Depending on the platform, it's unlikely the imagery's location is accurate to 20cm, so only 2cm precision loss passing into Web Mercator and back is pretty good. As a rule, you should not subject images to that kind of abuse (converting to a projection where distance is meaningless and back), so this is a borderline non-issue.
    – Vince
    Aug 2 at 0:34
  • Thanks for the information! :-) If you meant, why do you need to do this? It's because this is for a WMTS tile server and the drone image was cut into tiles using EPSG: 3857. The Image CRS is EPSG: 2109. This is all new ground for me, so I will go back to the team making the tiles to see if they can keep it in EPSG 2109?
    – scott_f
    Aug 2 at 0:46

Proj4Net seems to be a port of Proj4J that is a port of Proj.4 https://trac.osgeo.org/proj4j/.

The Proj.4 library is using EPSG:4326 as a pivot coordinate system so the conversion from EPSG:2105 into EPSG:3857 goes actually through the route EPSG:2105 -> EPSG:4326 -> EPSG:3857. Theoretically that should be a reversible route but several conversions in a row tend to make some rounding errors etc.

The new Proj library versions make conversion from EPSG:2105 into EPSG:3857 directly and the accuracy of the conversion is probably only limited by the inaccuracies in floating point computing as you can see from a test with the gdaltransform utility

gdaltransform -s_srs epsg:2105 -t_srs epsg:3857
Enter X Y [Z [T]] values separated by space, and press Return.
372893.221  809590.1314
19420845.9813354 -4410280.06502225 0

gdaltransform -t_srs epsg:2105 -s_srs epsg:3857
Enter X Y [Z [T]] values separated by space, and press Return.
19420845.9813354 -4410280.06502225
372893.221000015 809590.131399999 0

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.