|
| 1 | +# InteractiveGMT — Vision |
| 2 | + |
| 3 | +## Mission |
| 4 | + |
| 5 | +InteractiveGMT (**i'GMT**) is a graphical front end to [GMT](https://www.generic-mapping-tools.org/) |
| 6 | +and its Julia extensions ([GMT.jl](https://github.com/GenericMappingTools/GMT.jl)) — not a |
| 7 | +replacement for it. GMT's power has always come from being a scriptable, composable command-line |
| 8 | +toolset; i'GMT's job is to make that power discoverable, just not and immediate, :). |
| 9 | +Most dialogs are thin skin over a real GMT.jl call, and every action a user takes graphically should be, |
| 10 | +in future, reproducible, inspectable, and scriptable from the |
| 11 | +Julia console docked in the same window. **Scripting is the backbone, not a fallback.** |
| 12 | + |
| 13 | +## The Five Pillars |
| 14 | + |
| 15 | +### 1. A real GUI for GMT — without abandoning the command line |
| 16 | + |
| 17 | +Grids, images, tables, and solids open into a native Qt6 + VTK window with proper interaction |
| 18 | +(gizmo, cube axes, shading, colour bars, context menus) — but the in-window Julia console keeps |
| 19 | +the underlying GMT.jl calls one keystroke away. Menu actions are GMT.jl one-liners with a UI in |
| 20 | +front of them, not a parallel reimplementation. A user should be able to build a figure by |
| 21 | +clicking, then lift the equivalent script straight out of the console history. |
| 22 | + |
| 23 | +### 2. 3-D, volumetric, and spherical, natively |
| 24 | + |
| 25 | +GMT's native domain is the 2-D map; i'GMT's is what comes after: 3-D grids and point clouds today, |
| 26 | +extending toward true volumetric rendering (netCDF cubes, layered earth models) and spherical |
| 27 | +(whole-globe, non-planar) visualization — the geometries a flat `-JX`/`-JM` projection was never |
| 28 | +meant to carry. The Qt+VTK core exists specifically because this class of rendering has no home in |
| 29 | +classic GMT PostScript output. |
| 30 | + |
| 31 | +### 3. Rescue the Mirone legacy |
| 32 | + |
| 33 | +[Mirone](https://github.com/joa-quim/Mirone) accumulated two decades of MATLAB-based geoscience |
| 34 | +utilities — many with no equivalent in any other package, free or commercial: tsunami modelling |
| 35 | +(NSWING), Okada elastic deformation, IGRF, focal mechanisms, grid transplanting, nested-grid |
| 36 | +tools, seismicity catalogs, tile mosaics, and more. Most would otherwise be lost to an aging, |
| 37 | +license-gated runtime. Porting them into i'GMT — one dialog, one Julia module at a time — is not |
| 38 | +nostalgia; it's preservation of working science that deserves a modern, open home. |
| 39 | + |
| 40 | +### 4. Native multibeam ingestion |
| 41 | + |
| 42 | +Bring [MB-System](https://www.mbari.org/technology/mb-system/)-readable multibeam formats |
| 43 | +directly into i'GMT, and mirror the useful parts of MB-System's own GUI tools (swath editing, |
| 44 | +cleaning, mosaicking) inside the same window a grid or point cloud already opens in — instead of |
| 45 | +requiring a separate application and a file round-trip. |
| 46 | + |
| 47 | +### 5. Investigate swallowing GMTSAR |
| 48 | + |
| 49 | +InSAR processing ([GMTSAR](https://topex.ucsd.edu/gmtsar/)) is presently a shell-script-driven |
| 50 | +pipeline bolted onto GMT. Whether it can be "librarified" — exposed as a callable library GMT.jl |
| 51 | +(and by extension i'GMT) can drive directly, the way GMT's own modules already are — is an open |
| 52 | +feasibility question, not a commitment. Worth investigating; worth swallowing whole if it proves |
| 53 | +tractable. |
| 54 | + |
| 55 | +## What Stays True Throughout |
| 56 | + |
| 57 | +- **GMT command-line fidelity first.** Every graphical feature maps to real GMT/GMT.jl calls a |
| 58 | + script could also make. No dialog is allowed to become the *only* way to do something. |
| 59 | +- **Julia, not a shadow language.** Extensions are Julia modules calling GMT.jl, not a bespoke |
| 60 | + scripting layer competing with it. |
| 61 | +- **Windows today, portable in spirit.** The current viewer binary is Windows-only by |
| 62 | + circumstance (the build toolchain), not by design — nothing in the architecture is |
| 63 | + Windows-specific. |
0 commit comments