Open uleysky opened 2 years ago
-Bswnez1
What is that 1 doing there? Without it it works fine.
gmt psbasemap -R0/10/0/20/0/30 -JX5c/10c -JZ15c -Bxa+lx -Bya+ly -Bza+lz -BwsENZ1+b -px135/40/0
Yeap, this one looks buggy. Here, removing the 1 makes no difference.
I seem to remember that -p still has some weird behaviors in some corner cases. This works
gmt psbasemap -R0/10/0/20/0/30 -JX5c/10c -JZ15c -Bxa+lx -Bya+ly -Bza+lz -BwsENZ+b -p135/40/0 -png lixo
-Bswnez1
What is that 1 doing there? Without it it works fine.
The corner on the xy plane at which the z-axis is drawn. Number from 1 to 4.
I seem to remember that -p still has some weird behaviors in some corner cases. This works
gmt psbasemap -R0/10/0/20/0/30 -JX5c/10c -JZ15c -Bxa+lx -Bya+ly -Bza+lz -BwsENZ+b -p135/40/0 -png lixo
Yes it works because the default is -pz. But I need -px to shift the yz-plane along the x-axis (as the xy-plane is shifted along the z-axis in the first picture).
Ah, yes. Since I never used those corner options I forgot about them (and pretending to remember all -B varieties is high presumption).
I think this one is easier to interpret and shows better the bug. Notice that I changed the y limits to show that it's not mixing y and z coordinates
gmt psbasemap -R0/10/0/25/0/30 -JX5c/10c -JZ15c -Bxa+lx -Bya+ly -Bza+lz -BwsENZ1+b -px135/40/5 -png lixo
-p is somehow mixing the dimensions sizes. See this
gmt psbasemap -R0/10/0/25/0/30 -JX5c/10c -JZ15c -Bxa+lx -Bya+ly -Bza+lz -BwsENZ1+b -py135/20/0 -png lixo1
But now we change the size of the z axis to the same as y, we get the correct plot
gmt psbasemap -R0/10/0/25/0/30 -JX5c/10c -JZ10c -Bxa+lx -Bya+ly -Bza+lz -BwsENZ1+b -py135/20/0 -png lixo2
No, this is still incorrect. Pay attention to the y- and z-axes, they are parallel.
The plane is correct. The labels not
gmt psbasemap -R0/10/0/25/0/30 -JX5c/10c -JZ10c -Bxa+lx -Bza+lz -BwsENZ1+b -py135/20/10 -png lixo
Agree. In your first drawing, the plane is also shifted correctly, only the frame is drawn incorrectly.
Looking better at this I'm no longer convinced that this is a bug. What it does is the, useless, re-projection of one of the planes on another wall. And not using a cube the plane sides have do the same size as the wall where they are projected and hence we see what we see.
But on a more useful exercise, I'm trying to plot an image one the sides of a cube (that way well be the vertical sides of a grdview
plot). And here we have bugs as well.
This one is correct (commands in Julia but with plain GMT generated syntax below)
julia> basemap(R="-75/-60/-50/-40/0/999", JZ=8, J=:merc, p=(135,30), Vd=1)
psbasemap -R-75/-60/-50/-40/0/999 -JM15c -Baf -Bza -JZ8 -p135/30 -P -K > c:\TMP/GMTjl_j.ps
julia> image!("@maxresdefault.jpg", pos=(map=true,anchor=(-75,-50), width=(15,8)), p="y135/30", show=1, Vd=1, name="atorig.jpg")
psimage @maxresdefault.jpg -R -J -py135/30 -Dg-75/-50+w15/8 -K -O >> c:\TMP/GMTjl_j.ps
Now let's try to move it along the latitudinal axis. It wrongly moves it along the zz axis
julia> basemap(R="-75/-60/-50/-40/0/999", JZ=8, J=:merc, p=(135,30), Vd=1)
julia> image!("@maxresdefault.jpg", pos=(map=true,anchor=(-75,-48), width=(15,8)), p="y135/30", show=1, Vd=1, name="moveatlat.jpg")
psimage @maxresdefault.jpg -R -J -py135/30 -Dg-75/-48+w15/8 -K -O >> c:\TMP/GMTjl_j.ps
@remkos do you still remember where is the code that deals with this?
More work and more comprehension. The above image is not bugged either. It's raised in the xz plane because I first moved it up along lat with the Dg-75/-48
(origin is at -75,-50) and it was the -py135/30
final rotation that put it in that position.
The real problem that I'm facing right now is that the z in azim/elev/z
is ignored. Doing the trig in Julia to compute the necessary X,Y offsets I can now
It was only designed to work on those three planes as illustrated in @joa-quim 's last post. I remember from back when I created the implementation (>10y ago) that particularly the one illustrated before did not work. The transformation matrix is actually not that difficult for the image projection, but I think Ghostscript appears to have limitations when negative numbers end up in it. I never wrote those out (in frustration). But know there are. The frames were later many times modified. I won't claim they were working 100% in the past, but also abdicate responsibility for it. In any case the relatively simple transformation approach has faults and they may be due to limitations in Ghostscript.
Remko, what I did was to compute the missing z feature obedience in terms of -X<off>, -Y<off>
(had to resort to mapproject to compute the new origin along the axis I wanted to slide on). We can´t blame Ghostscript for that. I tried to see if I could do the same thing in C but the code is very complicated for me to decipher it.
And note also that plotting on the North side is not currently possible because it needs that z. Only the South side should work well.
First, the command
gives an error
If I replace "sw" with "ws" or "s" with "S" in the last -B option, the command works fine. The bug is small but curious.
Second, when shifting the xy plane by zlevel parameter of the -p option, the "+b" flag does not draw the bottom face of the cube
Also, the manual says
but some of the drawn lines are not foreground.
Third, the command
produces a result that I find it difficult to interpret. It looks like the z-axis is pointing wrong.