ECEF.ECEFToLatLong
bertt opened this issue · 5 comments
Hi, I'm trying function ECEF.ECEFToLatLong to convert from ECEF (4978) to LatLon (4326) but I see a difference in result when doing the same in PostGIS.
Input (ECEF): 1231256.4091099831, -4800453.89645644844978,4000024.663498499
Code:
var ecef = new ECEF(1231256.4091099831, -4800453.896456448, 4000024.663498499);
var c = ECEF.ECEFToLatLong(ecef);
var longitude = c.Longitude.DecimalDegree;
var latitude = c.Latitude.DecimalDegree;
In PostGIS I do:
select ST_Transform(ST_SetSRID(ST_MakePoint(1231256.4091099831, -4800453.89645644844978,4000024.663498499), 4978), 4326)
PostGIS result: -75.61445 39.09641
CoordinateSharp result: -75.61445, 38.90835
Notice the difference in latitude (39.09 versus 38.90).
In my app the PostGIS result is 'better', so the question is how can I get the same result with CoordinateSharp?
Btw I'm using the latest CoordinateSharp NuGet package (2.13.1.1).
This is interesting. It appears to be an issue with how the ECEF is presented.
The LLA coordinate: -75.61445 39.0964100, -959.19m (the desired result) actually translates to ECEF as 1233496.98, 1002307.48, -6155232.29 using documented translation formulas.
CoordinateSharp translates this correctly and matches the PostGIS result. For some reason though the "inflated" ECEF you have provided throws the altitude calculation off in CoordinateSharp causing a snowball effect. Thanks for reporting this, we may have a bug in the math.
I will look into this.
The Naval Post Graduate School's algorithm also exhibits the same behavior. This may be a limitation of the James R. Clynch algorithm itself, not the implementation of it.
https://www.oc.nps.edu/oc2902w/coord/llhxyz.htm
http://clynchg3c.com/Technote/geodesy/coordcvt.pdf
Wil consider Bowring's method and compare to existing algorithm. Adjust as needed.
Note: The PostGIS altitude result (-959.1868) looks wrong to me, I expect something between 0 and 70 (meters). Like CoordinateSharp result c.Cartesian.Z value (0.62807) converted from radians to degrees (35.98).
Whew, ok I figured out the problem (I am actually embarrassed I didn't see this right away). The issue lies in the documentation, not the formula itself.
PostGIS expects X Y Z in meters, where as CoordinateSharp expects X Y Z in kilometers. The huge variation in height should have been my first clue.
You simply need to convert your input X Y Z values to kilometers (divide by 1000) and the formulas should work as intended.
https://dotnetfiddle.net/aV6WbU
I will update the documentation to make clear that KM is the expected input format.
ah ok! thanks!