PyGMT Community Meeting Jun 27 (UTC 19:30)

The PyGMT folks had their first informal meeting on 27 Jun 2020 (UTC 19:30), mainly to talk about the Scipy 2020 sprint, but we also touched on other long term plans. These are the meeting minutes:

Participants: Dongdong, Leo, Liam, Wei Ji


  1. Scipy 2020 Sprints
  2. Conda-forge weekly GMT builds
  3. Remote Online Sessions for Emerging Seismologists (ROSES) module
  4. PyGMT as a high-level Pythonic API for plotting geographic data
  5. Postdoc from NSF funding


  • Prepare for multiple ability levels
  • Beginner only for Scipy 2020
    • Gallery examples - Make it easy for folks to contribute
    • grdview/grdimage/grdtrack example
  • Open issues with tag ‘Scipy 2020’ for people to work on.
  • Bugs to be fixed prior to sprint
  • Be aware of GMT 6.1.0 compatibility
  • Pin to GMT < 6.1.0 so people don’t upgrade? Or tell users to conda install gmt=6.0
  • API changes fixed in GMT master branches, mostly ok in PyGMT but need to confirm
  • GMT and PyGMT advance in sync, e.g. GMT 6.0 = PyGMT v0.1.x, GMT 6.1 = PyGMT v0.2.x
  • Scipy sprints very informal, at least in person (the 2017 one), people might just show up? Not sure about online, be on toes.
  • Find a PR that was merged, and use as an example to newcomers on what to expect with the review process
  • Manage expectations on people’s git/github experience
  • Give Liam access to label stuff on PyGMT repo and as forum moderator
  • Managing discussions during sprint
    • Use GMT forum as discussion board
    • Zoom/Slack/Gitter chat for informal conversation
    • Github for bugs or how to implement something new e.g. a wrapper

Conda weekly GMT build

  • Ensure changes in GMT don’t break PyGMT, also good for other GMT/GMT.jl/GMTmex users
  • Also nice to put in try-gmt repo at, have stable GMT 6.0, and also unstable GMT master
  • Filipe not on board of maintenance, very busy person
  • Docker image? Maybe better to compile on conda CI as compilers there support conda-forge ecosystem better
  • Could be a weekly CI job that compiles GMT. Not a problem if it only happens once a week and takes a long time.
  • Linux/macOS priority. Windows, if requested


  • Early August
  • Slack organization with 173 members, massive Zoom meetings
  • Obspy workshop on Jupyter notebooks with breakout sessions
  • Good opportunity for visibility
  • Get some material from FOSS4G 2019 at
  • Tie in ObsPy with PyGMT, get a waveform/station map, and start plotting that, look at Slack where they have modules on everything? Students like it when we tie topics together
  • Mention about GMT modules that are not wrapped yet in PyGMT, for those seismic students that have used GMT in grad school, access using lib.call_module?
  • Demand is high, 500 students in one cohort?
  • Make good use of Teaching Assistants? 1 hour lecture + 1 hour lab. Have someone keeping an eye on the chat
  • Specific stuff, e.g. new Python users, people not familiar with grids or projection systems

PyGMT as a high-level Pythonic API for plotting geographic data

  • Should we keep functions/Method names exactly the same in GMT as PyGMT?
  • Things grew to be different flags in one function, e.g. -B flag in GMT is large, instead of having more discrete functions that do one thing and one thing only
  • E.g. Coast can write coastline to files, not just plot coastlines
  • E.g. blockmode/blockmean can output table and grids
  • Maybe try not to be just GMT in Python, don’t be restricted by the namespace
  • Emulate good parts of Matplotlib/GMT, but we can do things differently, long term stuff
  • Name-wise, do we cater to users coming from GMT, or from Matplotlib, or from Cartopy?
  • What is the geoscience plotting library that we want to be?
  • Object orientated projection structure of Cartopy, see PR on Projection classes at
  • Interactivity in PyGMT, e.g. zooming into plots. NASA worldwind example Leo did a while ago broken quite often
  • GMT was designed for print, publication figures
  • Use analogy of Adobe Illustrator, layered on layered
  • Multiple levels of API? Matplolib has that, object orientated stuff and pyplot. Want to avoid that, don’t build a lot of stuff we don’t want to support later
  • Be more strategic on what we can do in Python, could be more than GMT or Matplotlib
  • Lib.call_module -> can put in data easily, but pulling data out using Tempfiles is tricky
  • Look at gmtmex/GMT.jl which handles data IO transparently
  • GMT C API - a deep rabbit hole


  • Postdoctoral position in GMT software development
  • Up to 3 years funding?
  • Is she/he going to work on GMT/PyGMT? What is her/his allocation of time between the different projects
  • Quite flexible, but help work on base GMT, and if know python, then could help out with the Python side
  • Help review entire GMT code base, even Joaquim with 15 years on GMT and he doesn’t know everything
  • Work with Paul to refactor/restructure the API, somehow

Great! A few comments:

  • GMT C API - a deep rabbit hole

He-he. I have a red pill and a blue pill for you - choose wisely.

Postdoc is 3-years. Their allocation time to GMT/PyGMT should be flexible and depends on skill set. I imagine the GMT team will discuss this once we select the winner. I can imagine that person would want to do Python stuff and not be down in the bunker with me.

Well, but we really want someone who can do the C part down in the bunker. The new visa restrictions will definitely be a blunder.