Conversion inconsistencies

[kjetilkjeka]

I'm getting weird results when combining "earth centered" coordinate systems (WGS84 + ECEF) with ENU and NED.

If i've understood everything correctly a conversion between ENU and WGS84 (or ECEF) can be done by wgs84_coordinates - wgs84_origin

    let oslo = WGS84::new(59.95, 10.75, 0.0);
    let stockholm = WGS84::new(59.329444, 18.068611, 0.0);

    // Calculate vectors between positions
    // This is equivalent of doint `ECEF::from(stockholm) - ECEF::from(oslo)`
    let vec: ENU<f64> = stockholm - oslo;
    println!("Vector between Oslo and Stockholm: {:?}", vec);

    > Vector between Oslo and Stockholm: ENU(Vector3 { x: -361169.42321972427, y: -114370.90908214542, z: 177247.8139263628 })

1. This can't be right as Stockholm is further east than Oslo and x is negative.
2. Proportions between east and north coordinates seems to be wrong as well, but this might be the map projection tricking me.
3. It seems wrong that the earth curvature gives this high z component. And shouldn't z be negative due to earth curvature.

    println!("Oslo: {:?}", oslo);
    println!("100m over Oslo: {:?}", (oslo + ENU::new(0.0, 0.0, 100.0)));
    
    > Oslo: WGS84 { lat: 1.0463248865706005, lon: 0.18762289458939044, alt: 0.0 }
    > 100m over Oslo: WGS84 { lat: 1.0463304101453916, lon: 0.1876383029847326, alt: 79.60187816944847 }

The earth isn't perfectly round but it seems excessive that 100m ENU up translates into 80m WGS84 altitude.

Do you agree with my logic or is there something I've missed?

[nordmoen]

Yeah, both of those problems seem to be correct. I have not had much use for this library after release so it is probably due for a complete rewrite. My intention of having most of the type be interchangeable does not fit well with Rust philosophy and have lead to the problems above. If you need any of the types here I would suggest ripping them out, reviewing the math and proceeding with a new library.

[kjetilkjeka]

My intention of having most of the type be interchangeable does not fit well with Rust philosophy and have lead to the problems above.

What do you mean by this? Isn't the problem just a bug in the conversion between ECEF and ENU? Using the rust type-system to "automatically" find out which conversions needs to be done sounds like a good idea to me? Do you mind explaining what conceptual problems you see?

[nordmoen]

I was more thinking of the conversion between WGS84, N-Vector and ECEF. ENU and NED conversions are fine since there is no performance penalty, however, having WGS84 + ENU become WGS84 -> ECEF + ENU -> WGS84 is hiding quite a lot. If I were to update the library now I would have From / Into between WGS84 and ECEF, but not WGS84 + ENU. Then the user would have to explicitly do WGS84.into() + ENU. That was more of a random rambling than pertaining to your initial question.

[feuerste]

@nordmoen @kjetilkjeka I just stumbled upon the same bug when using ENU to compute ECEF offsets and fixed it by using the transposed rotation matrix computed in https://github.com/nordmoen/nav-types/blob/master/src/ecef.rs#L43, because we want to go from ENU to ECEF, not the other way around. I just wanted to prepare a PR for this fix.
However, I saw that @kjetilkjeka's fork https://github.com/kjetilkjeka/nav-types already contains these fixes. Can we try to get these changes into the master here? Alternatively, @nordmoen, if you don't want to maintain this lib any more, what do you think about giving @kjetilkjeka or myself push access, so I can fix it?
Thanks a lot for your help and considerations!

[nordmoen]

@feuerste Currently I have very little time to maintain this library (which is extremely outdated!). I will gladly give either or both of you access to the crates.io package so that you can do what you want with it. I think that is better than you guys taking over this repository (or is there a good reason for you to take over this repository?)

[feuerste]

@nordmoen Thanks for your quick reply! Getting access to crates.io would be great. I however think that also having us as collaborators with push access to this github repo would be great, so we could at least fix this bug, so no other people run into the same problems again.

[nordmoen]

@feuerste Ok then, I will give you both write access to this repository.

[feuerste]

@nordmoen Thanks for all your help. I just updated everything and wanted to publish to crates.io. Can you please also add me as owner there by

cargo owner --add feuerste

Thank you!

[nordmoen]

@feuerste Done

[feuerste]

Great, thanks, just published v0.4.0, which should fix the conversion inconsistencies.