PyGMT: A Python interface for the Generic Mapping Tools · Issue #43 · pyOpenSci/software-review

• Read original article here

Education
Unsure/Other (explain below)
Explain how the and why the package falls under these categories (briefly, 1-2 sentences). Please note any areas you are unsure of:
Data munging
⚙️
: Several data processing modules are available to work on tabular and grid data ( https://www.pygmt.org/v0.4.0/api/index.html#data-processing ) including functions like blockmedian, surface, grdtrack, etc
Data visualization
????️
: Plotting publication quality maps and figures is a strong point of PyGMT ( https://www.pygmt.org/v0.4.0/api/index.html#plotting ). There is a comprehensive set of tools for plotting 2D and 3D data, both geospatial and non-geospatial. It is also possible to add standard map elements like a colorbar or legend, and make multi-panel subplot figures.
Geospatial
????
: PyGMT is inherently a geospatial package that can handle both vector and raster data. Several map projections are supported ( https://www.pygmt.org/v0.4.0/projections/index.html ), and there is support for plotting shapefiles and GeoTiff/NetCDF files.
Who is the target audience and what are scientific applications of this package?
The primary target audience of PyGMT is the geoscience community, including anybody working on fields like Earth Observation, Geophysics, Oceanography, Seismology, Planetary Sciences, etc. The package offers a way for users to perform general geoprocessing tasks and create high quality illustrations of their results for posters or publications.
Are there other Python packages that accomplish the same thing? If so, how does yours differ?
Yes, there are several geospatial Python packages such as:
cartopy for plotting vector data ( matplotlib based)
geopandas for working with vector data
rasterio , rioxarray and xarray-spatial for working with raster data
These tools are typically focused on one thing only (e.g. plotting maps, vector data, raster data). PyGMT allows users to mix vector and raster data easily, so that users can:
Produce a map with points/lines/polygons and raster grids in the same plot, e.g. plot weather station points on top of a raster Digital Elevation Model, while including map elements (e.g. scalebar, compass arrow, colorbar , legend , inset overview maps etc)
Extract a series of elevation values along a transect line (vector) from a NetCDF/GeoTiff grid (raster) using grdtrack
Convert a table of xyz points (vector) to a 2D grid (raster) using surface via a spline-based interpolation method.
PyGMT integrates with the PyData ecosystem. It allows users to process and plot data stored in NumPy arrays, Pandas DataFrames, Xarray DataArray/Datasets, GeoPandas GeoDataFrames, as well as from standard file formats like CSV and GeoTiff/NetCDF files. There are also plans to integrate with other scientific libraries like ObsPy (
ObsPy integration GenericMappingTools/pygmt#967 ) in the future.
However, PyGMT can only produce static plots unlike packages like Geoviews which allow for interactive plotting (e.g. panning and zooming). It is also non-trivial to scale out data processing tasks and/or plotting of big datasets (>10GB) that don't fit in RAM to multiple processors/clusters as with libraries like dask-geopandas because of limitations in the GMT C package that PyGMT wraps around.
Any other questions or issues we should be aware of?:
First off, thanks for reading this! We're keen to get some independent reviewers to have a look at the PyGMT package, sort of as a first step before going for a software publication at JOSS/G3 (the team is still deciding). Linking to original discussion at
I finally found some time (and sleep) after Scipy, and have reviewed the changes here.
Big thanks for all the developers for the many changes made in response to my review.
The only thing I noticed was that there are still a few checkmarks missing in GenericMappingTools/pygmt#1686 , but given the record of development I have seen here, I am confident these will be addressed soon (so no need to request another review period from my end).
I did check the packaging guide and found that this package exceeds all the requirements.
So from my end this is a go on publication
????
.
PS: This was such a pleasure to review, I wish science journals would enable a workflow even close to this!
????
Hi @weiji14 , @leouieda , @lwasser , @jbusecke !
I had mostly propositions of improvements (more Python, less GMT), and I've checked all linked resources (projects and discussions) - I think that we are on the same page, and this is what I was looking for. I agree, that classes could be better data structures to pass "Pythonic" parameters into drawing functions (instead of dictionaries).
Your new training materials from here are excellent, and it is good to see that the package is developed as a project with the future and you build a healthy ecosystem around it.
I've updated my review points too, and from my perspective, you are ready for the next publication steps! Thank you for your tremendous work and a lot of effort put into the promotion :)
????
Thanks @lwasser and all the reviewers! Just want to quickly acknowledge that we're delighted with the news, and it's been a pleasure to have such a nice open review process
????
In terms of next steps, we've got Zenodo set-up already at https://doi.org/10.5281/zenodo.3781524 (since v0.1.0 in fact), so you can tick the first 2 boxes. I'll submit PRs for the other 3 checkboxes soon (once I get some free capacity).
For the JOSS submission part, let me get back to you on that once the team has a chat on GenericMappingTools/pygmt#677 (comment) . Just to understand the expedited process though (as I'm a little new to JOSS), would the JOSS review just be focused on the software paper itself and not the code/documentation? I had a look at https://www.pyopensci.org/contributing-guide/open-source-software-submissions/author-guide.html#journal-of-open-source-software-joss-submission which mentions writing a paper.md file, but not sure if there's anything else needed.
All reactions
????
Regarding JOSS - that step is actually straight forward.
First you will need to create the paper.md file which is probably the most time consuming part of the process. I can have a look at that before you submit if you wish but they will review it and use their whedon bot to double check format, etc.
As far as the review, because we are partners with JOSS they accept our review for their process. Thus you do NOT have to go through another review. But you WILL get the cross-ref enabled DOI from them which if nice for your team to have as it will show up automagically in Orcid, etc. When / if you go through their review process please include a link to this issue / review and tell them you can be fast tracked as you've been accepted already to pyOpenSci. Ping arfon if you wish on this step. That's it.
So in short what you read is just it - you write the paper and the rest of the review process is super speedy as you've already been peer reviewed here.
Please let me know if you have any other questions about the process. And welcome again to pyOpenSci!
All reactions