search

uafgeotools / rtm

A Python package for locating infrasound sources using reverse time migration
https://uaf-rtm.readthedocs.io/
MIT License
38 stars 13 forks source link

Use PyGMT for plotting #23

Closed liamtoney closed 4 years ago

liamtoney commented 4 years ago

PyGMT could vastly improve the quality of maps output by rtm. It doesn't have a conda release yet, but that's in the works. In contrast, cartopy development seems slower. I may make a branch which uses PyGMT instead of cartopy.

davidfee5 commented 4 years ago

I'd second this and up the priority. Cartopy is very frustrating to work with...

liamtoney commented 4 years ago

The PyGMT branch is now viewable here.

liamtoney commented 4 years ago

FYI the GMT team was just awarded an NSF grant to strengthen GMT, including developing Python wrappers etc. — this is good news for the [funded] future of PyGMT! Excerpt:

These improvements will address [...] development of GMT-powered software libraries in other languages (Python, MATLAB, Julia) [...] so that GMT may continue to be maintained and evolve in a changing computational landscape.

liamtoney commented 4 years ago

With PyGMT now available for install via pip, I have completed the jump from cartopy to PyGMT, and ensured that installation of rtm with PyGMT and GMT is straightforward. I think we should consider committing to PyGMT soon, if not now!

weiji14 commented 4 years ago

There's a conda package for pygmt too by the way, it's at https://anaconda.org/conda-forge/pygmt.

If you need the FONT config functionality soon, I could merge in https://github.com/GenericMappingTools/pygmt/pull/411 and maybe get a 0.1.1 bug fix release out. Or you can wait longer until the subplot functionality is done in 0.2.0 :smiley:

liamtoney commented 4 years ago

If you need the FONT config functionality soon, I could merge in GenericMappingTools/pygmt#411 and maybe get a 0.1.1 bug fix release out. Or you can wait longer until the subplot functionality is done in 0.2.0 😃

Thanks, Wei Ji! The FONT config stuff is pretty minor in the context of our code actually. The workaround is simple. So no need to rush anything for us. :stuck_out_tongue_closed_eyes:

Right now we're just trying to figure out how essential interactive plotting (panning, zooming, data cursor, etc) and user manipulation of automatically generated figures (setting axis limits, etc.) are to our target users. These are (to my knowledge) only feasible with Matplotlib/cartopy.

For example — say a user wants to programmatically set "tighter" axis limits on a PyGMT map to zoom in on a particular feature of an automatically-generated figure. In Matplotlib this would at most be e.g.

ax = plt.gca()
ax.set_xlim(...)

but for PyGMT, we must re-create the figure from scratch, correct? Since the PostScript has already been written. The best solution I can think of is simply including axis limit kwargs in our plotting functions... have you thought about this at all in the context of DeepBedMap?

weiji14 commented 4 years ago

Thanks, Wei Ji! The FONT config stuff is pretty minor in the context of our code actually. The workaround is simple. So no need to rush anything for us. stuck_out_tongue_closed_eyes

Ok, I'll wait for more bugs to show up first :smile:

Right now we're just trying to figure out how essential interactive plotting (panning, zooming, data cursor, etc) and user manipulation of automatically generated figures (setting axis limits, etc.) are to our target users. These are (to my knowledge) only feasible with Matplotlib/cartopy.

In terms of interactive plotting, it sounds like geoviews would do what you want (they use Cartopy as a backend). There was some interactivity in pygmt before (see @leouieda's demo during the Scipy 2018), but that was dropped in https://github.com/GenericMappingTools/pygmt/pull/275. So it's theoretically possible with GMT somehow?

For example — say a user wants to programmatically set "tighter" axis limits on a PyGMT map to zoom in on a particular feature of an automatically-generated figure. In Matplotlib this would at most be e.g.

ax = plt.gca()
ax.set_xlim(...)

but for PyGMT, we must re-create the figure from scratch, correct? Since the postscript has already been written. The best solution I can think of is simply including axis limit kwargs in our plotting functions... have you thought about this at all in the context of DeepBedMap?

Having a matplotlib-like syntax would definitely be ideal since it's the de-facto standard in Python. I've been look at some matplotlib demos and thinking about how to mimic their style as I wrap the subplot module. It sounds like we could learn a bit from what the SHTOOLS library is doing (see e.g. https://shtools.github.io/SHTOOLS/pages/mydoc/notebooks/Introduction-4.html). My DeepBedMap paper figures just used nice round numbers for the axis limits, and you don't really want to 'zoom in' onto static raster plots without re-rendering otherwise they look pixelated. The vector objects might be okay though? I'm actually not super familiar with how postscript works.

liamtoney commented 4 years ago

It sounds like we could learn a bit from what the SHTOOLS library is doing (see e.g. https://shtools.github.io/SHTOOLS/pages/mydoc/notebooks/Introduction-4.html).

Agreed, we'll look there to see how PyGMT is integrated. Thanks, Wei Jei!

liamtoney commented 4 years ago

Removed the pygmt branch as lack of interactivity is a deal-breaker. We can still use internal code for paper figure creation.