Skip to content

C API: add proj_ellipsoid_from_proj_string() - #4925

Open
HugoFara wants to merge 1 commit into
OSGeo:masterfrom
HugoFara:ellipsoid-from-proj-string
Open

HugoFara wants to merge 1 commit into
OSGeo:masterfrom
HugoFara:ellipsoid-from-proj-string

Conversation

@HugoFara

Copy link
Copy Markdown

There is no public way to get the ellipsoid that a PROJ string like +ellps=WGS84 +R_A describes: proj_create() + proj_get_ellipsoid() drops the +R_* keys, and pj_ell_set() is internal. pyproj needs this for Geod (pyproj4/pyproj#1157).

This adds proj_ellipsoid_from_proj_string(ctx, definition, &a, &es), a thin wrapper around pj_ell_set(), with the shape agreed in #4864 with @jjimenezshaw: it returns (a, es) and ignores unrelated keys.

One open question: +R_C is evaluated at latitude 0 regardless of +lat_0, as proj_create() does today (init.cpp calls pj_ellipsoid() before reading phi0, and builtins.gie relies on it). The docs for +R_C say "at φ0". I kept the current behaviour and pinned it in the test, so if the docs are right, fixing init.cpp would fix both.

Resolve the ellipsoid described by a PROJ string into (a, es), honouring
the spherification parameters (+R_A, +R_lat_a, ...) that proj_create()
followed by proj_get_ellipsoid() drops. It wraps pj_ell_set(), so the
result is the ellipsoid the geod utility uses. Unrelated keys are
ignored, and +R_C is evaluated at latitude 0 as in proj_create().

Closes OSGeo#4864

Assisted-by: Claude Opus 5.5
@HugoFara
HugoFara marked this pull request as ready for review October 30, 2026 11:08

This branch has not been deployed

No deployments
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.

Public C API to resolve ellipsoid parameters from a PROJ string (incl. +R_A, +R_lat_a…)

1 participant