pygmt
pygmt copied to clipboard
Wrap ternary
This pull request wraps the GMT function ternary.
Preview docs at https://pygmt-git-wrap-ternary-gmt.vercel.app/api/generated/pygmt.Figure.ternary.html
Reminders
- [ ] Run
make formatandmake checkto make sure the code follows the style guide. - [ ] Add tests for new features or tests that would have caught the bug that you're fixing.
- [ ] Add new public functions/methods/classes to
doc/api/index.rst. - [ ] Write detailed docstrings for all functions/methods.
- [ ] If adding new functionality, add an example to docstrings or tutorials.
Slash Commands
You can write slash commands (/command) in the first line of a comment to perform
specific operations. Supported slash commands are:
/format: automatically format and lint the code/test-gmt-dev: run full tests on the latest GMT development version
I'm getting a weird problem where the axis labels on the right-side (b) axis isn't showing up. I'm not sure what I'm missing, as this follows along with the example on the GMT page for ternary, and there are still gridlines for that axis appearing in the final figure.
fig = pygmt.Figure()
pygmt.makecpt(cmap="turbo", series=[0, 80, 10])
fig.ternary(table="@ternary.txt",
region="0/100/0/100/0/100",
cmap=True,
projection="X6i",
frame= ["bafg+lAir",
"cafg+lLimestone",
"aafg+lWater"],
S="c0.1c")
fig.show()

I'm getting a weird problem where the axis labels on the right-side (b) axis isn't showing up. I'm not sure what I'm missing, as this follows along with the example on the GMT page for
ternary, and there are still gridlines for that axis appearing in the final figure.fig = pygmt.Figure() pygmt.makecpt(cmap="turbo", series=[0, 80, 10]) fig.ternary(table="@ternary.txt", region="0/100/0/100/0/100", cmap=True, projection="X6i", frame= ["bafg+lAir", "cafg+lLimestone", "aafg+lWater"], S="c0.1c") fig.show()
This was a bug in GMT in 6.2.0, which was fixed by https://github.com/GenericMappingTools/gmt/pull/5431.
This was a bug in GMT in 6.2.0, which was fixed by GenericMappingTools/gmt#5431.
@meghanrjones Is there a workaround for GMT 6.2.0, or will this plotting bug be the case until GMT releases a new version and PyGMT uses it?
This was a bug in GMT in 6.2.0, which was fixed by GenericMappingTools/gmt#5431.
@meghanrjones Is there a workaround for GMT 6.2.0, or will this plotting bug be the case until GMT releases a new version and PyGMT uses it?
You could try using pygmt.config(MAP_FRAME_AXIS, "WSE"), though using that internally would prevent users from overriding it unless you found a way to check whether the setting has been configured in the session.
Edit: To be more clear, it would need to be in a context manager for pygmt.ternary calls so that it doesn't impact other function calls.
You could try using pygmt.config(MAP_FRAME_AXIS, "WSE"), though using that internally would prevent users from overriding it unless you found a way to check whether the setting has been configured in the session.
Edit: To be more clear, it would need to be in a context manager for pygmt.ternary calls so that it doesn't impact other function calls.
I think calling ternary with a context manager will cause more confusion when none of the other plotting functions do, especially since this will presumably go back to normal in the next release of GMT (which I'm assuming will be after PyGMT v0.5.0 release). My thought is to just hold off on merging the upstream fix takes effect, as there are other methods to make ternary plots with Python.
Since we've bumped PyGMT's minimum GMT version to 6.3.0, do you want to give this PR another go @willschlitzer?
Summary of changed images
This is an auto-generated report of images that have changed on the DVC remote
| Status | Path |
|---|---|
| added | pygmt/tests/baseline/test_ternary.png |
Image diff(s)
Added images
- pygmt/tests/baseline/test_ternary.png
Modified images
| Path | Old | New |
|---|
Report last updated at commit 33b200e6fde5e2fadcaba01d47622076ce1489f1
/format
Hi @willschlitzer, I think this PR is good to merge after two small in-line suggestions (one for a line length issue to satisfy pylint and one to add a reference to plotting styles). Would you be open to moving forward with a merge rather than closing the PR?
@meghanrjones Not sure how I managed this (currently on a work computer), but didn't mean to close it! Thanks
@willschlitzer I think this PR is almost ready for merge. I'm wondering if you have some time to finalize this PR recently.
/format
The tests fail, likely due to the outdated baseline image. Could you please regenerate the baseline image using GMT 6.4.0 again?