Skip to content
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

Let surface return xr.DataArray instead of xr.Dataset #408

Merged
merged 1 commit into from
Apr 9, 2020

Conversation

weiji14
Copy link
Member

@weiji14 weiji14 commented Apr 9, 2020

Description of proposed changes

Docstring for surface says that an xr.DataArray should be returned, but xr.Dataset is given instead. Doing a quick fix here to ensure that we output an xr.DataArray which is required by other PyGMT modules that take in a grid input.

Fixes #407

Reminders

  • Run make format and make check to 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.

Docstring for `surface` says that an xr.DataArray should be returned, but xr.Dataset is given instead. Doing a quick fix here to ensure that we output an xr.DataArray which is required by other PyGMT modules that take in a grid input.
@weiji14
Copy link
Member Author

weiji14 commented Apr 9, 2020

Something seems to be up with our Continuous Integration/Deployment scripts (Codecov, Now and Travis?) but all of the status pages seem fine :/ Will leave it for now and retry tomorrow or so.

@leouieda
Copy link
Member

leouieda commented Apr 9, 2020

@weiji14 I've been having some trouble with Travis since they started that migration to their .com service. Not sure if that would break Now as well (seems unlikely).

Copy link
Member

@leouieda leouieda left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍 nice catch! Just need to figure out what's wrong with the CI but since tests pass, I'm fine with merging this.

@weiji14 weiji14 merged commit 5a5091e into master Apr 9, 2020
@weiji14 weiji14 deleted the surface/dataarray_output branch April 9, 2020 21:48
@weiji14
Copy link
Member Author

weiji14 commented Apr 9, 2020

@weiji14 I've been having some trouble with Travis since they started that migration to their .com service. Not sure if that would break Now as well (seems unlikely).

Not sure if it's an intermittent issue, but will keep an eye 👀 out.

weiji14 added a commit to weiji14/deepbedmap that referenced this pull request Jun 6, 2020
Bumps [pygmt](https://github.com/GenericMappingTools/pygmt) from 0.0.1a0-77-g4581a3e to 0.1.1!
- [Release notes](https://github.com/GenericMappingTools/pygmt/releases)
- [Changelog](https://github.com/GenericMappingTools/pygmt/blob/master/doc/changes.rst)
- [Commits](GenericMappingTools/pygmt@0.0.1a0-77-g4581a3e...v0.1.1)

Finally, with this proper pygmt version, we can get rid of a few of my thin wrappers (e.g. blockmedian, grdtrack, grdview) that have since made it into pygmt! Will do so in separate commits. Only made a small edit here to the xyz_to_grid function as pygmt.surface now returns an xarray.DataArray since GenericMappingTools/pygmt#408.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

grdtrack/surface/others?, incompatible data types
2 participants