-
Notifications
You must be signed in to change notification settings - Fork 382
Make the -J question-mark for subplots and insets optional #4758
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
Conversation
Given the issues with csh discussed in #3916, this PR makes the questionmark optional. It even allows for a lack of final slash.
Having slept on this, I think option 1 is the only feasible solution. That way we are 100% backwards compatible and can allow the ? to be there or not. Will wrap that up tomorrow. |
To be sure I get this right I looked at all the -J forms we have. Remember that the current system using ? in places for scales works (except under csh perhaps). So if I detect a ? in the -J string I do nothing. If there is no ? character then I need to examine if the user specified a scale/width or if they left it off for us to add the ?. Here they are classified based on syntax: 1. Projections that always ends in
For these we check if string ends with / and if so we append ?. 2. Projections that may not have a slash (e.g., -Jm):
If they do use the optional arg then there is a slash and they move up to the simple category 1. Otherwise, we check if there is a number where the scale should go, and if not we append ?.
Because -Jx may use a slash to separate two different scales we examine this projection separately, so that -Jx/ becomes -Jx?/? and -Jx becomes -Jx?. We also look for the d,l,p stuff for degree, log, power. For the polar projection we similarly check if there is a scale or not after -Jp so that -Jp+a becomes -Jp?+a, etc. 4. proj syntax (-Jproj|EPSG:n) I do not think these are (yet) useable in plots but assuming they are/will be we simply need to watch for the two extensions Does @GenericMappingTools/core see any non-unique cases here or do I have them all covered? |
... all of this because there are 20 persons in the world that still use |
Well, as long as Dave Sandwell and his group are doing csh we kinda have to make it work. But this also shortens your typing (you save one ? per inset or panel. |
Require a trailing / if at least one another argument, or otherwise have no numbers after the projection code. Adjusted the demonstration inset script and docs. added complement script that tests -JX without ?.
I have completed this PR and stayed with the conservative option (1) above and followed the three projection cases to finish the implementation. Updated the docs accordinly and doc/scripts. Left most test scripts using ? as they were so they are exercised, but added on new without ? to test the many -JX perturbations (e.g., -J-/d -> -J-?/?d). Pinging @seisman, @joa-quim and @meghanrjones for final test and approval. |
I would like to move on and have this PR approved. Just to remind you, in testing I found that our documentation plot of insets (doc/script/GMT_inset.sh) looked like this:
Despite setting up the inset size and margin, the coast command in the inset still set the actual size of 1.4 inches. Per our GMT 6.0 documentation this should have been using the questionmark:
What this PR does is to relax the requirement of the question mark (which fails in csh), so that this is the preferred way:
All of these varients (but importantly the last two) give the same plot and is thus backwards compatible. The implementation actually replaces -JG120/30S/ with -JG120/30S/? and then calls the regular ?-parser. Please have a check if you'd like and then consider giving your approval(s). |
Description of proposed changes
Since the perfect map scale or width for plots placed in subplot panels or insets to fit that space exactly are unknown to the user, we introduced in GMT 6 the syntax that the user should supply "?" where normally a scale or width should go. GMT looks for these and replaces them with the computed quantities. This works fine, except we have since learned that some UNIX shells do not want to play nice (see #3916). Then what? We cannot let GMT csh scripts not work.
This PR implements an alternative scheme while still honoring the initial solution, and is thus backwards compatible. In the new scheme, the ? is not provided, yielding a missing argument. Most map projections have the size as the final argument, while Cartesian and polar can be more complicated. My implementation works this way: It looks for the -J argument to determine if it is of the form where the scale/dimension is missing and there is no ?, and if so inserts the missing question-mark(s). It then passes the modified argument to our existing parser.
With this PR, the following lists have valid -J arguments in insets and subplot panels and on the right is the converted argument:
etc. Running the tests with this PR yielded 7 failures:
Upon inspection, these were all due to these scripts actually spelling out the desired dimension of the inset or panel plot instead of relying on the magic (some where composed before I figured out the ? mechanism). Since it is allowed to actually give a manual size, I added a check that if a -J ends with a dimension indicator (c|i|p(, then we leave it alone. With that change all tests passes.
However, the reason this has a WIP is so we can discuss what to do. Insets and subplot panels are still a relatively new thing in GMT. It is likely that most users supply the ? in the -J option, and both the Julia and Python wrappers do that as well. However, we would currently fail if someone gave a specific projection and size without using a trailing unit, e.g. -JA-45/60/13. This of course goes against the magic of ? and also our recommendation of supplying dimension units in scripts to avoid side-effects when posting or sharing scripts - but users do this anyway. The only way to really avoid falling into that trap is to add much more checking so that we know exactly how many slashes each projection should have, and if there is an argument after the last one then do nothing. This is complicated by the fact that many projections have optional arguments, such as central meridian, and then it may not be possible to tell for sure. I do not want to attempt this coding.
I think we have these two options that both will simplify GMT syntax and fix #3916:
In both cases we need to update the documentation. We should also fix the above 7 script to use the auto magic and not provide bad examples in the cookbook.
Happy to entertain votes on this issue. I think option (1) is the conservative, safe choice, but open to comments.