Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Retain information about default colormaps for remote files #6167

Closed
maxrjones opened this issue Dec 29, 2021 · 7 comments · Fixed by #6178
Closed

Retain information about default colormaps for remote files #6167

maxrjones opened this issue Dec 29, 2021 · 7 comments · Fixed by #6178
Labels
feature request Request a new feature

Comments

@maxrjones
Copy link
Member

Description of the desired feature
It would be helpful if GMT had a way to retain information about the default colormaps for remote files during processing. For example, if the following code produced two images using the geo colormap. This feature would be helpful for PyGMT, where the remote data files are often read into memory before being passed to GMT, resulting in the loss of the default cpt information (xref GenericMappingTools/pygmt#499).

gmt grdimage @earth_relief -R0/10/0/10 -B -JM5c -png ex1

gmt begin ex2 png
    gmt grdcut @earth_relief -R0/10/0/10 -JM5c -Gtest.nc
    gmt grdimage test.nc -B
gmt end show

ex1:
ex1

ex2:
ex2

Are you willing to help implement and maintain this feature? Yes

@maxrjones maxrjones added the feature request Request a new feature label Dec 29, 2021
@PaulWessel
Copy link
Member

One relatively simple implementation would be to add an attribute to the output netCDF file that holds the default CPT, if one is available. It could then be read and placed in the hidden GRID_HEADER structure and used to inform the default CPT choice if none is set via -C. This makes these assumptions:

  1. The user is not specifying a non-netCDF output grid format
  2. PyGMT can access the attributes of a netCDF grid when read into an Xarray.

I think (1) is reasonable, only very specific needs require a non-netCDF intermediate grid. As for (2), need feedback from @GenericMappingTools/pygmt-admin if this helpful, and perhaps @joa-quim could have similar needs in GMT.jl.

@maxrjones
Copy link
Member Author

Currently, PyGMT loads the variable attributes for netCDF grids but not the global attributes and uses grdinfo to access other attributes (registration, grid type).

@joa-quim
Copy link
Member

The SST L3 grids from the OceanColor color come with a cpt in global attribute called palette. But silly is a 3x254 instead of a 255x3 array. We could use the same name for that attribute. If I would use it or not in GMT.jl I don't know right now.

@PaulWessel
Copy link
Member

PaulWessel commented Dec 30, 2021

So the grid's z' attributes are read, so if I add palette it would be available to PyGMT then.

@PaulWessel
Copy link
Member

The SST L3 grids from the OceanColor color come with a cpt in global attribute called palette. But silly is a 3x254 instead of a 255x3 array. We could use the same name for that attribute. If I would use it or not in GMT.jl I don't know right now.

Since this would only be used when GMT grdcuts a subset off one of our remote grids and writes a netCDF grid, I think just adding CPT = "@earth_age.cpt" or similar is all we need to do.

PaulWessel added a commit that referenced this issue Dec 31, 2021
This addresses #6167 when we cut a subset from, sa, earth_relief_10m and then no longer know what the CPT should be.
PaulWessel added a commit that referenced this issue Jan 3, 2022
* Save any default CPT in hidden grid header

This addresses #6167 when we cut a subset from, sa, earth_relief_10m and then no longer know what the CPT should be.

* use allocated string cpt instead

* Init remote_id to -1

* polish

* Fix save CPT and highpass

* Update gmt_support.c

* Add small tests

* formatting

* Remove boundary annotations

* Save the current CPT from grdcut if modern mode
@PaulWessel
Copy link
Member

OK to close, @meghanrjones ?

@maxrjones
Copy link
Member Author

Yes

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature request Request a new feature
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants