mil_os / lee_os / gs48: `P->es = 0` without `P->e = 0` projects such that the center does not map to the origin on the default ellipsoid

Open
  • Is something wrong?
#4,932 1 comment 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

@manduinca is already working on this.

Since Nov 5, 2026.

  • #4941 by @manduinca — open

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
48/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
cpp
Domain
backend

Research direction

Start with the mil_os, lee_os, and gs48 projection definitions in src/projections/mod_ster.cpp, then read the shared setup and forward/inverse routines cited in the issue. Reproduce the reported center coordinates with the default ellipsoid and with +R=. Done means the centers map to the origin and results no longer depend on +ellps, with the projection behavior and documentation consistent with the intended spherical form.

Written by the indexing model from the issue text.

Description

bug
AI usage
  • Fable 5.1 supported the creation of this ticket.
  • This ticket has been (mostly) written by myself (human), and is aimed at being read by humans.
Example of problem

The table shows the deviation from expected, in meters.

Miller oblated stereographic, fixed center lon_0 = 20 E, lat_0 = 18 N
+proj=mil_os                        fwd (20 E, 18 N) =          0.000     -11607.296
+proj=mil_os +ellps=WGS84           fwd (20 E, 18 N) =          0.000     -11607.296
+proj=mil_os +ellps=clrk66          fwd (20 E, 18 N) =          0.000     -11736.282
+proj=mil_os +R=6378137             fwd (20 E, 18 N) =          0.000         -0.000
+proj=mil_os +a=6378137 +b=6378137  fwd (20 E, 18 N) =          0.000         -0.000

+proj=mil_os                        fwd (100 W, 35 S) = -19233374.228  -18150580.102
+proj=mil_os +R=6378137             fwd (100 W, 35 S) = -19110058.965  -18219883.135     (141 km apart)
+proj=mil_os                        fwd (10 E, 50 N)  =    -703233.038    3376463.037
+proj=mil_os +R=6378137             fwd (10 E, 50 N)  =    -700940.072    3397111.428

Lee oblated stereographic, center 165 W 10 S
+proj=lee_os                        fwd (165 W, 10 S) =         -0.000       5267.742
+proj=lee_os +R=6378137             fwd (165 W, 10 S) =          0.000         -0.000

GS48, center 96 W 39 N
+proj=gs48                          fwd (96 W, 39 N)  =          0.000     -20670.771
+proj=gs48 +R=6370997               fwd (96 W, 39 N)  =          0.000         -0.000

Contrasting, this is alsk and gs50, which set e and es together, showing that they map their centers to the origin:

+proj=alsk                          fwd (152 W, 64 N) =          0.000         -0.000
+proj=gs50                          fwd (120 W, 45 N) =          0.000          0.000
Problem description

PJ_PROJECTION(mil_os), lee_os and gs48 (src/projections/mod_ster.cpp lines 145, 165, 185) set P->es = 0. to
make the projection spherical, but P->e keeps the value the ellipsoid setup gave it (=GRS80 by default). The shared
forward and inverse (mod_ster_e_forward line 33, mod_ster_e_inverse line 93) compute the conformal latitude of
every point with P->e, while mod_ster_setup (lines 116-122) sees P->es == 0 and takes the center's latitude
geodetically. The result is a hybrid: points are placed at their conformal latitude relative to a center that was not
converted. With the default ellipsoid the fixed projection center does not project to (0, 0), and the map depends on
+ellps although the projection declares itself spherical.

Expected Output

Either the spherical projection the P->es = 0. assignment intends (the center at the origin, the map independent of
+ellps, as +R= gives), or a consistent ellipsoidal form in which the center is converted too. The coefficient sets
PROJ carries for mil_os, lee_os and gs48 are single, spherical sets, whereas alsk and gs50 carry a spherical and a Clarke 1866 set and select by P->es. I think this means that the spherical reading is what the code's own data supports. The P->es = 0. implies it is what was intended.

Proposed fix

In PJ_PROJECTION(mil_os), lee_os and gs48:

    P->es = 0.;
    P->e = 0.;

(or call pj_calc_ellipsoid_params(P, P->a, 0.), which also refreshes P->one_es, P->rone_es and P->b). The
documentation of the three ("Available forms: Forward and inverse, spherical and ellipsoidal", +ellps defaulting to
GRS80) should then say spherical, as it does for the other fixed-sphere projections. If instead a true ellipsoidal form
is wanted, drop the P->es = 0. so mod_ster_setup converts the center as well; but the published coefficients were
fitted on the sphere.

Note: gs48 also reassigns P->a (line 186), which has a second, independent effect on the inverse; see the separate
report on the stale P->ra.

Environment Information
  • PROJ version (proj): 9.7.0
  • Operation System Information: MacOS Sequoia 15.7.7
Installation method
  • From C source
Dominant language
C++
Stars
2k
Forks
918
Avg merge
1d 11h
Merged PRs (30d)
20

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from OSGeo/PROJ

All issues in OSGeo/PROJ

Similar issues

More C++ issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.