GenericMappingTools
Set a default position for colorbar, map scale and directional rose
Just a suggestion.
For the below features the users must indicated a position (refpoint) to plot them. Maybe we could define a default position for them. I include some suggestion.
- colorbar:
-DJMRfor vertical scale and-DJBCfor horizontal (which could be set with+h). - map scale:
-LjBR(I think we need a small offset). - north (directional rose):
-TdjTR.
For consistency, maybe we should define a default refpoint for magnetic rose, inset map and legend?
FYI, in #6215 there is a new GMT defaults called MAP_EMBELLISHMENT_MODE = manual|auto which is auto in modern mode by default (manual in classic). With auto we supply reasonable defaults for useful settings like the offset, size, and we can add location in there as well. I agree with your placements. There is also the vertical data range bar set in wiggle.
Because if we set it to auto in classic by default then lots of scripts will suddenly give very different results and hence would be a backwards break. With you mixing classic and modern in Julia I think you just have to add MAP_EMBELLISHMENT_MODE=auto somewhere if you want it the same across both modes.
Yes, I can see it would break compat in classic but why is not breaking compat in modern? And I'm not mixing classic and modern in Julia.
Pretty sure you have told me many times that GMT.jl uses both classic and modern. Perhaps mixing is not the right word.
My thinking is that we do not want to make major changes in classic. I am pretty sure most longtime GMT users are still using classic and this would be noticed. However, modern mode folks are fewer and more inclined to have GMT do work for them instead of the other way around. Yes, it will break a few scripts, perhaps, but the benefit of having well-thought-out defaults will outweigh those cases. The change fits in with modern mode design and thinking - unlike in classic.
Any thoughts on auto-map scale? Here is my draft plan (not implemented yet):
- Get the 10% map width in inches = L
- Get local scale at scale origin and convert L to spherical degrees = D
- Convert D to desired scale unit [km]
- Get x = floor (log10 (D))
- Change D = rint (D/x)*x for final scale length in desired units
Some examples for various D in km:
D = 57 -> 60 km
D = 132 -> 100 km
D = 169 -> 200 km
D = 388 -> 400 km
D = 3.4 -> 4 km
Julia makes classic looks much like modern in behavior but no (impossible to do) mix-match.
And although I have not experimented it, I still don't see why MAP_EMBELLISHMENT_MODE can not be made default for classic too. If we are talking about new defaults it means that before the users had to specify parameters that now have a default. So if users keep using older syntax the auto mode is not activated and no backward compat breaking would occur. But I'm probably missing something.
Well, this is a branch so we can discuss this. The idea was that in auto mode, you could leave some things off and have it set, but you could also set some things. E.g., -Td2c would override the default auto size of 10% but not change the auto offset of 10% of symbol size. The thing you imply is that -TdjTL might do auto but -TdjTL+w2c would no longer set +o automatically as we have now turned auto off by giving a size option. So we need to sort out how this all should work.
I guess my main concern has to do with the offset. It is by default zero in classic, which is probably what most people do not want (I assume we all want a nice little gap between the embellishment and the map border). This PR changes the default (for modern, as of now) to a small percentage of the size of the feature. This seems to work well and lets you specify the future without having to add +o0.1c etc. In modern mode I keep track of whether +o was used or not, so the user can override. It seems tricky to do this for classic since its default is zero, We could just declare that the offset default should not be zero for either classic and modern, and you would actually have to use +o0 to force it to have no gap. Then, classic would also get a nicer setup and all those existing scripts with +o will be honored.
I would prefer that. Having classic and modern behave the same way has the further advantage that MAP_EMBELLISHMENT_MODE would not be needed (and have too many conf variables)
The other thing that would be completed backwards incompatible are all the attributes related to, say, a map compass. In classic they are all set manually (e.g., MAP_TICK_LENGTH ...). In this PR, and for modern mode, I have this:
bool adjust = (GMT->current.setting.map_embellishment_mode); /* A bit shorter to use */
/* If modern mode we recompute ticklengths, label sizes, and text offsets relative to compass size */
tlen[0] = (adjust) ? TLEN_SCL0 * mr->size : GMT->current.setting.map_tick_length[GMT_TICK_UPPER];
tlen[1] = (adjust) ? TLEN_SCL1 * mr->size : GMT->current.setting.map_tick_length[GMT_ANNOT_UPPER];
tlen[2] = (adjust) ? TLEN_SCL2 * mr->size : 1.5 * GMT->current.setting.map_tick_length[GMT_ANNOT_UPPER];
off[0] = (adjust) ? OFF_SCL0 * mr->size : GMT->current.setting.map_annot_offset[0];
off[1] = (adjust) ? OFF_SCL1 * mr->size : GMT->current.setting.map_annot_offset[1];
font_size[0] = (adjust) ? FNT_SCL0 * mr->size * 72.0 : GMT->current.setting.font_annot[0].size;
font_size[1] = (adjust) ? FNT_SCL1 * mr->size * 72.0 : GMT->current.setting.font_annot[1].size;
title_size = (adjust) ? TITLE_SCL * mr->size * 72.0 : GMT->current.setting.font_title.size;
lbl_size = (adjust) ? LBL_SCL * mr->size * 72.0 : GMT->current.setting.font_label.size;
txt_offset = (adjust) ? TITLE_OFF * title_size / 72.0 : GMT->current.setting.map_title_offset;
This is like modern theme with auto-scaling of attributes based on map size, but here based on embellishment size. It makes it a lot easier for the user. When you use classic mode from Julia, are you not using the modern theme (which modern mode uses)? If you are then we could just stick MAP_EMBELLISHMENT_MODE as auto into that theme and we have a solution...
I have no problems in setting any gmt.conf var as default without having to save a gmtdefaults file. For example, the init() function does
gmtlib_setparameter(G_API[1], "COLOR_NAN", "255")
and also sets a theme. The thing is that I don't like to see a slow derivation from classic & modern.
If you can issue a MAP_EMBELLISHMENT_MODE auto call then I can save hours of messing with this trying to keep classic from deviating too much even though it is near impossible to do without backwards breakage. It seems I am more happy than you with letting classic receive mostly updates and new features but not changing existing syntax than you are.
Simplifying syntax of the embellishment elements is not even a breaking. I don't mind that
Any thoughts on auto-map scale? Here is my draft plan (not implemented yet):
1. Get the 10% map width in inches = L 2. Get local scale at scale origin and convert L to spherical degrees = D 3. Convert D to desired scale unit [km] 4. Get x = floor (log10 (D)) 5. Change D = rint (D/x)*x for final scale length in desired unitsSome examples for various D in km:
D = 57 -> 60 km D = 132 -> 100 km D = 169 -> 200 km D = 388 -> 400 km D = 3.4 -> 4 km
Sounds good. Altough I think I will have to test it to be sure.
I think it would be good because it would help new users (since it would simplify the code, for example they would only need to do basemap -L to get an scale without needing to read about refpoint).
And new users will be using the binary packages so it would be good to have these features for 6.5.