wgs84_etrs89 deviation

[raue]

Hello,

I'm planning to use the wgs84_to_etrs() function. But I have some doubts about the correctness, due to my following example:
$ pycraf.geospatial.wgs84_to_etrs89(10.234277034617 * u.deg, 52.403406485378 * u.deg)
Result:
(<Quantity 4336944.84215441 m>, <Quantity 3254912.90967703 m>) ... which looks somehow questiionable.

The coordinates glon/glat I gave in above refers to a place in Germany, north west to the city of Braunschweig. The expected result would be close by:
East: 583967.725, North: 5806623.881. I've double checked this w/ another converter (s. LINK), which comes to the same/expected result.

In addition I tried the sample/test data available in github (i.e. wgs84_etrs89.npz). Here the conversion matches the input and outout data given in that file. But by using the other converter from the above link, the results are totally different and do not match the given results in the test data file.
For example: Taking the first point from the test data file:

• The input glon/glat values in degree point to a place somewhere in the middle of the North See, west of Denmark;
• Taking the output values in elon/elat take you somewhere down to Saudi Arabia

With the 10th value of the given tetst data set I've compared w/ another tool, which seems to have a good reputation (s. LINK). The outcome from that tool also differs from the given testset.

Conclusion at that point - unless I've missed something important - would be, that wgs84_to:etrs89() is not working properly.

Regards

rainer

System:

• Windows 10 Enterprise
• Python 3.9.2
• PyCraf 2.0.2
• Numpy 1.23.4
• Astropy 6.0.1

[bwinkel]

Dear @raue,

thanks a lot for pointing this out. Before I explain, what's going on, let me quickly say that pycraf does not do these calculations itself, but just provides a wrapper about the pyproj package (which itself is a wrapper around the C++ proj4 software). Thus, any error is usually either owing to the underlying packages or an issue with the coordinate definition.

In this particular case, I believe the deviation comes from the existence of different ETRS89 systems (I'm not really into geographical projection/coordinate systems, so my apologies if I'm talking nonsense). In pycraf, the "Lambert Equal Area" version of ETRS89 is used. To be honest, I have no clue if this is the most appropriate one or not - it is just the one that was used for a case that I had to deal with myself. You can quickly check by using another nice online calculator which I found (compare ETRS 89 / ETRS-LAEA vs. ETRS89 (UTM)).

You could obviously use pyproj to do your own desired coordinate transformations, or, if you like the pycraf interface better, construct a new transformation function with the help of the transform_factory.

I'll keep the issue open for now, as it will remind me to improve the documentation, highlighting this potential pitfall.

Cheers