Double frame on grdview perspective plot #4181
Comments
|
You can avoid it with |
|
The "double frame" is actually the frame for geographic projections (i.e., the fancy frame). If you add -Bxaf -Byaf to the command, it would be more clear:
The debug message from @weiji14 says: it's unclear to me why GMT chooses -JX15c for a geographic grid. |
It's the poor man's choice. Alternative would be to give the right projection for the given region. Doable but never done. |
|
Ok, put it down as user error for now (setting a projection like |
|
Agree. It's a mild bug |
|
Not sure what you expect here. There is only -Bzaf given, right? So nothing for x-y. It cannot draw checker-board without knowing or setting increments, but no -B was given. So what it did was basically -B0. When that happens I totally agree that the double lines are not helpful, so it could switch to a plain frame in that case when no increments are set. |
|
I actually expect no X and Y frames here, because not -Bxaf and -Byaf are given. BTW, adding -B0 to the grdview command gives me a plain frame. |
|
Yes, I can go with that, I was just assuming we have to do some backwards compatibility here by drawing that -B0. But I would be fine and happier with just the z-axis as requested. |
|
Ping @weiji14. |
|
I think it would look weird with just the z-axis plotted and no x and y frames (maybe someone would plot it that way?), but happy to go with it (just z-axis plotted). Anything is better than the strange double frame really. |
|
Remember that we have MAP_FRAME_AXES defaulting to |
|
Or -B+n I think. |
No, -Bzaf -B+n doesn't plot the Z axis.
For 2D maps, the frames are not plotted unless -B, -Bx or -By is given. However, for the 3D case, giving -Bz only also plots the X and Y axes seems weird to me. |
|
Yes, it breaks the logic. -Bz should not magically also turn on horizontal frames I think. That is the error here. |
|
Based on experiments yesterday, I think we need to add a bool that keeps track if -Bx and|or -By (typically via plain -B) is set during parsing. Only if that is true shall we plot the x-y basemap. Right now there is various confusions. For instance, test/psxyz/filler.sh (which passes) uses -Bwesn and it somehow draws the frame (just like -B0) would do. But not sure if specifying axes and format shall automatically imply -B0? We have a system default of WESN which kicks in if you specify intervals with -B. So in that sense -Bwesn just overrides that default but should not result in any frame. Agreed? |
|
Yes, -Bwesn should not result in any frame. |
|
What should -B0 result in? When I replaced -Bwesn in fillter.sh with -B0 I get an empty 3-D stick for the z-axis. I think that is why I did -Bwesn so I could do -B0 -Bwesn, but we should define what -B0 means, i.e., should it imply anything about the z-axis. |
|
-B0 is a xy frame with no annots, no ticks and no grid, right? |
|
I am totally confident in that is what we meant, yes. But
gives that z-stick. |
|
I am learning that if I turn the z-axis off then the map title is plotted as 2-D instead of in-plane 3-D. So while the above command no longer has a stick. Compare these: In master, running
while in my branch that lets -B0 only set x/y frame the same command looks like this:
In that branch, I can get the first plot by adding -Bz0. As you can see, a true 3-D plot places a 2-D title while a perspective 2-D plot gets a title in the same perspective. Might also want to document taht, but I think the branch is better, no? What does @seisman think? I should add that perhaps the real problem is that -JZ is being used but nothing is plotted in z. So perhaps master is correct in that sense. Yet, if I take out -JZ and run master I get a 2-D title:
|
|
Having the z stick with |
|
I agree. So we have these rules:
|
|
Yes, seems to cover all cases. |
|
#4293 still doesn't fix the issue, right? |
|
Trying the latest master branch. The following result doesn't make sense. Here I give -Bx -By, but the Y annotations and ticks are not shown.
|
|
So in the highest level of parsing I know we look (in modern mode only) for options like plain -B and we append to make it -Baf. I probably did not check for them all individually so will do that later today). |
|
No, I have checks for those cases and they should all end up as -Bxaf -Byaf and -Bzaf. So then the question is what happens next in the auto-interval section. |
|
After -Bx is parsed, GMT->current.map.frame.set is true and -By is not processed, only -Bz. I think set needs to be set[GMT_X|Y|Z] so we have more control here. |
|
Note: This has been fixed in PR #4274 and will go away once that branch is merged. |
|
Branched merged so closing this issue. |
Description of the problem
There appears to be a double-frame on the x and y-axis when making a perspective plot using
grdviewwith the-Jzflag. Originally detected at GenericMappingTools/pygmt#589 (comment).Full script that generated the error
Full error message
System information
I've reproduced this both on my personal computer and on the try-gmt.
gmt --version): 6.1.1The text was updated successfully, but these errors were encountered: