[choupeanut]

Summary

World::forward and World::inverse now return None when the sphere radius is zero, negative, NaN or infinite. Previously a zero radius could collapse a forward projection onto its false origin, a negative radius could mirror coordinates, and an infinite radius could turn a finite inverse input into an apparently valid centre point.

Both directions validate the radius before projection arithmetic. The method documentation states that the radius must be finite and positive. Valid projection formulas and the public API signatures are unchanged.

This addresses only the World sphere-radius validation finding in #2008, section 4. The Aeqd and UTF-8 label-length findings in that bullet remain open, as does the rest of the audit. No dependencies or data-model changes; no other project's code was followed or copied.

Testing

• cargo test -p rustgis-geom world::tests: 5 passed.
• The new regression checks forward and inverse conversion for all five projections (Robinson, Equal Earth, Natural Earth, Winkel Tripel and Eckert IV) with +0, -0, negative, NaN and infinite radii, both at the origin and away from it.
• Positive unit-sphere and Earth-size radii still round-trip with nonzero central meridians and false easting/northing. Existing numerical reference and outline tests also passed.
• cargo xtask ci: passed (fmt, Clippy with -D warnings, workspace tests: 6,461 passed / 23 ignored, layers).
• pre-commit run --all-files: all hooks passed.
• cargo check --locked --target wasm32-unknown-unknown -p rustgis-geom: passed.

UI evidence

No visible UI change.

Related issue

Part of #2008 (section 4: World radius validation). Does not close the tracking issue.

Summary by CodeRabbit

• Bug Fixes
  • World projections now return no result when the radius is zero, negative, or non-finite.

[coderabbitai]

No actionable comments were generated in the recent review.

Walkthrough

World::forward and World::inverse now return None when the world radius is non-finite or not positive. Tests cover invalid radii across all five projection kinds and round trips with valid radii and offsets.

Changes: World projection validation

Layer / File(s)	Summary
Radius validation and projection tests crates/geom/src/world.rs	World::forward and World::inverse reject non-finite or non-positive radii. Tests cover invalid radii across all five projection kinds and valid round trips with offsets.

Estimated code review effort: 2 (Simple) | ~10 minutes

Change: Bug fix

Suggested reviewers: bearinmindcat

Merge Risk: Minimal · up to 6ba25

World projections now return no result for zero, negative, NaN, or infinite sphere radii instead of computing with them. Valid radii behave as before. No merge-blocking risk was identified.

Pre-merge checks: 4

Check name	Status	Explanation
Title check		The title "fix(geom): reject invalid world projection radii" matches the main change. World::forward and World::inverse now return None for zero, negative, NaN, or infinite radii, and the title names …
Description check		The description follows the repository template. It has Summary, Testing, UI evidence, and Related issue sections. The UI evidence section states "No visible UI change.", which the template allows whe…
Linked Issues check		Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check		Check skipped because no linked issues were found for this pull request.

Full details: Title check

Explanation

The title "fix(geom): reject invalid world projection radii" matches the main change. World::forward and World::inverse now return None for zero, negative, NaN, or infinite radii, and the title names the component (geom) and the fix type. It is short, specific, and does not list files.

Full details: Description check

Explanation

The description follows the repository template. It has Summary, Testing, UI evidence, and Related issue sections. The UI evidence section states "No visible UI change.", which the template allows when no visible UI changes. The Testing section lists specific commands and results. The Related issue section links Part of #2008 and states that it does not close the tracking issue. The Summary explains the change and its reasons clearly.

Finishing Touches

Generate unit tests (beta)

• Create a new PR

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

Share

• X
• Mastodon
• Reddit
• LinkedIn

_{A rabbit checks the radius round,
No zero or strange value gets through.
Five projection kinds are tested,
Valid paths return, as they should.
Then off through fields, I hop anew.}

Recent review info

Run configuration

• Source mode: Auto
• Repository: Unavailable
• Branch: Unavailable
• File: No configuration file from this repository applied
• Commit: Unavailable
• Layers: Organization UI
• Review profile: ASSERTIVE
• Plan: Advanced
• Run ID: 03671f32-6a1b-42ca-a660-754793077356

Commits

Reviewing files that changed from the base of the PR and between 3da536e and 6ba2530.

Files selected for processing: 1

• crates/geom/src/world.rs

Included review availability: This review used your included allowance. Your plan provides up to 8 included reviews per hour; 6 remain after this review.

[github-actions]

Code review

Reviewed crates/geom/src/world.rs (+26/−2) against the base branch, with the two callers that build a World from file or definition input (crates/data/src/raster/crs.rs:675, crates/map/src/projection.rs:619). I found no bugs or security issues, so I posted no inline comments.

Bugs: None found. Checked:

• -0.0, negative, NaN and ±infinite radii all hit radius <= 0.0 or !is_finite() and return None in both directions.
• The valid-radius path is unchanged, and the new test round-trips it with offsets for both a unit sphere and MERCATOR_R.
• Both real callers already reject non-positive or non-finite radii (crs.rs checks a > 0.0 && a.is_finite(), projection.rs filters +R), so the guard is defence in depth and does not change current behaviour. Confidence: high.

Security: None. The change is pure f64 arithmetic with no new input paths.

Performance: None meaningful. Each forward/inverse call gains three comparisons, which is negligible next to the projection math.

Quality (nit, low priority): The radius guard is copied verbatim into forward and inverse. A small private helper such as fn has_radius(&self) -> bool would keep the two in step. This is a style point, not a defect.

AGENTS.md: Compliant on what I could check by reading. No unwrap/expect/panic is added outside tests, there is no unsafe, no new dependency, and the code is wasm-safe. The change is a crash-path guard with a regression test, as the rules require. The PR body's testing claims (cargo xtask ci, wasm check) are not verifiable from the staged files, and I did not re-run them.

Prior concerns: 0 earlier review threads exist on this PR, so none were left alone.

Change size

Compared: the whole PR against main (merge base 3da536e to PR head 6ba2530).

Measure	Value
Files changed	1 (added 0, modified 1, removed 0, renamed 0)
Size before	21.4 KB (21,956 B)
Size after	22.8 KB (23,389 B)
Total size change	+1.4 KB (+1,433 B)

Path	Before	After	Change
crates/geom/src/world.rs	21.4 KB	22.8 KB	+1.4 KB

[github-actions]

📖 Docs preview

Item	Value
Preview	https://preview.rustgis.app/pr-2038/
Web app	https://preview.rustgis.app/pr-2038/app/
Commit	6ba2530

GitHub Pages takes a minute or two to publish a new commit.