Skip to content

Resolve spherical radius from CRS datum - #19

Open
asinghvi17 wants to merge 2 commits into
spherical/nearest-pointsfrom
spherical/datum
Open

asinghvi17 wants to merge 2 commits into
spherical/nearest-pointsfrom
spherical/datum

Conversation

@asinghvi17

@asinghvi17 asinghvi17 commented Sep 20, 2026

Copy link
Copy Markdown
Member

Spherical table metadata previously preserved only GeometryOps' default radius. This adds an optional Proj extension that derives the radius from the supplied geographic CRS: a declared sphere retains its radius, and an ellipsoid uses (2a+b)/3.

GeoParquet edges still selects planar or spherical interpretation. The existing GEOINTERFACE:crs value carries the datum unchanged; no new radius metadata or replacement CRS is introduced. Export and setcrs validate radius agreement and reject projected CRS. Without a CRS, only the default spherical radius can round-trip.

This builds on the spherical lookup and nearest-point PRs in the GitHub stack. Reprojection and cross-space raster operations remain outside this change.

Validation: datum tests (including a fresh process without Proj), spherical lookup tests (66 assertions), and spherical nearest tests (816 assertions) pass on the combined branch. The datum layer also passed the existing planar suite in its isolated worktree.

Geographic CRS checks and ellipsoid parsing live together in the Proj extension. The core uses the resulting radius for inference and checks radius agreement for explicit manifolds. The combined stack passes the full Julia 1.13 suite (2,470 assertions).

@asinghvi17
asinghvi17 added this pull request to stack #18 September 20, 2026 20:30

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.

1 participant