Allow for a fixed label offset #5320

PaulWessel · 2021-06-10T03:10:00Z

Description of proposed changes

See issue #5182 for background. This PR lets a negative MAP_LABEL_OFFSET be interpreted as the absolute distance from the axis to the base of the label [The default is that a positive offset is seen as a relative addition beyond the end of the annotations]. The use for this is to better align multiple y-axes plots that are stacked so that the labels align even if the annotations have different magnitudes and formats. TO demonstrate this effect I added a test based on the original poster's issue. This plot is found below this text. One remaining issue is whether of not we restrict this mechanism to just the y-axis. There are two different consequences depending on the answer:

If applicable to all axis then the user may need to use separate basemap calls so that the effect only applies to the label they want.
If only applicable to the y-axis then one cannot align x-labels on stacks of plots in several columns, and not just this example of one column.

For these reasons I favor not imposing any restriction on which axis it applies to. Also note: The offset is the exact absolute distance between axis and base of label . That means it is the same on both left and right axis, but since the base is on the right there is a difference. Another question is then if we need to ensure it works symmetrically on left and right, meaning on the right axis (and bottom) we must deal with the absolute distance to the top of the label.

Comments please.

Trying it out

seisman · 2021-06-10T03:23:01Z

This PR lets a negative MAP_LABEL_OFFSET be interpreted as the absolute distance from the axis to the base of the label

It's backward-incompatible, right?

PaulWessel · 2021-06-10T03:24:26Z

Do you mean we already are using a negative label offset for something else?

seisman · 2021-06-10T03:27:26Z

Do you mean we already are using a negative label offset for something else?

People may be using a negative label offset to make labels closer to the axis.

PaulWessel · 2021-06-10T03:36:48Z

OK, I can imagine people doing that. The alternative implementation would then be some sort of flag to interpret the offset the absolute way. MAP_LABEL_OFFSET=offset[unit][+a] with a modifier for absolute. Not sure if this is the first defaults setting with a modifier so perhaps that is a bad precedent. The final alternative is a separate and new defaults setting like MAP_LABEL_MODE=auto|absolute [auto].

And I guess it really should measure from the axis outward to the start of the label, be it to the base of the top of it, so that means working this into PostScript for exact height, etc.

maxrjones · 2021-06-10T18:44:16Z

OK, I can imagine people doing that. The alternative implementation would then be some sort of flag to interpret the offset the absolute way. MAP_LABEL_OFFSET=offset[unit][+a] with a modifier for absolute. Not sure if this is the first defaults setting with a modifier so perhaps that is a bad precedent. The final alternative is a separate and new defaults setting like MAP_LABEL_MODE=auto|absolute [auto].

And I guess it really should measure from the axis outward to the start of the label, be it to the base of the top of it, so that means working this into PostScript for exact height, etc.

Is it possible to make these both customizable for x and y axes independently? For example, --MAP_LABEL_OFFSET 12p/24p --MAP_LABEL_MODE annot/axis for 12p x-axis labels relative to the annotations and 24p y-axis labels relative to the axis.

Either way, I prefer MAP_LABEL_MODE to +a, but find annot/axis more descriptive than auto/absolute.

PaulWessel · 2021-06-12T18:45:12Z

I have introduced the new GMT defaults MAP_LABEL_MODE = annot|axis which can be set separately for the x and y axis via a slash. Similarly, the MAP_LABEL_OFFSET can now be given separate offsets for x and y if desired. With these upgrades we can offer support for having proper alignment of numerous y-axis labels without imposing the same condition on the x-axis. But we could, if we wish to align several sets of x labels across columns.
All tests still pass.

doc/rst/source/gmt.conf.rst

maxrjones · 2021-06-14T15:41:18Z

Do you think it is possible to update the auto settings for MAP_LABEL_OFFSET to work better when MAP_LABEL_MODE is set to axis?

gmt begin panels pdf
  gmt subplot begin 2x1 -Fs8c -M20p -A -SCb -SRl
    gmt set MAP_LABEL_MODE axis/axis MAP_LABEL_OFFSET auto/auto
    gmt subplot set
    gmt basemap -R0/8000/0/1000 -BWSne -Bya+l"Axis label"
    gmt subplot set
    gmt basemap -R0/80/0/10 -BWSne -Bya+l"Axis label"
  gmt subplot end
gmt end show

PaulWessel · 2021-06-14T20:38:21Z

We could, but no single value will work well I think. But I agree 8p is not it! Suggestions?

maxrjones · 2021-06-14T21:04:09Z

We could, but no single value will work well I think. But I agree 8p is not it! Suggestions?

32p seems OK. Maybe it would be worth adding a warning as well for MAP_LABEL_OFFSET=auto with MAP_LABEL_MODE=axis, like what is done if annotations are removed due to gmt.conf settings.

PaulWessel · 2021-06-14T21:07:51Z

Yes, that would be good. So 8p/32p for the two types of offsets plus warning for axis actions. Would you like to try this?
-p

maxrjones · 2021-06-14T21:10:11Z

Yes, that would be good. So 8p/32p for the two types of offsets plus warning for axis actions. Would you like to try this?
-p

Do you mean implementing the changes or testing? Fine doing either.

PaulWessel · 2021-06-14T21:11:27Z

Sorry, meant implementing etc. Includes doc update I think as well.

maxrjones · 2021-06-14T21:16:33Z

Sorry, meant implementing etc. Includes doc update I think as well.

Yes, will do.

src/gmt_init.c

Co-authored-by: Meghan Jones <meghanj@alum.mit.edu>

PaulWessel · 2021-06-16T00:51:28Z

Sorry, I completely forgot to access these suggestions...

maxrjones · 2021-06-16T02:09:04Z

OK, I seem to be having the subplot related problem again. Is something wrong in the second example here?
Example 1 (works as expected, with MAP_LABEL_OFFSET = 32p)

gmt begin panels pdf
  gmt set MAP_LABEL_MODE axis
  gmt subplot begin 2x2 -Fs8c -M25p
    gmt subplot set
    gmt basemap -By+ltest -Bx+ltest -R0/8000/0/1000
    gmt subplot set
    gmt basemap -By+ltest -Bx+ltest -R0/8000/0/1000
    gmt subplot set
    gmt basemap -By+ltest -Bx+ltest -R0/80/0/10
    gmt subplot set
    gmt basemap -By+ltest -Bx+ltest -R0/80/0/10
  gmt subplot end
gmt end show

Example 2 (MAP_LABEL_OFFSET still uses auto scaling):

gmt begin panels png
  gmt subplot begin 2x2 -Fs8c -M25p
    gmt set MAP_LABEL_MODE axis
    gmt subplot set
    gmt basemap -By+ltest -Bx+ltest -R0/8000/0/1000
    gmt subplot set
    gmt basemap -By+ltest -Bx+ltest -R0/8000/0/1000
    gmt subplot set
    gmt basemap -By+ltest -Bx+ltest -R0/80/0/10
    gmt subplot set
    gmt basemap -By+ltest -Bx+ltest -R0/80/0/10
  gmt subplot end
gmt end show

PaulWessel · 2021-06-16T02:25:28Z

I get the same, so looks like 6p is scaled to ~the same. It is clearly not scaling 32p to something. Not obvious anything in the code is wrong. May need to debug.
Oh, the issue is that you are setting the MAP_LABEL_MODE too late. subplot has already done the calculations and made a gmt.conf for the subplot based on the 6p then the mode changes...

maxrjones · 2021-06-16T02:29:06Z

src/gmt_init.c

-		GMT->current.setting.map_label_offset = 6 * pt * scale;	/* 6p */
+	if (gmt_M_is_dnan (GMT->current.setting.map_label_offset[GMT_X])) {
+		if (GMT->current.setting.map_label_mode[GMT_X] == GMT_LABEL_AXIS)
+			GMT->current.setting.map_label_offset[GMT_X] = 32 * pt;


Suggested change

GMT->current.setting.map_label_offset[GMT_X] = 32 * pt;

GMT->current.setting.map_label_offset[GMT_X] = 32 * pt * scale;

I set this as constant intentionally, but in retrospect scaled might be better.

Do you still want this suggestion to be active?

maxrjones · 2021-06-16T02:30:06Z

I get the same, so looks like 6p is scaled to ~the same. It is clearly not scaling 32p to something. Not obvious anything in the code is wrong. May need to debug.
Oh, the issue is that you are setting the MAP_LABEL_MODE too late. subplot has already done the calculations and made a gmt.conf for the subplot based on the 6p then the mode changes...

OK, so it should not be expected to work. Thanks for the explanation.

PaulWessel added 3 commits June 9, 2021 15:40

WIP Implement a fixed label offset mechanism

c44040c

Trying it out

Merge branch 'master' into fixed-label-offset

9e3dc79

Ad example and update docs

5c4e540

PaulWessel added new feature PR that implements a new feature or capability in GMT new core module feature PR that implements a new core module feature labels Jun 10, 2021

PaulWessel added this to the Future release milestone Jun 10, 2021

PaulWessel requested review from joa-quim, maxrjones and seisman June 10, 2021 03:10

PaulWessel self-assigned this Jun 10, 2021

Merge branch 'master' into fixed-label-offset

bc0f25c

vercel bot temporarily deployed to Preview June 12, 2021 02:37 Inactive

handle height of label on the right/bottom axes

a08f6c5

vercel bot temporarily deployed to Preview June 12, 2021 03:15 Inactive

maxrjones added the add-changelog Add PR to the changelog label Jun 12, 2021

Update map_label_offset to have separate x[/y] values

ae37d06

vercel bot temporarily deployed to Preview June 12, 2021 18:41 Inactive

Merge branch 'master' into fixed-label-offset

b2cdd07

vercel bot temporarily deployed to Preview June 12, 2021 18:49 Inactive

maxrjones reviewed Jun 14, 2021

View reviewed changes

doc/rst/source/gmt.conf.rst Outdated Show resolved Hide resolved

doc/rst/source/gmt.conf.rst Outdated Show resolved Hide resolved

Adjust MAP_LABEL_OFFSET auto default if MAP_LABEL_MODE is axis

65d1531

vercel bot temporarily deployed to Preview June 14, 2021 22:38 Inactive

Document new auto behavior for MAP_LABEL_OFFSET

3fe1993

maxrjones reviewed Jun 14, 2021

View reviewed changes

src/gmt_init.c Show resolved Hide resolved

maxrjones reviewed Jun 15, 2021

View reviewed changes

src/gmt_init.c Outdated Show resolved Hide resolved

Update doc/rst/source/gmt.conf.rst

6c05558

Co-authored-by: Meghan Jones <meghanj@alum.mit.edu>

vercel bot temporarily deployed to Preview June 16, 2021 00:50 Inactive

PaulWessel and others added 2 commits June 15, 2021 14:50

Update doc/rst/source/gmt.conf.rst

8197e23

Co-authored-by: Meghan Jones <meghanj@alum.mit.edu>

Update src/gmt_init.c

0c28513

Co-authored-by: Meghan Jones <meghanj@alum.mit.edu>

vercel bot temporarily deployed to Preview June 16, 2021 00:55 Inactive

maxrjones reviewed Jun 16, 2021

View reviewed changes

maxrjones approved these changes Jun 16, 2021

View reviewed changes

PaulWessel changed the title ~~WIP Allow for a fixed label offset~~ Allow for a fixed label offset Jun 16, 2021

PaulWessel merged commit 67471c1 into master Jun 16, 2021

PaulWessel deleted the fixed-label-offset branch June 16, 2021 02:40

PaulWessel mentioned this pull request Jun 19, 2021

Option to set MAP_LABEL_OFFSET to be relative to axis #5182

Closed

seisman removed this from the Future release milestone Jan 7, 2024

	GMT->current.setting.map_label_offset[GMT_X] = 32 * pt;
	GMT->current.setting.map_label_offset[GMT_X] = 32 * pt * scale;

Allow for a fixed label offset #5320

Allow for a fixed label offset #5320

Conversation

PaulWessel commented Jun 10, 2021

Uh oh!

seisman commented Jun 10, 2021

Uh oh!

PaulWessel commented Jun 10, 2021

Uh oh!

seisman commented Jun 10, 2021

Uh oh!

PaulWessel commented Jun 10, 2021

Uh oh!

maxrjones commented Jun 10, 2021

Uh oh!

PaulWessel commented Jun 12, 2021

Uh oh!

Uh oh!

Uh oh!

maxrjones commented Jun 14, 2021

Uh oh!

PaulWessel commented Jun 14, 2021

Uh oh!

maxrjones commented Jun 14, 2021

Uh oh!

PaulWessel commented Jun 14, 2021

Uh oh!

maxrjones commented Jun 14, 2021

Uh oh!

PaulWessel commented Jun 14, 2021

Uh oh!

maxrjones commented Jun 14, 2021

Uh oh!

Uh oh!

Uh oh!

PaulWessel commented Jun 16, 2021

Uh oh!

maxrjones commented Jun 16, 2021

Uh oh!

PaulWessel commented Jun 16, 2021

Uh oh!

maxrjones Jun 16, 2021

Choose a reason for hiding this comment

Uh oh!

PaulWessel Jun 16, 2021

Choose a reason for hiding this comment

Uh oh!

maxrjones commented Jun 16, 2021

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants