-
Notifications
You must be signed in to change notification settings - Fork 356
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
Ability topping NaN nodes/pixels in grdview with the NaN color #8301
Comments
Yes, but (as Yvonne said on the post) how GMT would know at what z value should paint the NaN? At the bottom of the 3D block? at the top? in the middle? So, the modifier must include a z value. |
The NaN value is used, not some random z-value. Aren’t we talking NaNs?
Paul Wessel
Professor Emeritus, Department of Earth Sciences
(808) 956-4778 | ***@***.***
http://www.soest.hawaii.edu/earthsciences
On 17 January 2024 at 12:50:33, Federico Esteban ***@***.***) wrote:
Yes, but (as Yvonne said on the post) how GMT would know at what z value
should paint the NaN? At the bottom of the 3D block? at the top? in the
middle? So, the modifier must include a z value.
—
Reply to this email directly, view it on GitHub
<https://urldefense.com/v3/__https:/GenericMappingTools/gmt/issues/8301*issuecomment-1895649416__;Iw!!PvDODwlR4mBZyAb0!T6N3-p0X4FsExxR39vvgorBE6akpqeMN7B9M2CuIE3BGHfWYJk2nU5481820m8vCfptas8lGEN4IvurZNKAE4Zc9aw$>,
or unsubscribe
<https://urldefense.com/v3/__https:/notifications/unsubscribe-auth/AGJ7IX26QVKY7P32RVJSXJ3YO63INAVCNFSM6AAAAABB6KT2EOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQOJVGY2DSNBRGY__;!!PvDODwlR4mBZyAb0!T6N3-p0X4FsExxR39vvgorBE6akpqeMN7B9M2CuIE3BGHfWYJk2nU5481820m8vCfptas8lGEN4IvurZNKDYMNAubg$>
.
You are receiving this because you were assigned.Message ID:
***@***.***>
|
As I understand, We can set the color of NaN for the But we also need a value for the |
HM, OK there are several issues with grdview that we have addressed in grdview so now there are differences in syntax, docs, and maybe internal operations. Back from GMT4 we used to allow grdimage to accept three grids (red.grd, green.grd, blue.grd). We still do so under the hood but usage and documentation only discusses single grid and single image (grid | image). In fact, grdimage handles those 3 grids as three consecutive files given on input. This differs in grdview. In grdview.c we list the single relief grid but under -G for drape grid we still list the option for three grids (-Gdrapegrid | -Gred.grd -Ggreen.grd -Bblue.grd). So here, -G is repeated 3 times. This all looks ugly to me. Apart from the NaN-color issue, I think grdview needs to modernise its documentation and usage and hide this ugliness but accept it via backwards compatibility. Our preferred way of images is passing an RGB image, not 3 grids from an era before @joa-quim worked to include images. We might even consider a GMT_Call_Module to grdmix if we get 3 color grids and return the image. In the presence of draping, the relief grid just provides geometry/shape and there is nothing to paint. COlor is determined by the draping and that grid may have NaNs to be coloured or it is an image. grdimage image has many ways to handle NaN color - not sure if we want to replicate all that in grdview. I think I may want to work on a PR that fixes the oldfashinoned -Gred -Ggreen -Gblue syntax first. |
BTW, I just post in the forum a way to do it (that maybe is clearer). |
I think @joa-quim might recall we had a rgb2grd module a long time ago? So that is how people made those 3 grids. Better to expect -Ggrid|image and leave some stuff under the hood in case someone runs an old script with three -G drape grids. |
Also @joa-quim you added this in the grdview parser:
We will see but perhaps there wont be a need for this once -Gimage works, but no biggie. |
What do you think is |
Sorry, a bit early to know - I am in the middle of stuff. Not quite sure of what you are asking. |
Hmm, I'm not finding any use of that hidden |
Think we can remove it. We learn that one image is passed and that is all that is needed I think. |
See the forum post for background.
Apparently, grdview can only paint nodes with the NaN colour for -Qs (surface) and when the 3D vantage point -paz/el is not used. This seems unnecessarily restrictive for no good reason and probably hails back to the GMT4 days. My proposal to improve this involves a new modifier to -Q. New syntax (and improved layout for all):
-Qc|i|m[x|y][color]|s[m][+m][+n]
Select among the following directives c i m or s:
feature in PostScript Level 3 (the PS device must support PS Level 3).
Note: If the CPT is categorical then only -Qm is available (but see -T).
Optional modifiers:
One question is if we leave the NaN colour default for -Qs or if that also needs +n? Probably for backwards compatible reasons we should leave it?
The text was updated successfully, but these errors were encountered: