# PyGMT as a high-level API for Geovisualization **URL:** \ **Category:** Lounge\ **Created:** [June 28, 2020, 12:21am UTC](https://forum.generic-mapping-tools.org/t/pygmt-as-a-high-level-api-for-geovisualization/590 "2020-06-28T00:21:30Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![weiji14](https://yyz1.discourse-cdn.com/flex047/user_avatar/forum.generic-mapping-tools.org/weiji14/32/33_2.png) [@weiji14](https://forum.generic-mapping-tools.org/u/weiji14)\ **Post date:** [June 28, 2020, 12:21am UTC](https://forum.generic-mapping-tools.org/t/pygmt-as-a-high-level-api-for-geovisualization/590/1 "2020-06-28T00:21:30Z")
Should PyGMT just be a wrapper for GMT, or could it be something more? Where should we sit in the [Python Data Visualization Landscape](https://www.anaconda.com/blog/python-data-visualization-2018-why-so-many-libraries)? ![Python Data Visualization Landscape 2018](https://canada1.discourse-cdn.com/flex047/uploads/gmt/original/1X/2c3a27a1b07416c7c55da357bdcb3738ca41c364.jpeg) This was a point raised in [PyGMT meeting #1](https://flint.soest.hawaii.edu/t/pygmt-community-meeting-jun-27-utc-19-30/589/3) (thanks again @leouieda for articulating your thoughts!), and also as at [comment on Github](https://github.com/GenericMappingTools/pygmt/pull/427#issuecomment-646983555) 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](https://xkcd.com/927)). To start, I’m actually a big fan of high level plotting libraries like [HvPlot](https://hvplot.holoviz.org/) (which uses [Bokeh](https://bokeh.org/) as it’s backend) and [Altair](https://altair-viz.github.io/) (which uses [Vega-lite](https://vega.github.io/vega-lite/) as its backend). These are the two fundamental types of ‘plotting’ API styles: - Imperative/Object orientated style: - Declarative style: 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: - [Anaconda | Python Data Visualization 2018: Why So Many Libraries?](https://www.anaconda.com/blog/python-data-visualization-2018-why-so-many-libraries) - [The reason I am using Altair for most of my visualization in Python — Fernando Irarrázaval](http://fernandoi.cl/blog/posts/altair/) - [A Dramatic Tour through Python’s Data Visualization Landscape (including ggplot and Altair) – Dan Saber](https://dsaber.com/2016/10/02/a-dramatic-tour-through-pythons-data-visualization-landscape-including-ggplot-and-altair/) - [Redirect](http://blog.pyviz.org/pyviz-scipy-bof-2019.html) ---
**Author:** ![leouieda](https://yyz1.discourse-cdn.com/flex047/user_avatar/forum.generic-mapping-tools.org/leouieda/32/2134_2.png) [@leouieda](https://forum.generic-mapping-tools.org/u/leouieda)\ **Post date:** [June 29, 2020, 3:49pm UTC](https://forum.generic-mapping-tools.org/t/pygmt-as-a-high-level-api-for-geovisualization/590/2 "2020-06-29T15:49:24Z")
@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”. ---
**Author:** ![Joaquim](https://yyz1.discourse-cdn.com/flex047/user_avatar/forum.generic-mapping-tools.org/joaquim/32/16_2.png) [@Joaquim](https://forum.generic-mapping-tools.org/u/Joaquim)\ **Post date:** [June 29, 2020, 4:06pm UTC](https://forum.generic-mapping-tools.org/t/pygmt-as-a-high-level-api-for-geovisualization/590/3 "2020-06-29T16:06:40Z")
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. ---
**Author:** ![weiji14](https://yyz1.discourse-cdn.com/flex047/user_avatar/forum.generic-mapping-tools.org/weiji14/32/33_2.png) [@weiji14](https://forum.generic-mapping-tools.org/u/weiji14)\ **Post date:** [June 29, 2020, 9:47pm UTC](https://forum.generic-mapping-tools.org/t/pygmt-as-a-high-level-api-for-geovisualization/590/4 "2020-06-29T21:47:57Z")
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](https://github.com/holoviz/hvplot/issues/480#issuecomment-650832779), 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](https://github.com/GenericMappingTools/gmt/pull/3513) and [here](https://github.com/GenericMappingTools/gmtserver-admin/pull/62)), and it would be nice to tie that in with [Fabio’s Scientific Colourmaps](http://www.fabiocrameri.ch/colourmaps.php) (e.g. have seismic=“roma”, topography=“oleron”, etc).