PyGMT as a high-level API for Geovisualization

Lounge
1

Should PyGMT just be a wrapper for GMT, or could it be something more? Where should we sit in the Python Data Visualization Landscape?

Python Data Visualization Landscape 2018
Python Data Visualization Landscape 20181200×877 182 KB

This was a point raised in PyGMT meeting #1 (thanks again @leouieda for articulating your thoughts!), and also as at comment on Github about not repeating matplotlib’s mistakes (i.e. having both an object oriented API and functional pyplot API). It’s really easy for us to just copy an existing implementation without giving thought to how it could be built from scratch, so let’s explore a ‘ground-up’ way of doing things (though we’ll run into xkcd: Standards).

To start, I’m actually a big fan of high level plotting libraries like HvPlot (which uses Bokeh as it’s backend) and Altair (which uses Vega-lite as its backend). These are the two fundamental types of ‘plotting’ API styles:

  • Imperative/Object orientated style:

    • I.e you instruct the computer what to plot step by step, think Assembly language
    • Full control and compositionality but complex and highly verbose for some common tasks like creating subplots
    • E.g. matplotlib’s object oriented/pyplot API, and arguably what PyGMT v0.1 is right now

  • Declarative style:

    • I.e. you instruct the computer what plot you want to get, and it figures out how to do it. think SQL
    • Arguably more user friendly (though maybe not developer friendly), and easier/faster to get to a complicated plot
    • E.g. Declarative graphics APIs: Altair’s “Grammar of Graphics”, or ggplot2 in R
    • E.g. Declarative data APIs: E.g. Hvplot, Holoviews, Geoviews

Yes, there are limits to what we can do with using GMT as a backend, e.g. interactive plots you can ‘zoom’ in on. But given that PyGMT is still a young project, it’s worth considering what we want the API to look like going forward before things get too sticky to change.

References:

1 Like
2

@weiji14 I also quite these libraries. But I feel like these grammar of graphics libraries wouldn’t be a good fit for PyGMT. That style is not well developed for grids and maps, which is a huge part of our “market share”.

3

Confess that I don’t understand the “grammar of graphics”. It requires that you are a programmer (and one to inclination to that vocabulary) to make a plot.

But obviously I’m wrong because many people like it.

4

Yes, I don’t expect us following a “grammar of graphics” route, though that doesn’t mean we can’t test out the declarative data style (ala Geoviews). The dream would be to have a “GMT” backend in HvPlot, but reading this comment, it seems like a lot of hoops to jump through. We can at least learn from those examples though. Our advantage is that we can build something from the ground up catered specifically for the Earth Sciences, rather than ‘geo’ being just an afterthought.

That said, a “grammar of graphics” would be an interesting piece of research. I know GMT is working on a default CPT for different grids (see Github PR here and here), and it would be nice to tie that in with Fabio’s Scientific Colourmaps (e.g. have seismic=“roma”, topography=“oleron”, etc).

1 Like