# Dataset versioning
**URL:** https://forum.generic-mapping-tools.org/t/dataset-versioning/6408
**Category:** Site Feedback
**Created:** [April 18, 2026, 7:35pm UTC](https://forum.generic-mapping-tools.org/t/dataset-versioning/6408 "2026-04-18T19:35:46Z")
**Posts on this page:** 9
**Page:** 1
### Author:  [@Andreas](https://forum.generic-mapping-tools.org/u/Andreas)
#### Post date: [April 18, 2026, 7:35pm UTC](https://forum.generic-mapping-tools.org/t/dataset-versioning/6408/1 "2026-04-18T19:35:46Z")
> [@Invitation to participate into a "GMT Advisory Group" meeting](http://forum.generic-mapping-tools.org/t/invitation-to-participate-into-a-gmt-advisory-group-meeting/6377/21):
>
> There is the SWOT gravity data ( [Index of /pub/global\_grav\_1min\_SWOT](https://topex.ucsd.edu/pub/global_grav_1min_SWOT/) ). Should we replace the old gravity data ( [IGPP Earth Free-Air Anomaly — Remote Datasets documentation](https://www.generic-mapping-tools.org/remote-datasets/earth-faa.html) ) or add a new dataset?
Please add a new dataset! Don’t replace it.
---
### Author:  [@mkononets](https://forum.generic-mapping-tools.org/u/mkononets)
#### Post date: [April 18, 2026, 7:56pm UTC](https://forum.generic-mapping-tools.org/t/dataset-versioning/6408/2 "2026-04-18T19:56:44Z")
comment withdrawn
---
### Author:  [@SolarEarth](https://forum.generic-mapping-tools.org/u/SolarEarth)
#### Post date: [April 20, 2026, 2:40pm UTC](https://forum.generic-mapping-tools.org/t/dataset-versioning/6408/3 "2026-04-20T14:40:12Z")
The current naming convention and directory structure do not readily support multiple versions of the datasets. I would like to support multiple versioning of the datasets as part of FAIR principles. But of course it can very quickly become a complicated challenge.
I’m thinking perhaps we could create a subdirectory to hold the versioned instances of the datasets but have the unversioned path/filename (eg. server/earth/earth\_faa/earth\_faa\_01m\_p) point to the latest or most up to date version.
How has this issue been addressed within GMT in the past? Is there already a pardigm I should be aware of? I did a quick search of the forum, but didn’t come up with any guidance.
---
### Author:  [@mkononets](https://forum.generic-mapping-tools.org/u/mkononets)
#### Post date: [April 20, 2026, 3:11pm UTC](https://forum.generic-mapping-tools.org/t/dataset-versioning/6408/4 "2026-04-20T15:11:42Z")
comment withdrawn
---
### Author:  [@Esteban82](https://forum.generic-mapping-tools.org/u/Esteban82)
#### Post date: [April 20, 2026, 3:23pm UTC](https://forum.generic-mapping-tools.org/t/dataset-versioning/6408/5 "2026-04-20T15:23:40Z")
Hi Solar
> [@SolarEarth](#):
>
> How has this issue been addressed within GMT in the past? Is there already a pardigm I should be aware of? I did a quick search of the forum, but didn’t come up with any guidance.
Yes, the current policy is published here ([Remote Datasets — GMT 6.7.0 documentation](https://docs.generic-mapping-tools.org/dev/datasets/remote-data.html#remote-datasets)):
> It is our policy to only supply the _latest_ version of any dataset that undergoes revisions. If you require previous versions for your work you will need to get those data from the data provider separately.
---
### Author:  [@Joaquim](https://forum.generic-mapping-tools.org/u/Joaquim)
#### Post date: [April 21, 2026, 12:34am UTC](https://forum.generic-mapping-tools.org/t/dataset-versioning/6408/6 "2026-04-21T00:34:08Z")
Extending to version datasets looks complicated (and honestly, in my view data distribution is not exactly the main GMT business).
Our current naming scheme already has 3 parameters
```@remote\_name\_rru[\_reg]```
and adding a new one would imply a 4rth one
??
```@remote\_name\_[date]\_rru[\_reg]```
but then `date` here would be dependent on that dataset as each of them has different release histories. And all these would need to be followed by code changes to accommodate it. … far from trivial and very doubtful that it would worth the time/effort to implement (who?) it.
---
### Author:  [@mkononets](https://forum.generic-mapping-tools.org/u/mkononets)
#### Post date: [April 21, 2026, 9:33am UTC](https://forum.generic-mapping-tools.org/t/dataset-versioning/6408/7 "2026-04-21T09:33:26Z")
BTW Why is it important to keep each dataset in both gridline and pixel registrations? I presume there must be some good reason to keep double the size of each gmt dataset?
---
### Author:  [@SolarEarth](https://forum.generic-mapping-tools.org/u/SolarEarth)
#### Post date: [April 21, 2026, 6:21pm UTC](https://forum.generic-mapping-tools.org/t/dataset-versioning/6408/8 "2026-04-21T18:21:25Z")
One option that might not be too complicated is to create a tarball of the dataset, like server-earth-earth\_faa-20260120.tar.gz and store it in something like an Archive subfolder. So if a user really wanted the older version to support reproducible research, they could download it in a form that is already tiled and formatted to be readily useable by GMT. It would then be up to the user to unpack the datasets into the appropriate place in their .gmt/server directory and do something like set GMT\_DATA\_SERVER = none and GMT\_DATA\_UPDATE\_INTERVAL = 0 to prevent the dataset cache from being overwritten when GMT runs.
---
### Author:  [@mkononets](https://forum.generic-mapping-tools.org/u/mkononets)
#### Post date: [April 22, 2026, 9:31am UTC](https://forum.generic-mapping-tools.org/t/dataset-versioning/6408/9 "2026-04-22T09:31:47Z")
I just realized I have already been storing some old and not so old versions of some datasets archived locally.
So I withdraw all my arguments for the gmt project to keep providing access to the old versions of the remote datasets.