Skip to content
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

Closed
PaulWessel opened this issue Sep 28, 2020 · 12 comments
Closed

Consistency on placement of gridlines and basemaps #4265

PaulWessel opened this issue Sep 28, 2020 · 12 comments

Comments

@PaulWessel
Copy link
Member

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:

  1. For modules plotting filled polygons (data, coast, solar, etc.) the gridlines shall be plotted at the end of the module (if 2-D).
  2. For modules plotting images (grdimage, grdview if 2-D, image, grdcontour with fill) the gridlines shall be plotted at the end of the module.

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 ?

@PaulWessel
Copy link
Member Author

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.

@PaulWessel
Copy link
Member Author

Also, it seems data should take precedence over frames, so plotting data overlapping on frames should be more important.

@seisman
Copy link
Member

seisman commented Sep 28, 2020

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.

the -B frame setting could take an option +l for last and then we plot it at the end, else the beginning.

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.

@joa-quim
Copy link
Member

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.

@PaulWessel
Copy link
Member Author

Those are good points @seisman, I agree that -B does not have a shortage of modifiers. In summary then, each module should:

  1. Plot the base frame itself
  2. Lay down optional gridlines except for the exceptions listed above
  3. Lay down annotations and ticks except if inside, but always if true 3-D
  4. Plot the data
  5. Overlay optional gridlines for the exections above
  6. Overlay annotations and ticks if inside

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?

@joa-quim
Copy link
Member

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.

@PaulWessel
Copy link
Member Author

We can. That means plot frame first when

  1. True 3-D or plot/plot3d with -N

else at end.

@PaulWessel
Copy link
Member Author

Updated recipe:

  1. Plot the base frame first if true 3-D or a plotting modules with a no-clip -N option active (plot, plot3d, text)
  2. Lay down optional gridlines except if plotting filled polygons, images.
  3. Lay down annotations and ticks except if inside, but always if true 3-D
  4. Plot the data
  5. Overlay optional gridlines if not plotted earlier as an exception
  6. Overlay annotations and ticks if inside
  7. Draw frame if not drawn earlier

Are we in agreement on this plan, guys?

@joa-quim
Copy link
Member

👍

@seisman
Copy link
Member

seisman commented Sep 28, 2020

Sounds good to me.

@PaulWessel
Copy link
Member Author

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.

@PaulWessel
Copy link
Member Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants