psxy no longer draws line from outside to outside across region
|Target version:||Candidate for next bugfix release|
|Affected version:||all||Platform:||Mac OS X|
The following command
(echo -e -100 -100;echo 100 100) | psxy -R0/10/0/10 -JX10c -Bafg -W2p,red > tmp.psused to draw a diagonal line across the region. At least at some time before the current version 5.2.0_r13823.
This does work though:
(echo -e 0 0;echo 100 100) | psxy -R0/10/0/10 -JX10c -Bafg -W2p,red > tmp.ps
I suspect this is to do with recent changes concerning plotting segments that are partially outside the region.
Nonetheless, I think the earlier case should plot a diagonal line, despite both end points being outside the region.
Probably also affects 5.1, but having checked.
#6 Updated by Paul almost 7 years ago
No, it does handle that (that function passes the work to specific functions for geo. cartesian, radial etc). Otherwise you would have this problem all the time. I remember making an adjustment for something similar to your case (points far outside a region on both sides) but it was meant to address geographic data only. I will see if I can find exactly where that was implemented. Note your example work with 50 instead of 100 everywhere so I think it is a geo/Cartesian confusion case.
#7 Updated by Remko almost 7 years ago
- Assignee changed from Remko to Paul
OK. I may have been too quick drawing that conclusion. At least, I can tell you that in my case (with 100) gmt_map_crossing would return 0, instead of 2.
If I comment out the first half of gmt_map_crossing (the if/else if/else bit), then I get a proper value of 2.
So if not in gmt_map_crossing, then the error is in the *GMT→current.map.overlap routine linked when using a linear projection (i.e. gmt_rect_overlap).
Handing it over to you again ...
But note! This error is also there in GMT4, where you did not change anything, I believe.
#8 Updated by Paul over 6 years ago
- Status changed from In Progress to Resolved
- % Done changed from 0 to 100
Fixed in r13844 (GMT 5) and r10288 (GMT 4).
The problem was that an earlier fix to deal with a similar situation for geographic data shared code with the regular Cartesian case (in which the above should always be allowed). The solution was to separate out a new gmt_cartesian_overlap function in gmt_map.c. I also added a new test script (psxy/longjump.sh) that uses the above example for both Cartesian and Mercator plots). This script complements the earlier test script psxy/rectclip.sh.