Developer Summit Aug. 15-19, 2016 at Scripps

This is the unsorted list of action items that the developer discussed and made recommendations on. The current status or action is written in italics. Most of these actions pertains to future version 5.4 but a few will be considered bug-fixes in 5.3.x.

  1. New module: gmtfft. Like grdfft but for tables. Allow filtering and other spectral calculations. Should be done in 5.4.
  2. New module: grd2sph: Complement sph2grd, and long overdue. Nobody on team needs it and it is a large task; task for postdoc depending on talent, for 5.4.
  3. Revise module: surface (new transposed version); mask option? Paul will do more testing and present results, target 5.4.
  4. New options: sample1d or trend1d or filter1d: smoothing spline? Sinc interpolation? Yes, check Walter’s code to see how to fit it in 5.4.
  5. Spectrum1d: NxN cross-spectral and option to do ensample averaging vs Welch’s method. Walter would like this. Lead?
  6. Blockmean: Add option –A<alpha> to do Tukey 1- mean via a call to GMT_blockmean. Fairly easy to do, target 5.4.
  7. Variable grid spacing [OLD 2011 summit item]. Explore x(col), y(row) extension.
  8. Convex hull calculation [OLD 2011 summit item]. Later/Winter, do some research.
  9. Kriging [OLD 2011 summit item]. Write an exposition (white paper) first to highlight issues.
  10. Clipping of finite-width lines ending at border: When we determine that a line exits the region we clip it. But when it is rendered it looks chopped off unless exiting normal to the border. Same applies to circles and symbols, see clipping* tests in test/psxy. Explore this change: (1) Instead of clipping array to include point exactly at boundary, just draw to the next data point and stop there. (2) Consider fat pens as polygons. 3) Google to see how this problem has been solved already.
  11. Policy of posting fuller issue messages, with documentation. No action listed?
  12. Best way to run GMT on Windows? Cygwin vs Mingw? We need a statement on the page with options and our recommendation.
  13. Fast updating: gmt –update? Windows only. Needs more groupthink.
  14. GSA GMT Workshop June 2017. Opportunity for using GMT/MEX toolbox in a workshop. Information only.
  15. Interoperability: Given Caress’ presence discuss a broader adoption of the API for the MB-modules. A clear advantage of this would be MB access from external interfaces (Mirone already does a bit of that via a modularized mbswath). In progress; gmt-config now displays plugin dir for MB installer to copy
  16. Extend the GDAL interface via librarified GDAL executables. The whole ensemble of GDAL algorithms are within our reach now. JL and PW will do some homework on this.
  17. Dave (Sandwell) might be particularly interested in SAR formats via GDAL (there are several messages on GDAL mailing list about this). Somebody energize Dave?
  18. How to infiltrate more into GDAL users land? I regularly see questions on GDAL lists that are easier to do with GMT than resorting to python scripts. Await Python module.
  19. What about Martin Jacobsson and his multi-resolution gridding efforts (pyramid spline)? Rediscover the problem (if any) and do or don't do, there is no try.
  20. Deal with longitude adjustment when writing to memory (i.e., mex) for tables. By Friday!
  21. Revitalize the FORTRAN API; try to recruit interested developers. Remko will resurrect/test/ + F95 interface.
  22. Redo how backwards compatibility is implemented: Cast old options into new and parse with new parser only. E.g., -D for psscale, pslegend, etc. Identify where we have two parsers (-B, -D, -T, etc.) and redo the design by converting old syntax to new syntax and use a single parser.
  23. Re-categorize our examples in terms of simple to complex or by category. Expose examples via different paths, e.g., Chronological, Thematic (1-D/2-D, surfaces, time-series, processing, supplements), Simple-to-Complex, Statistics, etc.
  24. Help Samantha Zambo with developing new tools [she is on Windows]. Joaquim takes the lead.
  25. Ability to write PDF (or image) directly. We would need a new –z option to specify final output file via call to gs. Remko will write proposal for discussion. This is 5.4.
  26. Least-cost paths extraction of features (ridge-lines, valleys). Exists in GRASS. JL has C-code used in Mirone for this. Would be a supplement not core, so need a willing developer. Perhaps issue calls for new supplements and what they should do.
  27. Complex grids (e.g. SLCs)? Should this be supported? How? I.e., grdmath operations. Simplest situation would be to add modifier to input filename to specify a conversion from complex to amplitude, phase, real, imag, i.e., just return a single layer grid. No complex file format yet. Start by adding Complex operators like CMUL, CADD, etc, to grdmath for starters.
  28. Enable double-precision internal grids via typedef GRID_REAL float | double. Carefully replace float in the context of grids with GRID_REAL, test, default to float in Cmake config. Florian stared with CMake. Paul will modify use.
  29. Use geo-vector for grdvector plots on maps. Also, can we derive curvatures to do curved flow-line vectors? Paul will talk to Clint to determine need.
  30. Speed up GMT_Get_Record via function pointer for different cases. Currently too slow for bad design reasons. Complete this in 5.3.1.
  31. Add web form to assist users setting up their ConfigUser.cmake file. Start by making the current Template more user friendly. Follow JL’s short script example.
  32. Reach out to USGS ShakeMap to help improve their plots? Rediscover who the guys is and ask what we can do to help.
  33. Rename meca to seismo? What about pssac tool? Feedback from a seismologist: “I was a fan of pssac before I moved to GMT 5. It is not very difficult to plot single trace/seismogram with psxy or pswiggle. But it is very easy to plot a record-section (multiple traces in order of distance/azimuth/index) with pssac.  In that case, we don't need to convert sac file into ASCII file and calculate shift of each trace. Maybe that is why it is very popular in seismologist community. “ Paul will follow up with Zhang.
  34. Column header, comments, history etc. records for data tables (–h+c, etc.) not working. Paul will summarize and clarify what the problem is.
  35. Should gmt –X print out help usage for option –X? We will explore for 5.4.
  36. When a user specifies an annotation interval with –B and it implies a gazillion annotations we should at least warn the user that this is bad. Consider adding a warning if dx = <map width>/<n_ticks> << Pen-width.
  37. Add velocity correction option to segy2grd? Get request via Dan B and Check with Tim Henstock.
  38. Enhance shading options in grdgradient as per Caress’ requests. Better explain how illumination works, pre/post map-projection and why. Do some research first. Invite Andreas to join us in developing/documenting according to his ability. Possibly leading to a new module grdshading.
  39. Restructure our online documentation, perhaps separate Appendices from main stuff, etc. To be continued.
  40. Decide on and purchase blade server. Consider off-site/ITS backup service?
  41. Add a gmt animate module to set up generao-purpose animation scripts? Paul will develop prototype.
  42. Can we use something like GIS Stack-exchange? Proprietary?
  43. Discuss EarthCube GMT proposal with Louise Kellog. Paul will check with Dave as well.
  44. Establish web traffic for gmt4 vs gmt5 using SOEST servers. Paul will investigate.
  45. Use undergraduate student to harvest test script examples to update man pages. Paul will hire undergrad but probably Jan 2017 due to travel.
  46. Let mgd77 tools obtain data from NGDC via URLs – to avoid people having to recreate entire data libraries. Feedback to Dietmar – could they help with this?
  47. Spherical gridding (sphinterpolate) fails, apparently? Need more testing at the very least. PW: EarthByte says they’ve tried lots of cases with no luck. News to me. Fixed bug in –Q0; investigate Q1 problem with outliers; there are still issues.
  48. A better way to work with publicly available multibeam bathymetry data - in particular, all the raw data files available through the NGDC repository, which are in a not-that-convenient format. As far as I know the best open-source solution is MB-system, which can be tricky to compile and seems to largely use GMT anyway, it would be much easier if there was a GMT supplement package that read these data (just like the x2sys and mgd77).” See plugin.
  49. Let the mgd77 supplement have a way to obtain/query NGDC data availability?” See item above (NGDC)
  50. A way to use x2sys commands that accessed the trackline data via a web request to a repository (rather than having to have ~12 Gb of data in your machine and have to update it manually).” See item above (NGDC)
  51. One thing that has always annoyed me (at least in older versions) occurred when you do something like a grdproject with -I<sampling>=, with the = specified to force the sampling to be a nice round-numbered value. It seemed to ignore me and make the sampling some nearly-but-not-quite-the-same value. Perhaps this is intended behavior but it is problematic as soon as you want to use the grid in other programs that expect equal grid spacing in the x and y directions.” Request a failing example.
  52. I once encountered an apparent bug in grdtrack, related to the flag "-T+e, which in theory should find you the nearest NaN values from a grid if your points are in an area of the grid that is all dummies. In my experience, if you only query one point, it works. But if you input more than one point, the resulting list of nearest points with an actual value is a list of duplicates of the first point, no matter where the input points (other than the first one) are.” Request a failing example.
  53. Ironing out remaining bugs relating to polygons that cross the dateline and/or include the poles in different projections - Kara said she had problems with this recently. PW: New issues added and two new (failing) test scripts added. Work to fix these in 5.3.x.
  54. Capture new examples from Dan B and Dave C. Paul will send email.
  55. Refine Dave’s report and submit to NSF. Paul will take the lead.