CPT range auto-stretching works differently with NetCDF and virtual reliefgrid inputs #5294
Comments
|
I am getting lots of these errors (the one with -1 -9 etc): What am I missing here? |
|
Ah yes, could you try doing |
|
Sorry, I need more help if I am going to debug this - we are also running out on time fro 6.2.0 I think. pip install github.com/GenericMappingTools/pygmt/archive/grdimage-xarray-shading.zip I usually debug against master and now little about the pyGMT setup... |
|
Hmm, did you add https:// to the url? |
|
For some reason I managed not to copy that part... OK now. |
|
But makes no difference - same errors. |
|
Did you restart the Python kernel? I'm assuming you ran conda activate pygmt # Activate the PyGMT environment
pip install https://github.com/GenericMappingTools/pygmt/archive/grdimage-xarray-shading.zip # install the PyGMT PR branch
python # to get the python console
ipython # to get interactive python console |
|
I probably need to install ipython then
|
|
sudo port install ipython |
|
|
|
OK, done, but still typing ipython into the python problem gives same error. |
|
Sorry, just ignore the |
|
OK, getting same errors as reported at first. |
|
I get the bug with master gmt branch and grdimage-xarray-shading pygmt branch. I could step through to see if I notice anything if it would help. |
I do not think it is reproducible with pygmt's master branch. |
The PR contains a feature which isn't merged into PyGMT's master branch yet, so need to install the feature branch to test. |
|
Ok, PR GenericMappingTools/pygmt#750 has been merged into PyGMT master so it should be easier to test things now. Note that there might be a separate bug intertwined into this, related to an offset of pixels (see GenericMappingTools/pygmt#750 (comment)). |
|
For the example above, the Here is another example that is broken in a different way: import pygmt
# Expected (wrong) case using xarray.DataArray reliefgrid
fig = pygmt.Figure()
grid = pygmt.datasets.load_earth_relief(registration="gridline")
fig.grdimage(grid=grid, region=[0, 5, 0, 5], cmap="geo", verbose="i")
fig.colorbar()
fig.savefig("test.png")For this example |
|
I will have a look at debugging this pygmt case. |
Thanks. When I was debugging the offset issue, I used this paired down version without the shading code: import pygmt
# Baseline (correct) case using @earth_relief_01d_g reliefgrid
fig = pygmt.Figure()
fig.grdimage(
grid="@earth_relief_01d_g", region="GL", cmap="geo", verbose="i"
)
fig.colorbar()
fig.show()
# Expected (wrong) case using xarray.DataArray reliefgrid
fig = pygmt.Figure()
grid = pygmt.datasets.load_earth_relief(registration="gridline")
fig.grdimage(grid=grid, region="GL", cmap="geo", verbose="i")
fig.colorbar()
fig.show() |
|
Region="GL" presumably returns the w/e/s/n in floating degrees not rounded off, yes? Could anyone try the same test with a rounded w/e/sn to the nearest integer degree and tell if the problem persists? |
Trying the below: fig = pygmt.Figure()
grid = pygmt.datasets.load_earth_relief(registration="gridline")
# fig.grdimage(grid=grid, region="GL", cmap="geo", verbose="i")
# fig.grdimage(grid=grid, region="286.737/348.688/59.7773/83.6274", cmap="geo", verbose="i")
fig.grdimage(grid=grid, region="287/349/60/84", cmap="geo", verbose="i")
fig.colorbar()
fig.show()Edit1: Sorry, I haven't tried the patch at #5940, this is just with regular GMT 6.2. On GMT 6.2 and PyGMT v0.5.0, using integer degrees still stretches things to the global range (-8592.5 to 5559): grdimage [INFORMATION]: Read header from file @GMTAPI@-S-I-G-M-G-N-000000
grdimage [INFORMATION]: Spherical approximation used
grdimage [INFORMATION]: Central meridian not given, default to 318
grdimage [INFORMATION]: Map scale is 459.606 km per cm or 1:4.59606e+07.
grdimage [INFORMATION]: Allocate and read data from file @GMTAPI@-S-I-G-M-G-N-000000
grdimage [INFORMATION]: Importing grid data from user matrix memory location
grdimage [INFORMATION]: called with a pad < 2; skipped.
grdimage [INFORMATION]: Reading CPT from File /srv/conda/envs/notebook/share/gmt/cpt/geo.cpt
grdimage [INFORMATION]: Auto-stretching CPT file geo to fit data range -8592.5 to 5559
grdimage [INFORMATION]: Write CPT to File /home/jovyan/.gmt/sessions/gmt_session.115/gmt.6.cpt
grdimage [INFORMATION]: Save current CPT file to /home/jovyan/.gmt/sessions/gmt_session.115/gmt.6.cpt !
grdimage [INFORMATION]: Evaluate image pixel colors
grdimage [INFORMATION]: Basic z(x,y) -> color image with no illumination.
grdimage [INFORMATION]: Plotting 24-bit color image
PSL: Too many colors to make colormap - using 24-bit direct color instead.
PSL: DEFLATE compressed 4725 to 3662 bytes (22.5% savings at compression level 5)produces: Edit2: The below are the results on GMT 6.3 from master when using integer coordinates. Range is -3824.5 to 3195.5, desired range is -3893 to 3195.5 (if using netcdf file directly): produces
|
|
In the example below, the colormap is not correct for virtual files even after the last two PRs: import pygmt
# Baseline (correct) case using @earth_relief_01d_g reliefgrid
fig = pygmt.Figure()
fig.grdimage(
grid="@earth_relief_01d_g", region=[0, 5, 0, 5], cmap="geo", verbose="i"
)
fig.colorbar()
fig.savefig("test_correct.png")
# Expected (wrong) case using xarray.DataArray reliefgrid
fig = pygmt.Figure()
grid = pygmt.datasets.load_earth_relief(registration="gridline")
fig.grdimage(grid=grid, region=[0, 5, 0, 5], cmap="geo", verbose="i")
fig.colorbar()
fig.savefig("test_wrong.png")test_correct.png: test_wrong.png: In constrast to the original example, the incorrect case here goes through the Lines 5242 to 5327 in 8c55a80 The other header attributes are updated in Lines 3235 to 3264 in 8c55a80 |
When a matrix is passed by reference and there is no need to switch to duplication, we adjust the grid's pad to simulate a cut. However, we never updated the header zmin/zmax to reflect the new data region. This PR takes care of this for grids (and cubes). Closes #5294.
* Update the z min/max inside readonly subsets When a matrix is passed by reference and there is no need to switch to duplication, we adjust the grid's pad to simulate a cut. However, we never updated the header zmin/zmax to reflect the new data region. This PR takes care of this for grids (and cubes). Closes #5294. * use GMT_LOCAL
Description of the problem
When comparing a
grdimageplot from a regular remote file and virtual file input, while setting a specific region (e.g. Greenland/GL in the case below), the CPT range is stretched differently. Specifically, the CPT range is -3893 to 3195.5 for the remote file case, but -8592.5 to 5559 for the virtual file case. See GenericMappingTools/pygmt#750 (comment) for context.Need to install PyGMT branch from GenericMappingTools/pygmt#750 first usingEdit: just dopip install https://github.com/GenericMappingTools/pygmt/archive/grdimage-xarray-shading.zipfirst before running the below:pip install pygmt=0.5.0.Full script that generated the error
Full error message
Copied from https://github.com/GenericMappingTools/pygmt/runs/2733822414?check_suite_focus=true#step:11:543
Actual outcome
Shading an xarray.DataArray (via the GMT C API)
**
Expected outcome
Shading the
@earth_relief_01d_gfile directly.Diff
System information
gmt --version): 6.2.0rc2The text was updated successfully, but these errors were encountered: