Conversation
Wrap the `grdcut` function. Ideally it should take a grid file or a `xarray.DataArray` as input, and store output as a grid file or return a `xarray.DataArray`. Supported features: - [X] input: grid file; output: grid file - [X] input: grid file; output: `xarray.DataArray` - [ ] input: `xarray.DataArray`; output: grid file - [ ] input: `xarray.DataArray`; output: `xarray.DataArray` Passing `xarray.DataArray` to `grdcut` is not implenmented in the GMT 6.0.0. See GenericMappingTools/gmt#3532 for a feature request to the upstream GMT.
grdinfo in GMT 6.1.0 reports the grid registration in the last column, while GMT 6.0.0 doesn't.
|
This is good work @seisman! It was on my TODO list a while back, but I realize that cropping a Cartesian bounding box could be done easily enough in |
Co-authored-by: Wei Ji <23487320+weiji14@users.noreply.github.com>
|
I will open a feature request or a bug report to remind us that grdcut doesn't support xarray.DataArray due to a missing feature from upstream GMT. |
|
Do you have any idea why the test |
|
There is one more failure on Windows: You use Lines 90 to 94 in 516e799 while I use Is it the reason? |
Yes, see #245 (comment) and commit 3324235, the comment which reads:
|
Never mind. I just forgot to push my changes. |
Co-authored-by: Wei Ji <23487320+weiji14@users.noreply.github.com>
Co-authored-by: Wei Ji <23487320+weiji14@users.noreply.github.com>
weiji14
left a comment
There was a problem hiding this comment.
Cool, thanks for working on this! I think it's fine to merge this now, and we can refactor later. Just one comment, which is more about integrating all the other grid related PRs we have open.
| lib.call_module("grdcut", arg_str) | ||
|
|
||
| if outgrid == tmpfile.name: # if user did not set outgrid, return DataArray | ||
| with xr.open_dataarray(outgrid) as dataarray: |
There was a problem hiding this comment.
After starting #494, I'm starting to wonder if we should have a pygmt.open function to load NetCDF files with the node_offset attribute inside the xarray.DataArray, as needed if we're going to start chaining operations as you mentioned in #476 (comment).
There was a problem hiding this comment.
If I understand the GMT C API correctly, GMT has its own data types (internally) for grids, CPT and data tables. It also provides API functions GMT_Read_Data and GMT_Write_Data, and two special modules gmtread and gmtwrite which I presume can read and write any GMT data types. Perhaps in the future we need to wrap these GMT data types. In this case, pygmt.read() and pygmt.write() may make more sense.
Description of proposed changes
Wrap the
grdcutfunction, which is the first step is to redesignthe
load_earth_relief()function (see #489).Ideally it should take a grid file or a
xarray.DataArrayas input, andstore output as a grid file or return a
xarray.DataArray.Supported features:
xarray.DataArrayxarray.DataArray; output: grid filexarray.DataArray; output:xarray.DataArrayPassing
xarray.DataArraytogrdcutis not implenmented in theGMT 6.0.0. See GenericMappingTools/gmt#3532 for
a feature request to the upstream GMT.
The long-form names of the grdcut function come from GMT.jl, but they're open for better naming.
The implementation of the
grdcut()function is very similar to thesurface()function.Reminders
make formatandmake checkto make sure the code follows the style guide.doc/api/index.rst.