Get tighter w/e/s/n domain for general perspective projection#5776
Get tighter w/e/s/n domain for general perspective projection#5776PaulWessel merged 3 commits intomasterfrom
Conversation
For various reasons we need to determine the encompassing w/e/s/n rectangle in degrees for all proejction settings. For the general perspective projection this is complicated by the fact that for some projection parameters the map window is the intersection of a rectangle and a sphere, yielding an odd rounded octagon. We then search along this perimeter and determine the extreme longitude/latitude values. However, should any of the geographic poles be inside this polygon then we just set w = 0, e = 360 and update the max or min latitude. That last step did not work for the genper because we ahd just copied/pasted what is done for other azimuthal projections. This PR implements this correctly by determining of those pole points is inside the spherical polygon clip path.
|
Anyone having a look at this one? |
Soon |
|
Is there any test? Or should approve it directly? |
|
No tests since it is just an internal improvement. If you have time to run all the tests (cd to build, run |
Esteban82
left a comment
There was a problem hiding this comment.
I try it. Nothing funny but I not sure if I do it well.
|
Does your test command end with something like this: |
|
FYI, to be able to build and run the tests you need to set things in cmake/ConfigUserAdvanced.cmake, e.g. otherwise the check stuff does not work I think. |
|
I did it wrong. I will have to edit the UserAdvance. |
|
No worries, it is a bit unclear - let me know if you run into any problems. |
|
I got this: |
|
Great, I think imgtrack.sh requires the img file to be downloaded, while longbasemap.sh definitively requires some more cmake settings. I have You can look in rbuild/Testing/Temporary/LastTest.log and search for those three and see what it says. |
|
Since @federico's three failures are not related to -JG I will merge this PR. |
For various reasons we need to determine the encompassing w/e/s/n rectangle in degrees of a map for all projection settings, such as for calling gmt_map_setup or finding grid bounds. For the general perspective projection this is complicated by the fact that for some projection parameters the map window is the intersection of a rectangle and a sphere, yielding an odd rounded octagon. We then correctly searched along this perimeter and determined the extreme longitude/latitude values. However, should any of the geographic poles be inside this polygon then we must set w = 0, e = 360 and update the max or min latitude. That last step did not work for the genper because we (the royal we) had lazily just copied/pasted what was done for other azimuthal projections. This PR implements this correctly by determining of those pole points is inside the spherical polygon clip path. All tests pass.
So not a significant bug in that nothing breaks, but this should reduce the number of remote tiles needed when blending together a grid for a region when using this projection, thus speeding things up. I noticed this when doing the testing of #5753 (as did @Esteban82 for the nigh/day plotting) that we were getting too crude images in the early stages. That is when the old calculations returned 0/360 when in fact a much tighter limit on longitudes were correct.