Skip to content

Fix -Ra rounding a log10 axis bound to zero or negative - #9166

Open
Esteban82 wants to merge 1 commit into
masterfrom
fix-6614
Open

Fix -Ra rounding a log10 axis bound to zero or negative#9166
Esteban82 wants to merge 1 commit into
masterfrom
fix-6614

Conversation

@Esteban82

Copy link
Copy Markdown
Member

The following script fails because -Ra rounds an axis bound to (or past) zero, which is invalid on a logarithmic axis:

gmt math -T0/10240/1 T 10240 DIV 360 MUL 400 MUL COSD = t.txt
gmt spectrum1d t.txt -S256 -W --GMT_FFT=brenner -N -i1 > pow5.txt

gmt begin test png
	gmt plot pow5.txt -Wgreen -Ra -JX-15cl/4cl -Bxa2 -Bya2
gmt end
plot [ERROR]: Option -JX|x:  Limits must be positive for log10 option
plot [ERROR]: General map projection error

This PR fix this and a figure is created.

Assisted-by Claude Opus 5 (Medium effort)

Fixes #6614.

@Esteban82
Esteban82 requested review from joa-quim and seisman August 29, 2026 02:22
@Esteban82 Esteban82 added enhancement Improving an existing feature add-changelog Add PR to the changelog AI-assisted All (or most) of the code was written by Artificial Intelligence. labels Aug 29, 2026
With a logarithmic x- or y-axis (e.g. -JX-15cl/4c), the modern-mode -Ra
shorthand rounded the data-derived region with the same linear "nearest
fifth of a decade" logic used for Cartesian axes, so the lower bound
could land on 0 or below -- invalid on a log10 axis. The issue's example
gave -R0/260/-2/86 for data spanning x = 2 to 256.

gmtinit_get_region_from_data now checks whether -Jx|X requests a log10
x- and/or y-axis and, if so, expands that side out to the enclosing
powers of ten. The check reads the raw -J string rather than calling
gmtinit_parse_J_option: -J is not parsed for real until much later, and
parsing it here would reset the column types just determined from the
data and emit "? not a valid number" warnings for the unresolved
?-widths that subplot and inset panels legitimately still carry.

Also fixes the rounding loop's item index, which only advanced inside
the per-side branch and so was left stale by a skipped (already-rounded)
side, making the remaining side write over the other side's bounds. This
is what left the region above at 0/260 rather than 1/260, and it is a
pre-existing bug for geographic data too: -R1/358/-55/58 rounded to
0/360/-55/58, silently dropping the latitude rounding. Only reachable
when exactly one side is pre-set, so gmt_round_wesn's other caller
(pscoupe, which passes geo = false) is unaffected.

gmt_round_wesn keeps its signature and behavior as a thin wrapper.

Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

add-changelog Add PR to the changelog AI-assisted All (or most) of the code was written by Artificial Intelligence. enhancement Improving an existing feature

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Let -Ra works for log graph.

1 participant