-
Notifications
You must be signed in to change notification settings - Fork 351
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
Update how CPT hinges are handled #2416
Conversation
Separate between soft and hard hinges. Hard hinges are data driven like those for bathymetry or magnetics, while soft hinges are ignored unless +h[hinge] is given.
Notes to self: the normalized hinge value is always 0. When we internally normalize a CPT for 0-1 in gmt_sample_cpt the normalized hinge will be at 0.5. The user-supplied hinge will be in user coordinates [0]. |
Explain soft and hard hinges
I believe this PR is ready for review. I have improved the documentation pertaining to CPTs by explaining the new soft and hard hinges, linking to the actual CPT plots in the appendix, adding triangles to indicate which ones have soft or hard hinges, and introduce two include rst_files that programs that produce (create_cpt.rst_) or use with grids (use_cpt_grd.rst_) includes to spell out what -C does. I hope to later do one for the remaining tools that read CPTs (plot, etc) but these are still too specific to the module. In the process I had to update a few PS since we basically reverted the hard hinges from many CPTS such as polar, split, etc. For instance, this demonstrates that polar no longer has a hard hinge:
but it can be activated by forcing a hinge:
and instead putting the hinge at 2:
|
There are a few things I do not understand and may need to be clarified:
Personally, I think this is making things way too complicated with those hinges. I think users should not be allowed to set the intervals on output CPT files, i.e. changing from continuous to discrete or vice versa; then the whole issue becomes moot. If a CPT has, e.g., 16 discrete colours, like Conversely, a colour map like True, the current implementation provides a lot of possibilities, but at the detriment of clarity, and opening the door to a lot of user-misuse. |
Thanks for the feedback. Here are some background before I address your specific concerns: In GMT 6 we added HINGE to several CPTs and in the process introduced backwards incompatibilities. The discussion in #2412 captures those problems. We realized there is a difference between what I now call a hard hinge (e.g., sea-level, specified by a feature of the intended data) versus a soft hinge (i.e., the white point in polar, which is not tied to a data feature per se). The 6.0 broke the ability to make a polar-like CPT that goes from 0 to 100 with a white point at 50, for instance. The solution was to restore backwards compatibility but recognize this second group of hinge-worthy CPTs by flagging them as having soft hinges that the user can activate if they so desire via +h[hinge] (e.g., when not specifying a symmetric range about zero or not selecting zero as their data hinge). OK, some answers:
Yes, and your feedback makes me realize that there is no point exposing the user to the issue of normalized z-values and the -1/+1 versus 0/1. It is irrelevant to them.
The Cookbook makes this distinction I think by contrasting the normalized z' values with the users data values. So the hinge is in user data values. I will make this more clear in the documentation for -C.
Yes, internal issue and I will remove that. It may be placed as comments for gurus who need to make new master CPTs in the future.
Yes, discrete CPTs have hinges everywhere; this distinction will be clarified. Nothing new here though. What we should add is that selecting discrete nodes may introduce aliasing of the original color table; I think we already warn when users create some of these.
These modifiers goes back to at least 5.2 or before. Their documentation has been sketchy and only present in the cookbook. The initial reason for these modifiers was to have the ability to use a CPT scaled to meters (e.g., for a topography grid) but be able to use it with psscale to make a km CPT without having to make a second CPT just for that purpose. Furthermore, the same modifiers have also been available to grids from that time as well, converting the x and y values in Cartesian grids between different distance units (e|k|m|M|n|u|s). So I need to emphasize distance unit more clearly. Thus, +U|u is a shared and long-lived mechanism for both CPTs and grids. I will implement the changes I mentioned next. |
I have update the documentation discussion of CPTs in the cookbook and the two new include rst_ files regarding hinges. |
See the script below. The output seems incorrect.
|
Yes, I see the discrete output tables are wrong - it looks fine with most of the continuous. I have reverted this to WIP and will work on this a bit later. |
Unrelated to the script above but: Should we impose that all the GMT master CPTs be continuous? It is really treacherous to have users create discrete tables by resampling discrete CPTs, since the number of slices in the master vs the ones requested cause really problems. |
At least not the |
But would you want Lester to run |
If it's going to be used in a FAA map maybe that's fine. What I want is to continue to use |
I guess what I think we would like to avoid is bad user decisions in making discrete tables that badly alias the original tables, especially if they are discrete to start with. |
You can bug them with a message saying "Resampling a discrete CPT is really a BAD idea". |
That comes back to what I said before. Maybe we should not even allow to change the intervals from discrete CPTs. Just like mag.cpt, they are designed a certain way, and users should not be allowed to meddle with it. I'm also not in favour of making discrete CPTs out of continuous ones, but that is way less dangerous. |
|
I am also OK with rules 1-3. The issue I have is with hard versus soft hinges. A hard hinge means what it says, it is inflexible because it is tied to a physical feature (shoreline). A soft hinge is independent of data and instead reflects a point of rapid color change in the CPT that could be tied to a data value hinge, and the user can do so via +hz. I am fine with the idea of using polar to show deviation in seismic velocities from 6.0 km/s, for instance, via |
With rules 1-3, |
If we can change hard hinges ... they are no hard anymore and then we should only have hinges |
Yes. We either have hard vs soft hinges, or just hinges. The command above gives (with rule 2):
but
|
So we are not talking the same rules. |
Well, doing otherwise takes us to -G:
My first implementation stretched zmin or zmax to reach the hinge at 0. The above is the case where we leave zmin/zmax along and just toss the other half of the CPT. To strictly interpolate 2000/4000 to mean just that section of geo has not been done (but possible via -G). |
Should have said that CPTs with a hard hinge, like any CPT, are stretchable, hence the color at the users 2000 will be the color from the hinge. Otherwise the CPT would be completely static and unchangeable. You then run gmt makecpt -Ggeo > mine.cpt and use that. |
I would like this to get resolved so we can plan 6.1 CPTs with hard hinges and ranges (e.g., geo with range RANGE = -8000/8000) can obviously be stretched and resampled: We may want to go from -12000 to +9000 meters, for instance. The range of the CPT is never fixed; it is just a default range when none is given in makecpt. Hence, commands like There may be cases where you want to extract only a subset of the CPT colors. We added -G for that, but this is a very special operation that few people would ever need. Thus, it seems the final decision we are stuck at has to do with the meaning of a hard hinge. I am arguing that it should be immutable: It is what it is, and the designer of the CPT wants it to be a fixed boundary tied to the physical properties it was intended for (topographic relief). In contrast, a soft hinge is mutable; you can change it with +hz. If it were not so and +h could apply to the hard hinges as well, then the only difference there would be between hard and soft is this: hard: There is always a hinge (no +h needed to activate it) and we stretch the output differently, except when user range excludes the hinge where we discard the unused half of the CPT, then sample normally. |
Re-reading this again I have no strong opinion on the two alternatives, but the second (to let a hard hinge soften a bit and move) gives more freedom without increasing confusion. The last paragraph
is what should go into the docs. |
OK, I can live with that. After all, it takes an unprecendented act on part of the user to move the geo hinge away from 0 via +h, so not likely to happen by accident. I will implement the movable hard hinge and see how it goes. |
Yes, this is exactly what I expected. |
Yes, that's how I understood it. I assume that an equivalent of case d) for soft hinges, e.g. -Cpolar+h -T10/20 will give the same cpt as i) but with [10 20] limits. |
Yes:
|
Hi @seisman, if you are happy with the latest merge in this PR please review and then we can fix any issues and merge this back to the mothership. |
A crash by a user error:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This PR looks good to me, except the small crash in my previous comment.
@PaulWessel Remember to click the "Squash and merge" button when merging. Don't use the first one. |
Thanks, done. |
Separate between soft and hard hinges. Hard hinges are data driven like those for bathymetry or magnetics, while soft hinges are ignored unless +h[hinge] is given. Explain this better in the CPT documentation.
Description of proposed changes