EGU22 Crafting beautiful maps with PyGMT short course

Announcements
#1

Hi everyone, we’re excited to showcase this short course for producing maps :world_map: and doing geospatial data processing :globe_with_meridians: with PyGMT at EGU22!

image

The short course is 1hr 30min long and includes the following:

  • Introduction by @weiji14 (7min)
  • Anatomy of a PyGMT figure by @leouieda (22min)
  • Integration with the scientific Python ecosystem by @maxrjones (16min)
  • Making some Mars maps with pygmt by @andrebelem (20min)
  • LiDAR Point clouds to 3D surfaces by @weiji14 (25min)

:open_book: Jupyter Book website: https://www.generic-mapping-tools.org/egu22pygmt
:point_right: Official session and 1h30min video (requires EGU22 registration): https://meetingorganizer.copernicus.org/EGU22/session/43186
:film_projector: Yoube playlist: https://www.youtube.com/playlist?list=PL3GHXjKa-p6VBA_MlUP7T_ByCFYQZ5uDG
:information_source: GitHub repo: https://github.com/GenericMappingTools/egu22pygmt

image

:loudspeaker: 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!

image

Details at https://webforms.copernicus.org/EGU22/pop-up-networking-events.
Zoom link for the event is https://osu.zoom.us/j/95307015056?pwd=RnVIWElvRXcybko1ck5RVGlxRUhOdz09

3 Likes
#2

Hi
are people outside the conference eligible to have access to this course?

#3

The Jupyter Book website is available to everyone, and we’re working on getting the videos uploaded to Youtube soon (see https://github.com/GenericMappingTools/egu22pygmt/issues/17).

1 Like
#4

The Youtube playlist :video_camera: is now live on https://youtube.com/playlist?list=PL3GHXjKa-p6VBA_MlUP7T_ByCFYQZ5uDG. Enjoy everyone :partying_face:

3 Likes
#5

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?
#6

Yes, it can. But guess how.

#7

Julia…?

#8

:clap:

#9

But is Julia native GMT? Why can’t I feed wkt/geometry to gmt in my shell scripts?

#10

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 (https://github.com/GenericMappingTools/pygmt/issues/967) 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 https://www.pygmt.org/dev/api/index.html#gmt-c-api 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.

2 Likes
#11

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.

1 Like
#12

Thank you @weiji14 and @Joaquim for great answers!