Bug #657

psxy no longer draws line from outside to outside across region

Added by Remko almost 7 years ago. Updated over 6 years ago.

Status:ClosedStart date:2014-12-11
Priority:HighDue date:2015-01-01
Assignee:Paul% Done:


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.ps
used 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.


#1 Updated by Paul almost 7 years ago

  • Status changed from New to Feedback

Yes, very likely related to that. Presumably this can be fixed since not geographic. May not have time to look as I am in for a 24-hour shift getting my AGU poster work done.

#2 Updated by Remko almost 7 years ago

  • Affected version changed from 5.2-svn to all

This affects all GMT versions: 4.5.13, 5.1.2 and 5.2.0

#3 Updated by Remko almost 7 years ago

  • Due date set to 2015-01-01
  • Status changed from Feedback to In Progress
  • Assignee changed from Paul to Remko

Brought if down to insufficient logic in gmt_map_crossing. This been like this for awhile in fact.
I will assign this one to myself.

#4 Updated by Paul almost 7 years ago

Thanks Remko. I suspect what is there should only apply to geographic data and your example is Cartesian.

#5 Updated by Remko almost 7 years ago

No, I think the error is more widespread than that. gmt_map_crossing is generic, and I have the feeling it totally ignores even the possibility of having a line drawn from from outside to outside that could cross the region.

#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.

#9 Updated by Remko over 6 years ago

  • Status changed from Resolved to Closed

Closed as verified

Also available in: Atom PDF