GMT Advisory Meeting Summary
Date: June 11, 2026 Duration: ~54 min Participants: Solar Smith (EarthScope), Garrett Apuzen-Ito, David Caress (at sea, Mid-Atlantic Ridge / Doldrums Transform), Joaquim Luis, Federico Esteban, Yvonne Freohlic
1. EarthScope/AWS Infrastructure Migration
GMT Forum
The GMT Forum has been successfully migrated to a Discourse-hosted server, fully off the University of Hawaii hardware. The migration took an extra day to get the custom domain name configured correctly. No issues have been reported. Joaquim noted one wrinkle: forum notification emails were briefly caught by Microsoft’s anti-spam filter, likely due to the sender address change — participants were advised to check their spam folders.
S3 Data Server — Status
Solar has a working prototype: the GMT datasets have been mirrored to an S3 bucket set up as a website, and he has successfully made GMT maps pulling from it. The system is still being tested and refined; the next step is assigning proper, intuitive domain names under the generic-mapping-tools.org domain (e.g., something like earthscope.genericmappingtools.org or primary.genericmappingtools.org). The group had no strong opinions on the naming — it was treated as a minor documentation matter.
S3 Limitations — Legacy Symlinks
S3 buckets do not support symbolic links or linked directories. Solar explained that around GMT 6.1 (~2020) the data server layout changed from a flat structure to the server/{planet}/dataset/ hierarchy, and symlinks were added to support pre-6.1 clients. To handle this on S3:
-
File links: Duplicated the actual files in the legacy locations (no performance cost)
-
Directory links (SRTM1, SRTM3): Implemented as HTTP redirects via CloudFront
Should legacy structure be maintained on mirrors? The group reached a clear consensus: not a priority. Joaquim’s position: there’s no good reason to still be running GMT 6.0, and it’s not the project’s responsibility to maintain data compatibility for users who haven’t updated in 6 years. Federico clarified the concern is GMT client version, not dataset version. David Caress agreed: the only way to know if anyone actually needs it is to stop supporting it and see if anyone complains. Solar will document that mirror operators syncing from S3 will not automatically support pre-6.1 clients, but the EarthScope-hosted server will continue to do so since it costs nothing on S3.
Cache / Test Data (Raised by Joaquim — Previously Overlooked)
Joaquim flagged an important element that had been left out of prior infrastructure discussions: the GMT cache, distinct from the remote datasets. Files referenced with a @ prefix (hat) in GMT tests are hosted on the data server and pulled on demand. The GMT data server runs a daily cron job that checks the gmtserver-admin GitHub repository for new files and pulls them to the server automatically. This mechanism must be replicated in the EarthScope/AWS setup. Federico confirmed the repository is gmtserver-admin and shared the link in the meeting’s Google Doc. Solar noted this as a new item to investigate and will look for the cron job on the current Hawaii server.
Integration with EarthScope Data Distribution
Work is ongoing to integrate the GMT data server capability with EarthScope’s broader data distribution systems, potentially making it accessible at something like data.earthscope.org/gmt. Still in planning.
Hawaii Server Transition
The University of Hawaii GMT server is expected to remain running in parallel for at least ~6 months after the EarthScope server goes live, to give users time to migrate. No firm shutdown date has been set.
2. GMT Release Planning — Version 6.7
Zenodo
Pushing GMT releases to Zenodo remains on the agenda but is not being actioned until the data server migration is more settled. Solar and Joaquim agreed it makes sense to hold a new GMT release until the data server situation is resolved — so the release can point to the new default server out of the box.
Security Bug and Case for a Pre-Summer Release
Joaquim raised a potentially time-sensitive issue: a crash-inducing bug in GMT has been flagged by a community member as a security vulnerability (a CVE-type designation was mentioned). The Debian/Ubuntu package maintainer noticed this and asked when a new release with the fix would be available. The Debian release cycle is very slow — missing the next cycle would mean the old version staying in distro repositories for another 1–2 years.
Joaquim’s recommendation: If the data server migration issues are not resolved quickly, the group should consider doing a GMT 6.7 release before end of July, rather than waiting. There are approximately 80 open bug reports, several feature requests, and additional crash fixes already in progress. A July release would also get ahead of the Debian packaging cycle.
Solar agreed July is a feasible target. No formal decision was made, but it was noted as a goal.
3. Supporting Contributors with AI Tools
Current State
Solar’s Claude access is funded through EarthScope as part of his development work. Rob Casey (absent) is looking into what funding is available to extend Claude access to a small group of core contributors. The group discussed who should be included and how access should be managed.
Who Gets Access
Consensus: invitation-only, restricted to established contributors. Joaquim was clear: AI license seats should not be used to attract new contributors, but to support people who are already actively contributing. The initial group identified was approximately 4–5 people: Joaquim, Federico, Solar, and potentially Dongdong Tian. David Caress suggested a two-phase approach:
-
Stand up access for the obvious initial group and validate that costs are manageable.
-
Once confirmed, make it openly known that active contributors can be invited to join.
AI Usage Policy
Joaquim noted that a usage policy will eventually be needed — many open-source projects have strict rules about AI-generated code contributions. GMT should develop its own guidelines so contributors know what is and isn’t acceptable.
Claude Code Demo (Joaquim)
Joaquim shared his screen to demonstrate his Claude Code workflow (command-line shell interface on Windows). He showed an active session working through a VTK/Qt build problem, illustrating how he interacts with Claude entirely via typed text. Key observations from the discussion:
-
Claude can build and compile GMT, iterate on fixes, and navigate large codebases effectively
-
It can be directed to scan the GMT C codebase for specific classes of bugs (e.g., dangling pointer dereferences causing crashes) — a task that would otherwise be very time-consuming
-
However, it requires careful management: it consumes credits quickly on large files, sometimes claims to have fixed things it hasn’t actually tested, and can lead you down unproductive paths
-
Joaquim’s view: “Don’t trust it, but also let it do things that are fantastic — learn to navigate that balance”
David Caress, who described himself as a self-proclaimed Luddite about AI, admitted he recently started using Claude (via a Zimbra-linked subscription) and found it “indispensable” — two new GMT timeline tools were written primarily by Claude with his direction.
GMT-Specific AI Agent (Continued Discussion from Previous Meeting)
Solar raised Xiaohua Xu’s demo from the previous meeting (a GMT SAR agent that could fetch data and produce results through dialogue). The group discussed what a GMT-specific agent might look like:
-
Approach A — Lightweight prompt context: Use Claude’s existing knowledge plus GMT documentation/code fed into context or as “skills/memory” files. Joaquim noted Claude can be taught to retain knowledge between sessions using written files (skills). This would require users to still have their own Claude subscription.
-
Approach B — Fine-tuned small model: Train a small, purpose-built model specifically on the GMT codebase and documentation. Joaquim found this technically interesting but non-trivial (requires tokenizer, training infrastructure). It could potentially be free to run once built, but building it requires significant effort.
Garrett noted Claude in VS Code has similar agentic capabilities to Claude Code. Joaquim acknowledged this but expressed a preference for the command-line interface for deep coding work, citing more precise control over credit usage.
Rob Casey (absent but noted by Solar) is exploring funding options for both the developer license program and potentially the GMT agent concept.
4. DNS / Mirror Configuration Issues (GitHub Issue #8927**)**
Solar has now obtained access to the Hover DNS management account for the EarthScope domain and is investigating the mirror forwarding issues. Based on curl tests guided by Claude, the problem with the China mirror (china.generic-mapping-tools.org) appears to involve something going wrong at the HTTP → HTTPS redirect step, possibly a server-side configuration on the remote mirror dropping part of the URL. Joaquim clarified this is not unique to China: at least one Australian mirror had a similar problem where mirrors were inconsistently adding or omitting trailing slashes and path components, causing URL construction to fail for some mirrors but not others. Solar plans to continue investigating DNS configurations now that he has access.
Action Items
Owner
Action
Solar Smith
Investigate and replicate the daily cron job (gmtserver-admin GitHub → data server sync) in the AWS/EarthScope setup
Solar Smith
Document that S3 mirror sync does not automatically support pre-6.1 GMT clients; legacy paths supported on EarthScope server only
Solar Smith
Finalize domain name for EarthScope GMT data server under generic-mapping-tools.org
Solar Smith
Continue DNS investigation for mirror forwarding issues (GitHub issue #8927); now has Hover account access
Solar Smith
Coordinate with Rob Casey on AI license funding and next steps for contributor access
Joaquim Luis
Continue crash/bug fixes targeting a July 6.7 release; flag any blocking security issues
Joaquim / Federico
Continue developing Claude usage patterns for GMT codebase work; contribute to AI usage policy draft
Rob Casey (follow-up)
Report back on funding availability for contributor AI licenses (~4–5 seats)