P.S. We’re going to have a pop-up networking event on Wednesday 25 May 2022 at 17:00 UTC/19:00 CEST/ 13:00 EDT. Edit: event over, thanks everyone for joining!
Really great, thank you. I’ve never used PyGMT and this was a really nice intro.
Two questions:
I’ve been using GMT from the terminal/shell since I first was introduced to it; are there any good reasons why I should leave the shell and start using PyGMT instead? Is it a matter of taste? Does PyGMT offer something more (excluding the whole python ecosystem of course) than simply another way of doing things, preference?
In this video, PyGMT is said to be able to read Well-known text /geometry. How does it do that? Native GMT can’t do that, right? Geopandas?
Thanks for the kind words @Andreas. To answer your questions:
PyGMT is just a wrapper around GMT, and it’s meant to integrate better with the Python ecosystem (so instead of calling GMT via subprocess in Python, it’s better to use PyGMT instead). Specifically things like numpy arrays, pandas dataframes, xarray DataArrays, geopandas GeoDataFrames, and potentialy more things like ObsPy (ObsPy integration · Issue #967 · GenericMappingTools/pygmt · GitHub) if people work on it. There are long aliases/parameters e.g. region for -R, and the interface is meant to be more user-friendly to people who haven’t used GMT before.
In terms of features. If GMT is 100%, GMT.jl would be >95%, PyGMT might be at >80%. If a module isn’t wrapped, PyGMT does have a C API interface via API Reference — PyGMT to cover just about anything GMT can do, but that is more for advanced users. So yes, it’s really just a matter of preference on what programming language you use.
Yes, that would be done through GeoPandas in PyGMT. So GeoPandas being the I/O layer to read in the data, and then PyGMT would be able to plot or process data from the geopandas.GeoDataFrame object. Theoretically, this also means that anything GeoPandas can read such as postgis databases, geoparquet, flatgeobuf, feather, etc can be used in PyGMT as well (though I haven’t tested these), though this is really just going through OGR and GMT C does have support for shapefiles and such.
Julia calls whatever public GMT function it wants and GMT has functions to read OGR natively that are not possible to access via shell scripts because there is no C interface for exporting OGR data. But GMT.jl has functions to do such interface. Now, sending in OGR data, namely WKT, depends on if C core understands it or not and it only understands it in the extent that PROJ4 is understood.
Well, I have a somewhat different view here. If GMT = 100% then GMT.jl > 130%. It extends GMT with quite a lot of functionality (e.g.contourf, pcolor, sreamlines, triplot, extended ternary plots, an almost full GDAL interface, etc…, ability to receive data back in memory to Julia (like the MEX). And going back to WKT, sometimes GMT might not understand it but then there some method from the GDAL+PROJ+GEOS pool that can do that part of the job. And all that called from the GMT.jl wrapper.
This is one of the main objectives of both wrappers. And after a little while even the experienced users get attached to that as well.
and doing geospatial data processing 
with PyGMT at EGU22!
Jupyter Book website: https://www.generic-mapping-tools.org/egu22pygmt
Official session and 1h30min video (requires EGU22 registration): CO Meeting Organizer EGU22
Yoube playlist: https://www.youtube.com/playlist?list=PL3GHXjKa-p6VBA_MlUP7T_ByCFYQZ5uDG
GitHub repo: GitHub - GenericMappingTools/egu22pygmt: Crafting beautiful maps with PyGMT at EGU22
P.S. 
is now live on 
