gmt
gmt copied to clipboard
Wrong projection inside `inset`
See this. The inset map is wrong. The red dot should be on the coastline
gmt begin inseto png
gmt coast -Rd -JN0.0/14c -Baf -BWSen -Ggray -W0.5 -Da
gmt inset begin -F+gwhite+p0.5,blue -Dg63/30+jBL+w1.4
gmt coast -R65.9/66.7/25.1/25.9 -JM1.4 -Dfull -Gorange -W0.5
echo 66.6666667 25.2833333 | gmt plot -Gdarkred -Sc0.1
gmt inset end
gmt end show
If we make it echo 66.6666667 25.2833333 | gmt plot -Gdarkred -Sc0.1 -JM1.4
then the inset map is correct. But I find it very weird that adding -JN0.0/1.4c
instead, also plots the correct result. So, what is the second (in the inset plot) plotting command doing?
Needs to be -JM? I think, since there is margins
Why any -J? Projection was set in the previous command (the coast
one)
The point is the coast command cannot know the needed size of the actual plot area given the region etc. So you do
gmt coast -R65.9/66.7/25.1/25.9 -JM? -Dfull -Gorange -W0.5
I hope.
-JM? sends a
coast [WARNING]: 1.40.551181 not a valid number and may not be decoded properly.
plot [WARNING]: 1.40.551181 not a valid number and may not be decoded properly.
inset [WARNING]: 1.40.551181 not a valid number and may not be decoded properly.
The -JM1.4
was generated by GMT.jl. The idea, I think, was also to have a too wide plotting area for the inset and get it clipped by the inset size
Too confusing stuff for a Friday night.
Certainly too confusing after a beer in some random hotel lobby.
When I run as I suggest with -JM? it works fine, just as intended:
gmt begin inseto png
gmt coast -Rd -JN0.0/14c -Baf -BWSen -Ggray -W0.5 -Da
gmt inset begin -F+gwhite+p0.5,blue -Dg63/30+jBL+w1.4
gmt coast -R65.9/66.7/25.1/25.9 -JM? -Dfull -Gorange -W0.5
echo 66.6666667 25.2833333 | gmt plot -Gdarkred -Sc0.1
gmt inset end
gmt end show
Yes, and it actually even works without the ? (-JM). I do remember the ? but can't find any reference to it neither in the inset
nor the subplot
manuals.
But I'm confused. What if one wants to set the fig size inside the inset(/subplot)? Then next commands may suffer from effect described here.
And note that there is a margin between the orange land and the vertical lines of the inset box, which does not exist in my first figure. Possibly because no frame is being drawn.
Well, your desired region and projection yields a rectangle that you then try to fit in a 1.4c square box. So scale is adjusted so it fits inside that limit. I.e.,
gmt mapproject -R65.9/66.7/25.1/25.9 -JM1.4c -W
1.4 1.54264870648
Since it is higher than the width, it shrinks so the height is 1.4 and the width is 1.4/1.542..
That explains the side margins. But I'm still out on what to do if one sets a projection and a size in the first command. Well, other than repeat the full -J in subsequent commands.
I think you will have to set the +w to +w1.4/1.5426... But perhaps we need to check what is going on and possibly improve this to allow +w1.4/0 ?
I learned that you can specify the -R -J with inset and not set +w:
gmt begin inseto png
gmt coast -Rd -JN0.0/14c -Baf -BWSen -Ggray -W0.5 -Da
gmt inset begin -F+gwhite+p0.5,blue -Dg63/30+jBL -R65.9/66.7/25.1/25.9 -JM1.4c
gmt coast -Dfull -Gorange -W0.5 -B0
echo 66.6666667 25.2833333 | gmt plot -Gdarkred -Sc0.1
gmt inset end
gmt end show
Then it computes the right box needed.
Yep, that's actually documented
This is useful when you want the inset -R -J to also determine the inset size.
And clearly, we cannot have +w1.4/0 before there even is a -R -J later as in the original script.
So, the only thing that can be done is to repeat the -J of the first command in inset, in case it was given. Seems too much work for such a little, except that it can make a wrong plot. Raise an error instead?
Well, I am leaning more towards a bug. The inset sets a square 1.4c box. Then coast runs with the given -R -J and it learns it has to adjust the scale to fit. Somehow that knowledge should be passed along to all commands inside the inset.
Cannot look today as trying to sell the Nissan Leaf today and have to go soon to meet a person.