Let inset begin optionally take -R -J to determine inset size instead of via -D #5903
Conversation
See #5875 for background. This PR implements that suggestion and adds a new test inset2.sh to demonstrate it.
Add original for inset2.sh test
PaulWessel
added
the
new core module feature
PaulWessel
changed the title
There was a problem hiding this comment.
Nice!
Is it possible to show annotations for inset maps? For example, below the -Ba does not impact the inset map:
gmt begin
gmt figure test-inset png
gmt grdimage @earth_relief -R-51/-48/-24/-23 -JM15c -B -Cworld
gmt inset begin -DjBL+o0.1c -F+p1p,black -R-80/-28/-43/10 -JM2c
gmt coast -Wthin -Swhite -Ggray -Bafg -BwsNE
gmt inset end
gmt figure test png
gmt coast -Wthin -Swhite -Ggray -Bafg -R-80/-28/-43/10 -JM2c -BwsNE
gmt end show
I think that annotations fall outside of the inset. The issue is that the width of the inset is the same of the map. So the inset should take into account the extra space. PD: I am not completely sure. Maybe this was already fixed. |
|
I test it with ex 44 but with GMT 6.2 (not dev version) where I use -Baf
|
|
When -R -J is used with gmt inset you get exactly that size and that is the projection you have in the inset. So the only hope would be to add a margin to the inset dimensions I think. |
|
This all depends on annotation size etc but you can slap a -M2p/14p/2p/14p to that inset call and play with the numbers. |
Ok. BTW, what is the default units for -M? inches? I noticed that it is not clarified in the docs. |
|
Should be cm like any other dimensions (only exception I think is font sizes which are assumed to be in points). |
|
It seems like a lot of work to get a nice tiny inset with annotations, e.g.: I guess I think that insets showing the entire world or a large chunk of it may not really benefit much from having separate annotations. Do we really need to know that South America has these coordinates, when the main plot has the coordinates for the data we actually are presenting? Perhaps a personal choice but I would not bother to add tiny tick marks, tiny fonts etc and worry about it all fitting. But, as you see, you can if you want to. |
Good to know that it's possible, thanks. |
|
Any other concerns before we merge this one? |
Looks good to me. |
|
I just addressed @Esteban82 comment on units for margins in both inset and subplot. |
|
Looks good for me too. |
I think it would be good to have an easy way to do this. I agree that is has no much sense for insets. But I think it could be good to set the dimensions of canvas in movies. In some occasions, I just want to get the animation and I don't care about the final dimension of the canvas. |
|
Could you explain this differently? I do not understand what you mean related to canvas and movies. You mean not specifying -C and let it be found from main.sh as the dimensions of the cropped frame? You would have to specify dpi though, right? So if you gave -C100c you want a 100 dots per cm movie frame of whatever size that is given your script? This would mean (1) need to run main once to call psconvert and determine the bounding box size, then (2) have to assume all frames are the same size. |
|
Yes. Like with any figure. I define the map width, I then add some stuffs like annotations and colorbar outside the map and finally psconvert gives me the bounding box size (which is slighter bigger than the original width). |
|
And what about dpi? Via -C, or default to the same as psconvert [300i]? Probably would give 4k-size movies... |
|
Mmm, I haven't think about dpi. The default 300 dpi sounds good. Or maybe with -C?/?/dpi?? |
|
I think -Cdpi is enough for that. If you compose on a typical piece of paper (say make a plot around 24x13cm which is the HD format setup now) then 300 is pretty large. The current scheme is 80dpc or 200dpi:
But, I think it is still the best default since it is what GMT_GRAPHICS_DPU currently is set to. So to get this to work, post 6.3, would be to
One issue is the pre.sh script which may need to run to create data to even run the movie, and it may also create a background PostScript plot. That plot needs to know the canvas size too, which we don't know yet. SO it gets a bit messy in having to run it twice. |
|
Ok. Sounds good. I think that might be an issue with for the bounding box for the animation 03. |
|
Right, so it cannot work for those types of animations, only the static frame one. Which begs the question if all the above work is really worth the effort... |
|
I think so. I will definitely use it. |
See #5875 for background. Normally, gmt inset begin is called without an explicit -R -J and instead it picks those up from the main figure history file that it is setting up an inset for. In that case, users must specify the inset size via -D...+w. However, there are times when the user wishes to specify the inset size indirectly via the -R -J settings that will be used within the inset itself. This PR implements that suggestion and adds a new test inset2.sh to demonstrate its use.