Discussion about axes defaults

[adigitoleo]

Follow up from #665 , hopefully this can be a bit more organised :)

First: thanks for this package! I'm moving as much of my data processing to Julia as possible, and it's so convenient to make nice maps from the Julia shell.

---

The default behaviour of axes seems to depend on the frame option. Example:

julia> basemap(region = (-90, -70, 0, 20), Vd = 2)
	psbasemap  -R-90/-70/0/20 -JX14c/0 -Baf -BWSen -P -K > /tmp/GMTjl_tmp.ps

julia> basemap(region = (-90, -70, 0, 20), frame = (annot = :auto, ticks = :auto), Vd = 2)
	psbasemap  -R-90/-70/0/20 -JX14c/0 -Bpaf -P -K > /tmp/GMTjl_tmp.ps

In the second case, there is no -BWSen so now all axes are annotated. With the introduction of #666 and similar aliases, we would already have e.g. frame = :full for doing that. So maybe frame = (kwargs...) where kwargs does not contain axes should also produce the -BWSen behaviour?

[joa-quim]

This is on purpose but can be changed if I manage to make it sane.

• First case has no -B settings so it just use the default (-Baf -BWSen)
• Second case is where all hell break loose. GMT divides -B in -Baxes and -Bframe and while -Baxes may further be broken in pieces -Bframe must be built in a single chunk. So it's very difficult to append to a previous -Bframe (the default with no themes is -BWSen). So I defensively imposed that if one starts to set a frame() all settings must be done there. Note that one can also call xaxis, yaxis, zaxis and the undocumented grid option. You may look at the parse_B() and companion functions in common_options.jl to see how complex the parsing already is.

But I do agree with you that it would be nice to have a kind off appending mechanism. It's just that it's damn complicated. For example I currently have it to do

GMT.parse_B(Dict(:frame => (axes=(:left_full, :bottom_full, :right_full, :top_full), annot=10)), "")[1]
" -Bf -Bg -Bpa10 -BWSEN"

Question, should -Bf be inherited from the default or dropped because user only set the -Ba? It probably has do be dropped otherwise user would have to be forced to say noticks (an non existent option by now) when no ticks are desired. And that -Bg is clearly a bug since the default has no g.

[joa-quim]

I have made a commit where the following policy should prevail. When using the the frame=(..., ..., ...,) form the arguments of frame() can modify the axes and the frame parts of the -B option. Note, this axes and frame notion is that of GMT as explained (in). Now:

1. if only the axes part is modified, we keep the frame part of the default (normally, -BWSne, IF a theme is not in action)
2. if it only modify the frame part we keep the default axes, which normally is -Baf but can be something else when a theme was used.
3. modifying both axes and frame drops the default entirely.

Now, there are other ways of calling the parse_B() option, namely by using xaxis, yaxis, xlabel, title, passing a string, etc. So can't guarantee this works all the time.

Please give it some stress tests.

[adigitoleo]

Thanks, I'll check it out soon. You're right it's more complicated than I anticipated, and it's not a critical priority but thanks for looking into this.

[adigitoleo]

I have changed my feelings about some of this: I don't really like frame = :auto or axes = :auto or frame = (; axes = :auto), etc. Once we have some defaults (if there is no theme), they should just be applied silently.

Examples:

julia> basemap(region = :g, Vd = 2)
"psbasemap  -Rg -JX14c/0 -Baf -BWSen -P -K > /tmp/GMTjl_tmp.ps"

julia> basemap(region = :g, frame = :auto, Vd = 2)
"psbasemap  -Rg -JX14c/0 -Baf -BWSen -P -K > /tmp/GMTjl_tmp.ps"

julia> basemap(region = :g, frame = (; axes = :auto), Vd = 2)
"psbasemap  -Rg -JX14c/0 -Baf -BWSen -P -K > /tmp/GMTjl_tmp.ps"

julia> basemap(region = :g, axes = :auto, Vd = 2)
"psbasemap  -Rg -JX14c/0 -Baf -BWSen -P -K > /tmp/GMTjl_tmp.ps"

It would be nice if we could eliminate all of these except the first option. However, it will come with some compromises. Some ideas for GMT -B:

• For users familiar with the GMT syntax, we provide a B option which accepts only a String, where all of the frame and axes settings must be given in one string. There is no appending mechanism when using this syntax.
• For the verbose syntax, we split it up into two arguments, frame and axes, which accept only a Union{NamedTuple,Symbol}.
• All of the frame settings must be specified inside frame = (; ...), and all of the axes settings inside axes = (; ...).
• In the frame NamedTuple, the user may specify the draw field, which we currently call axes. I suggest this different name to avoid confusion with the axes part of the B options. The title must also be set inside frame.
• In the axes NamedTuple, the user may specify e.g. xaxis or yaxis2 for more fine-grained control. Here the options like xlabel and annot are also set.

What it might look like:

basemap(region = :g, Vd = 2)
# "psbasemap  -Rg -JX14c/0 -Baf -BWSen -P -K > /tmp/GMTjl_tmp.ps"

basemap(region = :g, frame = :auto, Vd = 2)
# Erorr, frame must be one of :full, :WSen, ...

basemap(region = :g, frame = :full, axes = (; annot = false), Vd = 2)
# "psbasemap  -Rg -JX14c/0 -Bpa0 -BWSEN -P -K > /tmp/GMTjl_tmp.ps"
# Current syntax: basemap(region = :g, frame = (; axes = :full, annot = false), Vd = 2)

# This one could be controversial
basemap(region = :g, title = "My Title")
# Error, title is not a valid keyword arg

basemap(region = :g, frame = (; title = "My Title"))
# Note that this already works

basemap(region = :g, frame = (; draw = :full, title = "My Title"))
# Instead of basemap(region = :g, frame = (; axes = :full, title = "My Title"))
# to avoid confusion with the actual "axes settings" in axes = (; ... )

Some of the confusion for me came from the fact that GMT splits -B options into "frame settings" and "axes settings", but the first "frame setting" is -Baxes 😄 To simplify the parser and make cross-referencing GMT docs easier, I think it would be best to split up the two kinds of B-options here as well. And renaming the option for "which of the axes should be drawn" from axes -> draw seems like a reasonabe compromise, what do you think?