-
Notifications
You must be signed in to change notification settings - Fork 229
Complete documentation of grdimage #620
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
Conversation
Add automatic docstrings for frame (B), cmap (C), projection (J), region (R), timestamp (U), verbose (V), and interpolation (n). Also removed alias pen (W) that actually doesn't work.
Copied from https://docs.generic-mapping-tools.org/6.1/grdimage.html, swapping out short command-line arguments for long aliases.
41b9e01
to
14ba332
Compare
Ok, ready for review, and preview at https://pygmt-git-grdimage-documentallargs.gmt.vercel.app/api/generated/pygmt.Figure.grdimage.html#pygmt.Figure.grdimage! Best to take a closer look, I'm pretty sure I've messed up on some formatting. Also no rush to do it today since it's getting late. This also helps with #618, documenting the fact that |
Co-authored-by: Dongdong Tian <[email protected]>
pygmt/base_plotting.py
Outdated
`grdmath` or `grdhisteq`. A third alternative is available when GMT is | ||
build with GDAL support. Pass **image** which can be an image file | ||
(geo-referenced or not). In this case the image can optionally be |
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.
It reads awkwardly.
`grdmath` or `grdhisteq`. A third alternative is available when GMT is | |
build with GDAL support. Pass **image** which can be an image file | |
(geo-referenced or not). In this case the image can optionally be | |
`grdmath` or `grdhisteq`. A third alternative is available when GMT is | |
build with GDAL support. Pass **image** which can be an image file | |
(geo-referenced or not). In this case the image can optionally be |
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.
Agree that this could be worded better, currently it's just copied from upstream GMT at https://github.com/GenericMappingTools/gmt/blob/8c0b548e52938f91bfb15f47f27d023488003ef8/doc/rst/source/grdimage_common.rst_#L14-L16. Maybe we should take out the grdgradient
, grdmath
and grdhisteq
parts since they're not wrapped in PyGMT yet?
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.
I'm afraid we may forget to add them back when the wrappers are available.
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.
Maybe keep them for now, better to over-document than not. Doubt we'll see grdmath
anytime soon (who uses Reverse Polish notation?!!), but grdgradient
would definitely come, and grdhisteq
will be a nice one for stretching colormaps.
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.
Yes, I agree.
pygmt/base_plotting.py
Outdated
`grdmath` or `grdhisteq`. A third alternative is available when GMT is | ||
build with GDAL support. Pass **image** which can be an image file | ||
(geo-referenced or not). In this case the image can optionally be |
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.
Agree that this could be worded better, currently it's just copied from upstream GMT at https://github.com/GenericMappingTools/gmt/blob/8c0b548e52938f91bfb15f47f27d023488003ef8/doc/rst/source/grdimage_common.rst_#L14-L16. Maybe we should take out the grdgradient
, grdmath
and grdhisteq
parts since they're not wrapped in PyGMT yet?
pygmt/base_plotting.py
Outdated
(geo-referenced or not). In this case the image can optionally be | ||
illuminated with the file provided via the *shading* option. Here, if | ||
image has no coordinates then those of the intensity file will be used. |
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.
What do you think about taking out this sentence about image, related to the change at https://github.com/GenericMappingTools/pygmt/pull/620/files#r492612750.
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.
What do you think about taking out this sentence about image, related to the change at https://github.com/GenericMappingTools/pygmt/pull/620/files#r492612750.
The changes are big. It's unclear to me what you mean by "taking out this sentence about image"?
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.
Oops, wrong link. Should be #620 (comment). The part where we took out grid | image
.
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.
The reason to take out grid | image
is, it's a little unclear what grid | image
means, and for the grid
argument, we already mention that grid
could be a image:
The file name or a DataArray containing the input 2-D gridded data set or image to be plotted
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.
Yes, agree that taking grid | image
is ok. But would this lead to confusion about this sentence:
Pass **image** which can be an image file
(geo-referenced or not). In this case the image can optionally be
illuminated with the file provided via the *shading* option. Here, if
image has no coordinates then those of the intensity file will be used.
I suppose we could just keep it to keep it in line with upstream GMT?
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.
That's why I said these sentences don't read well in #620 (comment).
Perhaps we can change:
A third alternative is available when GMT is build with GDAL support. Pass image which can be an image file (geo-referenced or not). In this case the image can optionally be illuminated with the file provided via the -I option. Here, if image has no coordinates then those of the intensity file will be used.
to
If GMT is built with GDAL support, grid can be an image file (geo-referenced or not). In this case the image can optionally be illuminated with the file provided via the -I option. Here, if image has no coordinates then those of the intensity file will be used.
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.
Looks good enough (mentioning that image can be used with GDAL support). I'll commit the change.
Co-Authored-By: Dongdong Tian <[email protected]>
f3aa3f7
to
924e5a8
Compare
Co-Authored-By: Dongdong Tian <[email protected]>
pygmt/base_plotting.py
Outdated
grid via a call to `grdgradient`; append **+a** \\ *azimuth*, | ||
**+n** \\ *args*, and **+m** \\ *ambient* to specify azimuth, |
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.
There should be no spaces between modifier and value:
grid via a call to `grdgradient`; append **+a** \\ *azimuth*, | |
**+n** \\ *args*, and **+m** \\ *ambient* to specify azimuth, | |
grid via a call to `grdgradient`; append **+a**\\ *azimuth*, | |
**+n**\\ *args*, and **+m**\\ *ambient* to specify azimuth, |
Are you sure we need double back-slashes?
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.
Good catch. Single backslash would result in a flake8 error W605 invalid escape sequence '\ '
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.
Single backslash would result in a flake8 error
W605 invalid escape sequence '\ '
Double backslashes in ReST syntax doesn't give what we want if they're not in docstring: http://rst.ninjs.org/#KiorYSoqXFwgKmF6aW11dGgq
Why does flake8 check ReST syntax? Is it a flake8 bug? Or can we make flake8 ignore it for ReST strings?
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.
Anyway, the documentation looks good now. We may see if we can avoid double backslashes in the future.
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.
Double backslashes in ReST syntax doesn't give what we want if they're not in docstring: http://rst.ninjs.org/#KiorYSoqXFwgKmF6aW11dGgq
The double backslash is needed for Python, the alternative would be to use a raw string (e.g. r" **+n**\ *args* "
). We came across this at #525 (comment), might be good if we can standardize this in our CONTRIBUTING.md document (open an issue?).
Anyways, the rendered version looks fine:
Why does flake8 check ReST syntax? Is it a flake8 bug? Or can we make flake8 ignore it for ReST strings?
A quick search yields https://github.com/kataev/flake8-rst, but I haven't tried it, and don't know if it does what we want.
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.
GMT uses singe backslash syntax like **+a**\ *azimuth*
. If we copy documentation from GMT, then I expect we will see the same warning often.
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.
I'll open up an issue for this to continue the discussion :)
Co-Authored-By: Dongdong Tian <[email protected]>
Hmm, there's a strange failure on the Ubuntu Python 3.6 test at https://github.com/GenericMappingTools/pygmt/pull/620/checks?check_run_id=1152171757 with a missing earth_relief grid. I'll re-run just to be sure before merging. |
Description of proposed changes
Time to put an end to all the noise about
grdimage
not being properly documented! To be fair, the documentation at https://www.pygmt.org/v0.2.0/api/generated/pygmt.Figure.grdimage.html is pretty embarrasing, considering thatgrdimage
is one of the more widely used functions! For reference, upstream GMT docs is at https://docs.generic-mapping-tools.org/6.1/grdimage.htmlMentioned before at #364 (comment) and https://forum.generic-mapping-tools.org/t/grdgradient-in-pygmt/723/12.
Live documentation preview is at https://pygmt-git-grdimage-documentallargs.gmt.vercel.app/api/generated/pygmt.Figure.grdimage.html#pygmt.Figure.grdimage.
TODO:
Arguments/Aliases to document (see also https://www.generic-mapping-tools.org/GMT.jl/latest/#GMT.grdimage):
fFixes #
Reminders
make format
andmake check
to make sure the code follows the style guide.doc/api/index.rst
.