just one spontaneous idea: For grdview, the elevation is not only represented by the color-coding but also along the vertical or z-axis. So, there is the question at which position of the z-axis NaN values should be plotted, as there is no NaN value on the z-axis. Probably GMT does not know where to plot the NaN part of the data (vertically) and simply skips it.
In principle, it should be working. But if you also want 0 to be in red, then you need something like -Sb0/-0.1, as the colormap starts at zero (T0/2000).
Ah, yes your are right! Must have missed this part somehow when copying the code (locally I have gmt grdclip island.nc -Gtopo_island.nc -Sb0/-1 -Sr0/-1).
Updated my post above to avoid further confusions.
The issue of using NaN colors in grdview is probably something that could be improved and revisited. Right now, I get read NaNs only with -Qs (surface) and only without -p. This is due to various if-test checks. For -Q we rasterize the grid to an image and set the image pixels to whatever color (but not the NaN color).
I suspect we will need a modifier or option to insist that we use the NaN color, whatever it is, on the NaN pixels or NaN nodes or NaN patches. Perhaps the simplest syntax might be a new modifier +n to -Q which says "paint any NaN node or pixel with the NaN color in the CPT (requires -C)?
Seeing a duplicate the grid makes ruffle my hair. Looks like the right thing here is to make a NaN/no-NaN mask and add it as an alpha layer to the image. Then the transparency and transparent color machinery should apply. But we didn’t test the alpha machinery to grdview before.
(locally I have 