Create vs30 grids from a GMT module
Opened this issue · 2 comments
Hi, one of the core GMT developer here, a geophysicist but not a seismologist.
A bit of context first. A couple years ago colleagues from the Portuguese “Geophysical Service” asked me to rewrite their home custom code into a GMT-aware module. And so I did.
Meanwhile, time has elapsed and I saw you Vs30 gridding procedure and thought. Heck, this shouldn't need to be so complicated in GMT6 (especially since I’m a Windows user). So (a year or two ago) I made a GMT module to compute the Vs30 grids that relies only on GMT. But, since the GMT developers are not really seismologists (well, we have one but he is not so familiar with this subject), we would like to ask about your interest in this module you may or may not have, feature requests included.
The module in question currently lives in the GMT’s “shakemap” branch (https://github.com/GenericMappingTools/gmt/tree/shakemap) and the module is called “vs30”. It comes with a basic manual (vs30.rst) as well as typical GMT online help. We also have a potential "shake" modules as well for computing peak ground acceleration/velocity and intensity. We believe there are many US seismologists who would be interested in having these modules as part of GMT, despite your own (more feature reach) python codes available from the USGS.
We would like to know if you may have an interest in such a module and, in particular, if you would be willing to test it against your own code.
Hi Joaquim,
Sorry, we're not ignoring you, but a lot of us are on use-it-or-lose-it leave. Your proposal seems interesting but we need some time to review it and think about where we're going with this Vs30 project. Hopefully we can talk next week and start a discussion with you about what direction to take.
Just to give you a little background, we're also working on other global datasets that may have varying resolutions. For instance things like water table depth and other factors that may influence landslides and liquefaction. Some of these features may be "known" to 250m or even 100m resolution in some places, but are poorly constrained in many other places. One approach we started to explore was something like a quad-tree mesh to handle the varying resolutions.
Ultimately, we'd like to find a single solution for Vs30 and other parameters that allows us to create a mosaic of higher and lower resolution data with better and worse constraints, and to carry the uncertainty along with the data.
Obviously, we're already GMT based, so your ideas are very interesting to us.
Bruce
Bruce, thanks for the update.
We have a quad-tree aproach in grd2kml that may be of some use but know little about it. It was @PaulWessel who wrote that program alone.