Closed seisman closed 4 years ago
I think those CPTs do have a hinge, but I agree that it being hardwired to 0 is not useful in all cases. The before/after effect is of course the fix to actually do what we said we were doing regarding resampling. Possible options:
I guess option 2 is more flexible and also can handle option 1 without making that the default action.
If I understand it correctly, the old behavior is to ignore the hinge, and we declared it as a bug and fix it in #2334. However, it means the new behavior will break many old scripts.
Yes, but clearly the intent of the hinge was to honor it, so there was a but. However, we are free to define what should happen when the requested range does not include the hinge, and we could decide that the only sensible thing to do is to ignore the hinge in those cases. Unlike CPTs for bathymetry (where hinge = 0 is a good thing), we could also decide that hinge for polar etc does not make sense since 0 is not a universal value for hinges.
I don't see much point to have a hinge in the polar CPT. And I like +h[z] idea, which has another virtue to provide hinges to any CPT that were not defined with one.
I can also already see a new movie of the waterworld where we flood the Earth only by changing the z in -hz
Perhaps we should remove the HINGE setting from the non-bathymetry/topo CPTs first, then implement a +h[z] for removing/adding a hinge as a new feature then.
Hm, removing the hinges is actually a backward compat measure.
Testing my +h modifier. Adding +h to @seisman's -Cpolar now gives this:
I am not sure what will happen if the +hz does not match one of the boundaries in the cpt file. I don't think we want to interpolate and breat a slice just to put in an odd z value for hinge.
Hm, but with the hinge in cpt we can put it where we want, as long as it’s inside the min/max range. How is that -hz different? The implementation?
From: Paul Wessel notifications@github.com Sent: Monday, January 6, 2020 11:49 PM To: GenericMappingTools/gmt gmt@noreply.github.com Cc: Joaquim Manuel Freire Luís jluis@ualg.pt; Comment comment@noreply.github.com Subject: Re: [GenericMappingTools/gmt] CPT issues related to hinges (#2412)
Testing my +h modifier. Adding +h to @seismanhttps://github.com/seisman's -Cpolar now gives this:
[map]https://user-images.githubusercontent.com/26473567/71857270-0757bf80-308b-11ea-8e60-5e5806203740.png
I am not sure what will happen if the +hz does not match one of the boundaries in the cpt file. I don't think we want to interpolate and breat a slice just to put in an odd z value for hinge.
— You are receiving this because you commented. Reply to this email directly, view it on GitHubhttps://github.com/GenericMappingTools/gmt/issues/2412?email_source=notifications&email_token=AAEDF2LHUTW5TNAJJQ5A3FLQ4O7OFA5CNFSM4KDGZFOKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEIHFUSI#issuecomment-571365961, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AAEDF2PZ6IJ76JXDR4JGLGLQ4O7OFANCNFSM4KDGZFOA.
Havent tested that yet but the assumption in my implementation is that the CPT hinge is one of the z-nodes in the cpt.
Here are my expectation:
gmt makecpt -Cpolar -T-100/200/20
The default behavior is ignoring the hinge, the same as GMT5 and GMT 6.0.0 does.
gmt makecpt -Cpolar+h -T-100/200/20
With +h modifier, the hinge is honored, and the default hinge is 0.
-Cpolar+h50 should set the hinge to 50. In this case, the output should be the same as -Cpolar only.
gmt makecpt -Cpolar+h100 -T-100/200/20
I don't have a figure for this, but I expect to see blue to white from -100 to 100, then white to red from 100 to 200.
The comments above apply to non-bathymetry/topo CPTs only. For bathymetry/topo CPTs, the hinge should be always honored, i.e. -Ctopo
is equivalent to -Ctopo+h
.
OK, I can work on that.
I think this means we remove the HINGE keyword from the non-bathy/topo CPTs since otherwise I dont know when to honor hinges. So polar+h is needed to get the hinge as you indicate.
If we remove the HINGE from non-bathy/topo CPTs, how do we know if a CPT can have a hinge (i.e. polar can have a hinge, but seis cannot)?
I think any CPT can have a hinge but perhaps it makes little sense to push on on the seis cpt, but you could. We dont have to limit that I think.
Here is the list of all CPTs with hinges curently:
berlin.cpt:# HINGE = 0
broc.cpt:# HINGE = 0
cork.cpt:# HINGE = 0
earth.cpt:# HINGE = 0
etopo1.cpt:# HINGE = -0.001
geo.cpt:# HINGE = 0
globe.cpt:# HINGE = 0
lisbon.cpt:# HINGE = 0
mag.cpt:# HINGE = 0
no_green.cpt:# HINGE = 0
oleron.cpt:# HINGE = 0
polar.cpt:# HINGE = 0
red2green.cpt:# HINGE = 0
relief.cpt:# HINGE = 0
sealand.cpt:# HINGE = 0
split.cpt:# HINGE = 0
srtm.cpt:# HINGE = 1
terra.cpt:# HINGE = 0
tofino.cpt:# HINGE = 0
topo.cpt:# HINGE = 0
vik.cpt:# HINGE = 0
world.cpt:# HINGE = 0
I think the only one that should default to have a hinge are earth, etopo1, geo, globe, mag, relief, sealand, srtm, terra, topo, world.
Note taht some of the perceptually uniform colormaps are bimodal, such as vik, so they are kind of meant to have a hinge. But so is polar, and there is no rule it must be at zero, so best to remove those, too. I have to rescale the cpt masters to go from 0-1 instead of -1/1 as well for these.
I think the only one that should default to have a hinge are earth, etopo1, geo, globe, mag, relief, sealand, srtm, terra, topo, world.
I agree.
Note taht some of the perceptually uniform colormaps are bimodal, such as vik, so they are kind of meant to have a hinge. But so is polar, and there is no rule it must be at zero, so best to remove those, too. I have to rescale the cpt masters to go from 0-1 instead of -1/1 as well for these.
I'm a little confused. If there is no hinge in a master CPT, how do you resample the CPT? For example, if the master polar CPT is from 0 to 1, what does "gmt makecpt -T-10/50/5 -Cpolar+h10" mean?
Perhaps it is simplest to distinguish between a hard hinge and a soft hinge. We let the bathy/topo have a hard hinge at 0, but can let polar have a soft hinge at zero. Soft hinges are ignored unless +h is used while hard hinges are never ignored since they were designed with that feature in mind. So in your polar example the soft hinge of z' = 0 (normalized z' value at white) would be mapped to use data value z = 10. I think this is doable. Since the CPT language is not defined we can change the HINGE = 0 to HARD_HINGE = 0 and replace some with SOFT_HINGE = 0. I wonder if we even have to have a value for these since they are always at normalized z' = 0 except two case: srtm at 1 which I think is a special case where the hinge is in meter (we try to avoid painting the ocean) and etopo1.cpt which was made by Lester Anderson. Maybe I can redesign that one to use 0 as well.
In fact, all my hinged CPTs go from -1 to 1 with a hinge at 0, so I think they should all have hinge for z' = 0 and then that gets mapped to whatever you want (which normally is z = 0 but can be overridden).
That looks good to me.
So we should remove the HINGE keyword from non-bathy/topo CPTs. Then all the CPT can be divided into three groups:
Script below gives different results after #2327 was merged:
Before:
After:
Issues:
For the first issue, possible solutions are: