Should PyGMT just be a wrapper for GMT, or could it be something more? Where should we sit in the Python Data Visualization Landscape?
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 https://xkcd.com/927).
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 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.