Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

inset -R -J -X -Y history #6288

Open
gd-a opened this issue Jan 31, 2022 · 10 comments
Open

inset -R -J -X -Y history #6288

gd-a opened this issue Jan 31, 2022 · 10 comments
Assignees
Labels
bug Something isn't working

Comments

@gd-a
Copy link
Contributor

gd-a commented Jan 31, 2022

Not sure it is a bug but it seems that inset doesn't retain history within its block. Is it on purpose ?

Guillaume

@gd-a gd-a added the bug Something isn't working label Jan 31, 2022
@gd-a
Copy link
Contributor Author

gd-a commented Jan 31, 2022

... nevermind ... sorry

@gd-a gd-a closed this as completed Jan 31, 2022
@gd-a gd-a reopened this Jan 31, 2022
@gd-a
Copy link
Contributor Author

gd-a commented Jan 31, 2022

Ok ... I've retried ... it does conserve -X -Y but neither -R or -J

 gmt inset begin -DjBR+w3.5c+o0.25c/0.25c
		gmt coast -Rg -JG0/0/3c+w45 -Dc -Ggray -A5000 -Bg -Wfaint -X0.25 -Y0.25
	        gmt plot  <<- EOF
> delta-line -Wthin,black -Am
0 -89
0 89
EOF
    gmt inset end

@PaulWessel
Copy link
Member

It should retain -R -J once set inside the inset box. Could you help by supplying a full test script?

@gd-a
Copy link
Contributor Author

gd-a commented Jan 31, 2022

gmt begin test png
gmt basemap -R0/1/0/1 -JX10c -B
gmt inset begin -DjBR+w3.5c+o0.25c/0.25c
                gmt coast -Rg -JG0/0/3c+w45 -Dc -Ggray -A5000 -Bg -Wfaint -X0.25 -Y0.25
                gmt plot  <<- EOF
> delta-line -Wthin,black -Am
0 -89
0 89
EOF
    gmt inset end
gmt end show

If I interpret correctly the black line placement, it seems that -JG0/0/3c is not respected (it takes 3.5c)

@PaulWessel PaulWessel self-assigned this Feb 4, 2022
@PaulWessel
Copy link
Member

I think for gmt inset you have to stick with the rules for the inset:

  1. The projection should be given with ? as the scale or width
  2. Use -M if you want to remove some of the inset space for margin padding

A successful script based on what you have above does not use -X -Y at all and looks like this:

gmt begin test png
	gmt basemap -R0/1/0/1 -JX10c -B
	gmt inset begin -DjBR+w3.5c+o0.25c/0.25c -F+pfaint -M0.25c
		gmt coast -Rg -JG0/0/?+w45 -Dc -Ggray -A5000 -Bg -Wfaint
		gmt plot  <<- EOF
		> delta-line -Wthin,black -Am
		0 -89
		0 89
		EOF
	gmt inset end
gmt end show

Yet there are clearly documentation issues here, so I am not quite sure what is the best way forward here. Here are a bunch of concerns or issues.

  1. Because the user cannot easily know what map projection scale/width to use in the inset, we intended this to be a free parameter, signified with ?. However, I also played (later) with the idea of simply leaving it off (-JG0/0/+w45) but that is not tolerant (yet) of the trailing modifier. So for this projection, ? works, for other projections without a modifier you can leave it off. Not consistent.
  2. We have some inset tests that fails to use ? and specifies the projection width (that match the inset width). Lame.
  3. Our inset man page example uses the "skip the arg" format.
  4. The size of the inset is eaten away by the amounts specified in -M. In contrast, for subplots this is done via -C since in subplot, -M is used for the margins between panels, not space inside them. We should fix this in inset.

My proposal is this:

  • If possible, we should allow -X -Y to actually work since there may be things that can only be done that way. I am not sure if this is doable or too hard or easy without looking. Remember, we are playing with the individual history files to make this work in the first place. Clearly, in the above case, the shift of 0.25c did not happen until after the coast plot was done, which is why things are offset (echo 0 0 | gmt plot -SE-200k -Gred makes this clear). If it is not possible (or too hard for now) then we should reject the use of -X -Y inside insets.
  • We should replace the use of -M in inset with -C (but allow for -M due to backwards compatibility). Not sure what I was smoking at the time to select -M here in the first place.
  • We need to be consistent in both parsing and documentation on whether it is ? or missing argument. I suspect this is the same issue in subplot.

PaulWessel added a commit that referenced this issue Feb 4, 2022
While the -X and -Y options serve no purpose in the gmt inset call, and are not listed as allowable options neither in synopsis nor documentation, we did in fact not prohibit them, leading to troubles (#6288).
This PR slams that door shot.  No example or tests used -X -Y since that was never the plan.
@gd-a
Copy link
Contributor Author

gd-a commented Feb 4, 2022

So I would have to use something else than inset in my case.
The red arrow in here can not, to the best of my knowledge, be plotted outside the geographic boundaries without -X, -Y (and eventually the projection change)

PaulWessel added a commit that referenced this issue Feb 4, 2022
While the -X and -Y options serve no purpose in the gmt inset call, and are not listed as allowable options neither in synopsis nor documentation, we did in fact not prohibit them, leading to troubles (#6288).
This PR slams that door shot.  No example or tests used -X -Y since that was never the plan.
@PaulWessel
Copy link
Member

I am not completely done with this issue yet, but the intent is that you should be able to use -X -Y on commands inside your inset begin/end clause, but not with inset itself. There may be issues related to this as well but that is for the next steps. The key issue here is that gmt inset itself was never meant to take -X -Y.

@maxrjones
Copy link
Member

There's an issue with ex44.sh after the recent inset changes. It's odd because the script does not use -X or -Y, but here are the error messages:

bash ex44.sh 
inset [ERROR]: Unrecognized option -X
inset [ERROR]: Unrecognized option -Y
inset [ERROR]: Unrecognized option -X
inset [ERROR]: Unrecognized option -Y
inset [ERROR]: Unrecognized option -X
inset [ERROR]: Unrecognized option -Y
inset [ERROR]: Unrecognized option -X
inset [ERROR]: Unrecognized option -Y

@PaulWessel
Copy link
Member

Thanks, I will look at it later today or the weekend (busy day for other matters)

@gd-a
Copy link
Contributor Author

gd-a commented Feb 4, 2022

Thanks @PaulWessel, good luck !
(in the meantime I've bodged my code to circumvent the issue)

@maxrjones maxrjones added this to the 6.4.0 milestone Mar 23, 2022
@seisman seisman modified the milestones: 6.4.0, 6.5.0 Jun 25, 2022
@PaulWessel PaulWessel removed this from the 6.5.0 milestone Jul 19, 2023
@gd-a gd-a closed this as not planned Won't fix, can't repro, duplicate, stale Feb 26, 2024
@gd-a gd-a reopened this Feb 27, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

4 participants