Without knowing what you are trying to do …
Maybe this example helps?
https://www.generic-mapping-tools.org/GMTjl_doc/examples/projections/02_proj_examples/#oblique_mercator
My apologies @Joaquim for not being specific enough:
I’m still struggling with my “global domain wrap around world map”. While I do get your example from your post above to work on my machine I fail in moving the central meridian to the east for a better balanced map. See discussion in my post above.
So far I toyed around with proj’s +pm option but wasn’t able to get it to work properly:
using GMT
cl = coast(dump=:true, res=:crude, region=:global);
cl_right = cl .+ 360;
cl_left = cl .- 360;
cl_vdg = lonlat2xy(cl, t_srs="+proj=vandg +pm=20");
cl_right_vdg = lonlat2xy(cl_right, t_srs="+proj=vandg +over +pm=20");
cl_left_vdg = lonlat2xy(cl_left, t_srs="+proj=vandg +over +pm=20");
tmp = cat(cl_left_vdg, cl_vdg);
cl3_vdg = cat(tmp, cl_right_vdg);
plot(cl3_vdg, show=1)
I highly assume it is only due to my lack of Julia-fu. Maybe you as a Julia guru see my mistake right away?
Honestly, I don’t know who to blame here. The projection worked fine but 20 degrees of the Alaska are trimmed out in the West and wrapping lines show up. It’s not impossible that this is proj bug.
Glad you are not blaming me 
I’ll investigate further.
With master, but only if you are not plagued with some building stubbornness and you get a recent date
julia> GMT.GMTdevdate
2023-04-18
You can do
G = worldrectangular("@earth_relief_30m_g", pm=30, latlim=80);
imshow(G, shade=true)
and get (ignore the ERROR 10: Pointer 'hBand' is NULL in 'GDALGetRasterDataType'. that started to pop up from I don’t know where nor why).
? worldrectangular print the using options
1 Like
G, cl = worldrectangular("@earth_relief_30m_g", pm=30, latlim=(80,-70), coast=:low);
imshow(G, shade=true, show=false, cmap=:geo)
plot!(cl, show=1)
I’m thinking in using this example in the GMT.jl paper.
1 Like
Back from work – this looks awesome, @Joaquim! I’ll give it a run as soon as I’m done upgrading my number crunching rig. Great work!
Not sure where I messed up:
julia> GMT.GMTdevdate
0001-01-01
Needs more investigation on my part.
This is a transition period in GMT.jl where a new method to install GMT is implemented. Basically, just update GMT.jl (] up) and things should be solved. Note that after updating the GMT version that GMT.jl use is a Julia own built one and not the one you compile. I have a recipe for those who want to force using the system wide GMT (see https://github.com/GenericMappingTools/GMT.jl/blob/master/src/GMT.jl#L30) but the good news is that new GMT installation (that is only visible from Julia) was build with imagetexture branch.
Unfortunately still no joy:
julia> GMT.GMTdevdate
0001-01-01
(@v1.8) pkg> up
Updating registry at `~/.julia/registries/General.toml`
No Changes to `~/.julia/environments/v1.8/Project.toml`
No Changes to `~/.julia/environments/v1.8/Manifest.toml`
julia> using GMT
julia> GMT.GMTdevdate
0001-01-01
Edit: Julia reports the following version:
julia> using Pkg
(@v1.8) pkg> st GMT
Status `~/.julia/environments/v1.8/Project.toml`
[5752ebe1] GMT v0.44.8This is new stuff in master. Do ] add GMT#master
Ah, thank you @Joaquim. Now I get
julia> GMT.GMTdevdate
2023-04-13
which isn’t the date you were showing in your post above.
Running your code:
G, cl = worldrectangular("@earth_relief_30m_g", pm=30, latlim=(80,-70), coast=:low);
imshow(G, shade=true, show=false, cmap=:geo)
plot!(cl, show=1)
Gives me a plot but not like yours:
Do I need to invoke the master branch somehow? I did the usual using GMT and also tried using GMT#master.
That’s fine. It is the date when GMT was built in BinaryBuilder. Mine is different because on Windows what is used is the installed GMT (the one I build) or our installer.
I’m having different errors from yours in WSL, which is also quite strange but it seem to indicate that I have non-committed stuff. Well I know I do, but didn’t think it was needed to reproduce this example. I’ll come back when I update with my local changes.
No, just do the usual using GMT
This is indeed very strange. I updated master but get the same as you in WSL. I wonder if I screw something with the instructions to build GMT in BinaryBuilder (Julia stuff) and those GMT binaries are not updated to what it needs for this. The shufflings with bits of the global grid are not even done and we don’t see a full filled rectangular grid.
The only way I see for now on unix is to see if these intended instructions to make use of system wide installed GMT do work.
# The file deps/deps.jl is created by compile from the deps/build.jl
# On Windows we use a system wide GMT if it is found from path or install it from a GMT installer. It is a MSVC binary.
# On Unix the default is to use the GMT_jll artifact. However this can be changed to use a system wide GMT installation.
# To swap to a system wide GMT installation, do (in REPL):
# 1- ENV["SYSTEMWIDE_GMT"] = 1;
# 2- import Pkg; Pkg.build("GMT")
# 3- restart Julia
#
# Note the above will work up until some other reason triggers a Julia recompile, where the JLL artifacts
# will be used again. To make the ENV["SYSTEMWIDE_GMT"] = 1 solution permanent, declare a "SYSTEMWIDE_GMT"
# environment variable permanently in your .bashrc (or whatever).
But to keep teasing, this is what it was supposed to be possible by now. @pwessel how difficult would it be to let custom annotations have slanted ticks?
1 Like
I am surprised they are not slanted unless MAP_OBLIQUE_ANNOT has been set or changed (?)
They can’t slant because they are custom annotations and as far as they know, they are plotting on a cartesian axis.
Sure, if this is added as a Cartesian overlay then there are no slanting. I cannot see a simple method to overcome that.
@KristofKoch, the problem is more serious. The failure in unix is coming from the gdalwarp command not doing its job. Unfortunately, there are error messages issued by GDAL that I’ve not been able to capture in the Julia wrapper and maybe this is one of these cases. This makes even more needed to test if my recipe above makes it work.
It’s a GDAL bug. On Windows this works. It screams a lot but it works (it doesn’t for .nc)
gdalwarp -t_srs "+proj=vandg +over +pm=30" earth15.grd lixo.tiff
but not on linux. It screams equally but doesn’t work
… unless we repeat the command. Then no screaming and it works. That is, when overwriting it works but not when the file doesn’t exist.
What about inside annotations? Is it possible to have them oriented along meridians and parallels? Or does the same problem apply as with outside annotations?