The -R string from three coutries crossing 180 was bad #8266
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The USA, Russia, and Fiji are the only country polygons that cross lon = 180. That gave us odd -Rw/e/s/n strings such as 172.436/-66.9489/18.9099/71.3907 for the US. With west > east we run into trouble when building the list of remote file tiles (e.g., the @earth_relief ******_p.jp2 that needs to be downloaded). The result was a blank map. I verified this was the same with GMT 6.4 so it is not a new bug; it has probably been there since Day 1 of remote data set implementation but nobody used -RUS, -RRU or -RFJ before. This PR simply does the sanity check that if if east < west we subtract 360 from west, since it is assumed all global files are on the -Rd layout. With this fix the plots for the three countries now works.
|
I would go with 2 or 3. I think 1 is a bad idea. |
It works well for me with GMT 6.4.0 on macOS: |
|
OK, maybe you had the necessary tiles. I started with scratch and it was unable to get them just for those three examples. |
We have tons of open bugs reports. I have built the Win installers 3 of 4 times (installers build is not an instantaneous step). Let's stop now. |
|
I am fine with that, too. |
|
Just in case you're still interested, the bug was introduced in #7805. |
Hm. Not sure. For me, it works for both Windows with GMT 6.4 and Linux with GMT 6.4.0_965606f_2022.03.14. But it fails with GMT 6.5 on Windows. |
14 tasks
I see. So that section sort of assumed that west < east but for those three countries gmt_DCW_operation returns 172.436/-66.9489/18.9099/71.3907 for the US and that get caught in those tests. So perhaps 6.4 was OK for the images if you already had the tiles. I did not and I verified there was a problem selecting the right tiles and download then with the above bug. Obviously work around with coordinates. FYI, just getting the -R string (which I think @joa-quim was after in #7805): So first and last are the same ±360 and because the data sets are in -Rd I picked the negatives. |
Give more sensible warning if remote server is set or not set but cannot find file.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The USA, Russia, and Fiji are the only country polygons that cross lon = 180. That gave us odd -Rw/e/s/n strings such as 172.436/-66.9489/18.9099/71.3907 for the US. With west > east we run into trouble when building the list of remote file tiles (e.g., the @earth_relief ******_p.jp2 that needs to be downloaded). The result was a blank map. I verified this was the same with GMT 6.4 so it is not a new bug; it has probably been there since Day 1 of remote data set implementation but nobody used -RUS, -RRU or -RFJ before. This PR simply does the sanity check that if if
east < westwe subtract 360 from west, since it is assumed all global files are on the -Rd layout. With this fix the plots for the three countries now works, as shown below (these were all blank frames before):gmt grdimage @earth_relief_05m -B -RUS -png USAgmt grdimage @earth_relief_05m -B -RRU -png RUgmt grdimage @earth_relief_05m -B -RFJ -png FJSince this is a long-standing bug we can choose what to do:
Please opine. Note @joa-quim this particular PR has nothing to do with code freeze concern since it was there so long.