[Bug]: vincenty.vreckon returns incorrect answer if longitude is negative.

[BleedObsidian]

What happened?

Consider the following example:

Assuming I'm starting at the point at the bottom left, I want to work out the point in the top right knowing the distance travelled and the azimuth.

To do, I use the following code:

import pymap3d.vincenty

lat2, lon2 = pymap3d.vincenty.vreckon(52.22610277777778, -1.2696583333333333, 839.63, 63.02)
print(lat2, lon2)

The above code returns:

52.22952562862266 358.7412927899441

Note the latitude is correct but the longitude is totally invalid. This appears to be caused by using negative longitudes. Negative latitudes seem to be correctly handled.

Relevant log output

No response

[scivision]

Thanks, I see this bug is also present in Matmap3d, which vreckon is Pymap3d is based off of.

I tested with https://github.com/geospace-code/pymap3d/blob/main/src/pymap3d/tests/test_matlab_vreckon.py
from the pymap3d/ directory

pytest -k matlab

[scivision]

This bug is in the Kleder 2007 Matlab code I used straight from https://www.mathworks.com/matlabcentral/fileexchange/17493-vreckon-find-the-endpoint-of-a-geodesic-on-the-ellipsoidal-earth as well, which I based PyMap3d vreckon on

[scivision]

This is a little trickier than just removing the "mod % 360" as it affects several other corner cases.

[BleedObsidian]

The temporary fix I applied at the time was:

import pymap3d.vincenty

lat2, lon2 = pymap3d.vincenty.vreckon(52.22610277777778, -1.2696583333333333, 839.63, 63.02)

if lon2 > 180:
    lon2 -= 360

But It feels dirty and I haven't unit tested it against all the other corner cases. It's effectively only undoing the mod % 360 if the longitude is clearly invalid.