Skip to content

Fix thin polar sectors that end up parallel to an axis (#7059) - #9170

Open
joa-quim wants to merge 1 commit into
masterfrom
fix-7059
Open

Fix thin polar sectors that end up parallel to an axis (#7059)#9170
joa-quim wants to merge 1 commit into
masterfrom
fix-7059

Conversation

@joa-quim

Copy link
Copy Markdown
Member

A single polar axis is a sector so thin that its bounding box has a width but no height. Rotating it by 90 degrees swaps the two and broke both the scale and the annotations:

  • gmtmap_setinfo matched -JP to the map width, which for a sector standing on end is nothing but round-off, so -JP12c+t90 produced a plot 12 x 3437746 cm. It now checks the dimension it was asked to match and falls back to the other one when the first is under 0.01 % of it, with a warning (and a pointer to -Jp for polar plots). A fully degenerate map no longer divides by zero.
  • n_lon_nodes/n_lat_nodes are derived from the map dimensions and rounded down to zero for a map with no width, so the boundary-walking loops in gmtlib_map_latcross/gmtlib_map_loncross never ran and no ticks or annotations were placed. The three places that derive them now floor them at 2.

Adds test/psbasemap/polar_thin_sector.sh and documents the meaning of the -JP size for sectors, plus the -Jp recipe for radar plots.

Fix #7059

Supersedes #9131

Assisted-by: GPT Terra + Claude Opus 5.0

A single polar axis is a sector so thin that its bounding box has a width
but no height.  Rotating it by 90 degrees swaps the two and broke both the
scale and the annotations:

* gmtmap_setinfo matched -JP<size> to the map width, which for a sector
  standing on end is nothing but round-off, so -JP12c+t90 produced a plot
  12 x 3437746 cm.  It now checks the dimension it was asked to match and
  falls back to the other one when the first is under 0.01 % of it, with a
  warning (and a pointer to -Jp<scale> for polar plots).  A fully degenerate
  map no longer divides by zero.
* n_lon_nodes/n_lat_nodes are derived from the map dimensions and rounded
  down to zero for a map with no width, so the boundary-walking loops in
  gmtlib_map_latcross/gmtlib_map_loncross never ran and no ticks or
  annotations were placed.  The three places that derive them now floor
  them at 2.

Adds test/psbasemap/polar_thin_sector.sh and documents the meaning of the
-JP size for sectors, plus the -Jp recipe for radar plots.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01TZPAjvoG9oCgbMMbenuV8c
@joa-quim joa-quim added the AI-assisted All (or most) of the code was written by Artificial Intelligence. label Aug 30, 2026
@joa-quim
joa-quim requested a review from a team August 30, 2026 16:58
@joa-quim joa-quim added the add-changelog Add PR to the changelog label Aug 30, 2026
@Esteban82

Copy link
Copy Markdown
Member

I tested it and the test works fine.

But I run the command of #7059 and I got this figure

lixo

I suspect that the origin of the second axis should be at 0.0.

@joa-quim

Copy link
Copy Markdown
Member Author

Damn it (thanks for testing).

@Esteban82

Copy link
Copy Markdown
Member

I tested further. With -45 works fine:

gmt begin radar png
	gmt basemap -R-0.0001/0.0001/0/1 -Jp12c -Bya
	gmt basemap -Jp12c+t-45 -Bya
	gmt basemap -Jp12c+t-90 -Bya
gmt end
radar

But fails with +t45.
radar

gmt begin radar png
	gmt basemap -R-0.0001/0.0001/0/1 -Jp12c -Bya
	gmt basemap -Jp12c+t45 -Bya
	gmt basemap -Jp12c+t-90 -Bya
gmt end

@joa-quim

Copy link
Copy Markdown
Member Author

It smells like the thing has tailored the code to comply with the example given and not with a general solution.

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.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Multiple -JP plots start at end of previous plot (well, sort off)

2 participants