Seems useful. Maybe it is useful for you to look at our admin/build-scientific-colors-cpt.sh for converting their CPT into our master format (normalized 0/1 or -1/+1, depending on whether there is a hinge or not).
We may also wish to add a checker in the CI to tell us when there is a new release. @meghanrjones how is that working again?

The scientific colour maps workflow checks for releases using their Zenodo archive. It doesn't look like cmocean is on Zenodo, but we could probably query https://github.com/matplotlib/cmocean for new releases.

Yes, @PaulWessel. I can either convert their RGB text files, or get the GMT4 formatted files from cpt-city and do the normalisation. I'll certainly look at your script. Thanks for the hint.

@meghanrjones : Yes, that would be a start, but most likely the updates would be in the python scripts, not in the underlying colour maps.

I'm getting well on my way with this. I'm now getting Kirsten's own CPT files from here: https://github.com/kthyng/cmocean-gmt
And I've more or less made a working script like the one @PaulWessel pointed out.
There are two names of colourmaps that we already have (gray and topo). What shall I do there?

• Gray we can likely skip, as it is virtually the same as ours.
• Topo is different. Maybe rename it topo-cmocean?

There are no foreground, background or NaN colours defined in these maps. Shall I leave them out in our own versions?

Great. As for the BNF, if they have none then do not add any - this means GMT supplies its default settings which is all we can do without adding new things.

While renaming to a non-conflicting name is fine, perhaps we should at least discuss what alternatives there are? I can think of this one:

1. Contain sets of CPTs in groups or subdirectories, e.g., cmocean, matlab, matplotlib, gmt, fabio, cpt-city to allow the same named CPT to exist in different groups.
2. Either user typical directory separators in -C, e.g., -Ccmocean/topo or (since these are not actually file names) some new syntax like -C[group:]master, where default group is gmt. Yet, for backwards compatibility we would probably need to put everything up to now into the gmt group as well as duplicate into the new groups.

I am just concerned how to handle 1000s CPT files eventually - we are not there yet but probably because we do not directly support cpt-city...

I think a directory structure is a wise, flexible, and workable solution. I'll just need to check how the -C option behaves when using a slash in the name. I think the slash is preferred above all else, as that becomes natural to me.
If -C already works without changes, I would opt to:

• Store the GMT-originals in a subdirectory gmt of the directory share/cpt directory
• Store the others we borrowed from other projects into respective subdirectories like cmocean, panoply, fabio
• Link all those that we already have now from the share/cpt directory to the respective subdirectories mentioned above

Another few thoughts:

• Putting a link in share/cpt is of course possible, but is not really practical from a maintenance point of view. It might not even transfer well to Windows, does it?
• Probably we should add those "directories" to the names in the list that makecpt produces, then when the user selects a name without the directory, makecpt will pick the first one on the list that matches. E.g., -Ctopo will convert to -Cgmt/topo
• This allows backward compatibility and forward flexibility to adopt a lot of new maps, and be clear about their origin.
• I may need some help identifying which colourmaps came from where to put them in the right place.

Yes, I think we are talking about a handful of bytes so the duplication is OK and simplifies operations, including lack of symlinks (or done differently) on Windows.

Yes, I assume output form makecpt would be sorted per collection and maybe

gmt/abyss       : Black/dark blue to lightblue for bathymetry [R=-8000/0, C=RGB]
...
crameri/categorical : Color table particularly suitable for categorical data [C=RGB]

I think the gmt/ part is optional and if no directory given we default to gmt/ as you say.
I am less certain if we should hunt through all future directories looking for "topo" since then it becomes unclear which directory should be first in the list. If collections A and B both have a junk.cpt, what should -Cjunk return? I think it should probably be an error message saying no junk.cpt in collection gmt or something.

I got a lot further with this. There are just a few that I have not sorted out, see at the top of the list of
https://github.com/GenericMappingTools/gmt/blob/d7fa1f184acf82aa21da41f54161df684db5ff9e/src/gmt_cpt_masters.h

Where should those go?
Do you agree with the rest of the sorting?

I think these are basically cptcity:

cubhelix, dem1, dem4, elevation

These should be in the gmt list for sure: globe, mag, seis
But I think the rest can also be added to gmt to keep life simple.