Skip to content

fix: normalize vreckon output longitude to [-180, 180] range#108

Open
gaoflow wants to merge 1 commit into
geospace-code:mainfrom
gaoflow:fix/vreckon-negative-longitude
Open

fix: normalize vreckon output longitude to [-180, 180] range#108
gaoflow wants to merge 1 commit into
geospace-code:mainfrom
gaoflow:fix/vreckon-negative-longitude

Conversation

@gaoflow

@gaoflow gaoflow commented Jun 25, 2026

Copy link
Copy Markdown

Summary

Fixes #88.

vreckon() wrapped the computed destination longitude with lon2 %= tau, producing values in [0, 360). Any starting longitude west of the prime meridian therefore returned a wrong result — e.g. the example in #88:

>>> pymap3d.vincenty.vreckon(52.2261, -1.2697, 839.63, 63.02)
(52.22952..., 358.7413...)  # lon should be near -1.26°, not 358.74°

The comment added by Joaquim Luis already stated: "lon2 is always converted to the [-180 180] interval" — the implementation simply didn't match that intent.

Fix

One-line change in vincenty.py:

# before
lon2 %= tau                          # [0, 360)
# after
lon2 = (lon2 + pi) % tau - pi       # [-180, 180)

Four existing test expectations that encoded the old [0, 360) behaviour are updated (e.g. west-quadrant output 270°-90°), and a regression test for the exact case in #88 is added.

All 396 tests pass (9 skipped for missing optional deps).

Test plan

  • pytest src/pymap3d/tests/test_vincenty_vreckon.py — 17/17 pass (incl. new regression)
  • pytest src/pymap3d/tests/test_vincenty_dist.py — 16/16 pass
  • Full suite (pytest src/pymap3d/tests/ -q) — 396 passed, 9 skipped

This pull request was prepared with the assistance of AI, under my direction and review.

vreckon() was wrapping lon2 with `% tau`, producing values in [0, 360).
This caused wrong results for any starting longitude west of the prime
meridian: e.g., lon1=-1.27° yielded lon2=358.74° instead of ~-1.26°.

The docstring (added by Joaquim Luis) already stated lon2 should be in
[-180, 180].  Fix by changing the normalization to
`(lon2 + pi) % tau - pi`, which maps [0, 360) correctly to [-180, 180).
Update four test expectations that encoded the old [0, 360) convention,
and add a regression test for issue geospace-code#88.

Fixes geospace-code#88
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

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

1 participant