-
Notifications
You must be signed in to change notification settings - Fork 348
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
Let a signed grid cross size mean centered or asymmetrical grid ticks #2877
Conversation
See #2875 for context.
Hi @KristofKoch, any luck it testing this branch? |
Hi @PaulWessel, please give me another 36h … I'm currently at work in my day job. Will give it a try as soon as I can. |
No worries. At my day-job too! |
Thinking about possible improvements to this. Clearly, as implemented, it is assumed that there are gridlines present to support the ticks. So in an ideal world this would be one set of -Bs and -Bp to do the course and fine ticks. But your examples has three levels: course grid lines, finer longer ticks, and closely-spaced short ticks. We have no way of doing three settings (yet). |
One option is something like this script (which does not do what I want yet, but I will explain below):
Here we are saying that the longer, secondary ticks should occur every 10 minutes and the primary, shorter ticks should be placed every 2 minutes. However, this is all under the assumption that these ticks are only drawn along the earlier 1x1 degree gridlines. As it is now, we would just get lots of ticks every 10m and 2m. A solution would be to remember the previous gridline interval (keep track of last gridline interval used) and then when cross sizes are negative we use the previous gridline interval with the specified gridcross interval(s) to accomplish the desired plot. In the process I would let MAP_GRID_CROSS_SIZE accept the syntax primary/secondary for cross sizes. Currently it expects one item and sets both, but if given two separated by a slash we could assign the two separately. This is a script that gives what I think you want (the hard way):
with result |
Hi Paul, that virus is wreaking havoc at work … but finally: I like your proposed new syntax. Is there a way to get it to work for even more (many!) sets of tick marks? Something like And as I'm already dreaming things up – is there a way to get tick marks extend both sides of the grid line (not a cross)? I don't know if "=" is a good choice in terms of parsing but in my mind it would be something like "-" = one side, "=" = both sides of the grid line. So this:
would lead to something like this: where you have the single side ticks (1' & 5') mixed with double-sided tick marks (10' & 30'). The reason why I don't want a cross are tick marks at high latitudes with Lambert conic conformal or polar stereographic projections. Here the latitude grid lines bend so much that the crosses become visible. |
And another possible improvement … maybe there is a chance to specify pen thickness on a per tick mark basis as well? The 1' ticks having a thinner pen than the 30' ticks? Maybe I can help by writing the documentation for those features? |
Hi @KristofKoch, I will think about this. I don't think we will allow a 3rd tick/pen in one go, so since these maps count for 0.001% of GMT maps it is OK if you have to run a few commands to get it - you can always write a function of alias for something like that if you need it often. |
Hi @PaulWessel, I agree with you that more than two ticks are rarely needed and can easily achieved if desired. None the less I take pride in being responsible for 0.001% of all GMT maps ;-) |
Hi @KristofKoch. A small update: If grid cross sizes are specified with a leading + then they become symmetrical ticks, a leading - still means asymmetrical ticks, and no leading sign means regular grid cross. Please give this a try and see if you can demonstrate to me how it may fail for high latitudes, then post a short basemap script here so I can test further. I suspect I need to do more work to cover the case you mention. |
Hi @PaulWessel, thank you for working on this. I gave 6.1.0_7c0ba1d_2020.03.19 a test. I found a few issues. For ease I just used lon or lat ticks. Pen stroke: It gets funny if I use a pen thicker than the grid lines:
High latitudes: There seems to be no difference between
There is a good chance I'm using the Looking at asymmetric ticks I have a similar problem as with the two above. There still is a lon tick which escapes the grid line:
Is it me again not using |
For grid ticks one must first lay down a single (primary) set of gridlines, then that spacing sets the line spacing for the denser grid ticks (primary and secondary). I generalized functions used to set and get current CPT to avoid duplicated code.
Thanks @KristofKoch, I have made many changes to address the shortcomings. Note the grid tick feature below is only available to modern mode:
As an example, this test first lays down a 1x1 degree set of gridlines, then applies both 10m symmetrical and 2m asymmetrical grid ticks with one basemap command.
This script produces the plot below. So one call for coarse gridlines, one call to do the two sets of ticks. You can repeat for even more complications. Each graphics item (subplot panel, inset, figure) maintains its own memory for gridlines since you must draw them first for each such item. The memory lasts until another set of gridlines are drawn or the plot completes. Please give it a spin for other latitudes and projections. I also compute centered slope so your tick on the vertical central meridian will be horizontal, not tilted. |
Hi @PaulWessel these are big improvements. Awesome! I gave 6.1.0_db366d6_2020.03.20 a test and in generally behaves as expected with the "new" syntax. However a small problem remains: At high latitudes the ticks still peak out from the bent latitude grid lines. The placing is logically sound. I want a tick every 1°, I get one. Exaggerated example:
They even make the step down at N85° in lon density. Great! But unfortunately some ugliness when plotted at a lat/lon grid line junction. Maybe there is an easy way to omit them there? And another thing – any chance to get the functionality in classic mode as well? My workflow relies heavily on just generating those layers with updated data and then sandwich it together with all the other preproduced and stored layers in a second step to keep generation time low. |
Hi @KristofKoch. It makes sense not to draw the ticks exactly at the gridlines since the latter are curved and the ticks are straight. I think that is what you mean. I can probably fix that. As for classic: It cannot do the remembering. However, you should be able to do it the way we started off with, where you alternate course and detailed ticks. |
Hi @PaulWessel – good evening to Hawai'i. That's exactly what I meant with my convoluted sentence above. Don't draw the ticks if placed exactly at the grid lines. |
66129f4 does what it promises. Thanks! |
A thought on the polar cap discussion: My idea with showing only primary ticks was under the assumption that the primary ticks are those with the wider spacing – a look in the docs showed that the convention seems to be the other way around. I think you understand what I mean – just show the wider spaced ticks. |
Will get to this after family FaceTime with remote kids. |
I will tick the polar cap parallel(s). For the coarse gridlines toward the poles I think we only do the primary grid ticks, but I will experiment. The grid line spacing up there is controlled by MAP_POLAR_CAP. |
The full set of ticks at the cap parallels? Or a reduced (primary ticks only) set? |
Full set of ticks on the polar cap - like the other parallels, but only coarser on the meridians. However, perhaps it may make more sense to do just coarser ticks on both. I write courser because primary and secondary labels is a bit backwards in the sense that for time axis the smallest spacing is called primary and the coarser spacing is called secondary. So above, we may drop to just secondary since space is getting limited. I could also automatically pick the coarsest of the two to avoid any confusion. |
I'm not sure if there is a "perfect" solution for the cap parallels – If I look at the full globe ( Thank you for clarification where the primary and secondary comes from … I was quite a bit surprised to learn this in the docs. I agree for geo purposes it "feels backwards". |
Toying around with this a bit further I agree with you that it may make most sense to do just the coarser ticks on both. Because if there is enough space for the denser ticks I can as well move The "auto-pick-coarsest-ticks" would be a nice thing to have as well. Might also suppress some questions in the forums. |
Need feedback from @joa-quim and @seisman on this: The concept of primary and secondary annotations/ticks/gridlines originated with time-axes where it is often required to annotate more than one unit. In these cases, we use the primary term to mean the annotation closest to the axis and the secondary term to be the one further out. For time axes this always meant that primary intervals were smaller than secondary intervals: For geographic maps with two sets of annotations (rarely used) we actually do the same: Thus, for the case at hand (grid ticks) we must stay with the same scheme. Hence, for grid-ticks associated with polar caps I will use the coarser secondary gridline spacing, assuming it is the coarser. However, @KristofKoch example above switched the two and he used the coarser as primary and the detailed as secondary. This can lead to confusion. Possible remedies:
I think option 3 is the best since it follows our intention and also handles any user mixup. We may wish to give a warning when this happens. Comments? |
Historical correction. This concept was born when I, on board of French ships, saw their maps with double annotations made with their Caraibes Sun software and started bugging you to have the same in GMT (much like Kristof now). I have not been following this matter closely (busy with GEOS) but yes, option 3 is the more versatile one. |
Yes, that is true for maps. I don't remember if geo came before time. Time happened around 2004 (for GMT 4I think). |
This uses coarser interval as secondary. Another PR will deal with sorting primary vs secondary so the -Bs vs -Bp will be less of an issue.
Made a 1 month cruise in 1998 on board of l'Atalant. Probably from around that time. |
if users mix up -Bp and -Bs settings we will swap them.
Hi @KristofKoch, please check this out once more. The changes are:
|
Wow – @PaulWessel that's impressive work. Thank you very much! I feel it is about time to send another beer (maybe a keg would be more adequate) your way for all the work I'm causing.
|
I am trying to avoid having to swap ~10 different parameters that have _PRIMARY and _SECONDARY in them - see gmt.conf.rst for all those parameters (pens, tick lengths, colors, etc., etc.). |
@PaulWessel I see your point. I think your proposal is the more sensible way. Warn and explain always - even if polar cap is not involved - but don't swap anything. Thus old scripts keep working (and get a hint on how to improve them) and there should be no new scripts besides my few test scripts yet. So win-win? |
Hi @KristofKoch, I have improved the documentation for -B in usage and rst files to clarify that primary sets the more frequent annotations while secondary sets the less frequent intervals. This was largely missing except in the context of time axes. I have also changed my test above to just warn and explain, with no forced swapping. This should alley fears of breaking backwards compatibility. I think this PR is good to merge now, yes? |
I am answering my question: Yes good to merge. Happening now. |
Good morning from the other side of the blue marble, looks good to me as well. @PaulWessel , thank you for your efforts! This makes my life a lot easier. |
See #2875 for context. Hope @KristofKoch can give it a test. Alternate giving a small x-grid interval and course y-interval to get the effect. E.g.,