-
Notifications
You must be signed in to change notification settings - Fork 367
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Consistency on placement of gridlines and basemaps #4265
Comments
One thought: It may be that there is no single system that always will work and users may have to add extra commands, which is tedious. How about we make this entire thing an option? E.g., the -B frame setting could take an option +l for last and then we plot it at the end, else the beginning. |
Also, it seems data should take precedence over frames, so plotting data overlapping on frames should be more important. |
I always prefer a simple and consistent system, which is easy to document (for us) and to understand (for users). Thus, for base frame, I prefer to always have it at the start. If users don't like it, it's easy to call the basemap module after.
Not a good idea to me. -B is already too complicated. I'm afraid users won't notice that we add one more modifier to it. |
Well, we are talking about plot right? For others, except text, plotting overflow frames does not happen. And in plot we have -N to not clip, because default is clipping. So, frames should be plotted at the end, except -N is active. |
Those are good points @seisman, I agree that -B does not have a shortage of modifiers. In summary then, each module should:
As @joa-quim points out, plot and plot3d (in 2-D) may be exceptions where -N is needed for the above to be true, else we plot the frame after data. Are we converging on a code-able recipe? |
I thin yes, but it seems to me that there would be less exceptions if the frame is plotted at the end by default and at the beginning for the exceptions. |
We can. That means plot frame first when
else at end. |
Updated recipe:
Are we in agreement on this plan, guys? |
👍 |
Sounds good to me. |
The only reason this is marginally tricky is that MB system calls gmt_map_basemap (GMT) so I either pass kep settings via GMT or we add another super-function that calls this one. SO the strategy is have both a before and after gmt_map_basemap call but what they do may vary according to some settings. |
Close to wrapping it up after many changes in all plot programs. I broke something in psrose (only one not using gmt_map_basemap) so will need to fix that tomorrow (was trying to draw gridlines before data). There will be lots of PS changes with very tiny changes perhaps only noticeable by gm. |
Description of the desired feature
There are several aspects to consider regarding when to place gridlines, basemap frame and annotations+ticks on a plot. We recently learned that when MAP_FRAME_TYPE=inside then it is important that the annotations and ticks are plotted at the end of the module, whereas we typically lay down the annotations first. Note: The user can always achieve any other result by using a single basemap command before or after the data plotting, but we should have good and consistent default actions.
The normal rule has been that we always lay down the full basemap (frame, annotations+ticks, optional gridlines) prior to plotting anything else in the module. This rule is ignored for the following cases:
If MAP_FRAME_TYPE=inside then annotations shall be plotted at the end of the module.
Unresolved is the drawing of the base frame itself. For some modules like plot -N, we will plot symbols that normally can overprint the frame. To me, it looks ugly to have the frame plot on top of these points. Also, symbols that may start at the baseframe, such as vertical or horizontal bars, will overprint the frame by at least half the frame pen (and more if there is bar outline). In contrast, here I think plotting the baseframe last looks better. Two options:
Always draw baseframe at the start. This means items can and will plot on top of the frame.
Always draw baseframe at the end. This means symbols at or on the border will have a fat line cutting through them.
Whatever we decide, some tests may need to be recoded to accomplish what we wanted to show. Comments, @joa-quim and @seisman ?
The text was updated successfully, but these errors were encountered: