Bug #603

incorrect lines drawn by psxy(core) 5.1.1 (r12968) [64-bit], CentOS 6.5 Linux

Added by Roger about 3 years ago. Updated over 2 years ago.

Status:ClosedStart date:2014-08-12
Priority:NormalDue date:
Assignee:Paul% Done:

100%

Category:-
Target version:Candidate for next bugfix release
Affected version:all Platform:

Description

I have noticed this problem for some time (although infrequently) with our processing scripts, operating under both GMT4 and GMT5. We are drawing a large UTM plot which includes various quasi-rectangles bounding regions of interest. These rectangles are usually (and correctly) partially clipped by the main plot boundaries, e.g., only portions of one or more sides of such a rectangle may be drawn when it is not wholly contained within the plot, which is almost always the case. On occasion, however, we get stray diagonal lines drawn across the plot because such a rectangle is not correctly drawn/clipped. I have isolated the following example which incorrectly draws one such rectangle:

psxy -A -R-131.74249/9.8087739/-131.65578/9.883111r -Ju9/1:47500 -L <<END >/tmp/psxybug.ps
-131.69539 9.882795
-131.60807 9.88348
-131.60749 9.80983
-131.69480 9.80915
END

The psxy output from the above contains the following relevant material – note the diagonal line as commented by me:

%BeginObject PSL_Layer_1
0 setlinecap
0 setlinejoin
3.32551 setmiterlimit
4 W
5208 8107 M
4324 0 D
-4325 -8107 D !!!!!!! diagonal line here !!!!!!!
5208 8107 M
S
%EndObject

After some experimentation I noticed that ridiculously subtle tweaks to either the -R corner points or the coordinates supplied to psxy on stdin will make the problem go away. The following example is precisely identical to the first except that the y-coordinate supplied on the first line read by psxy has been changed from 9.882795 to 9.882794:

psxy -A -R-131.74249/9.8087739/-131.65578/9.883111r -Ju9/1:47500 -L <<END >
/tmp/psxybug.ps
-131.69539 9.882794
-131.60807 9.88348
-131.60749 9.80983
-131.69480 9.80915
END

Output from this command contains the following, with no diagonal line:

%BeginObject PSL_Layer_1
0 setlinecap
0 setlinejoin
3.32551 setmiterlimit
4 W
5208 8107 M
4324 0 D
5207 0 M
1 8107 D
S
%EndObject

I don't see anything particularly significant about 9.882794 vs. 9.882795 with respect to either the -R corner points or any of the other psxy input coordinates, although it clearly makes some difference somewhere, perhaps as an arithmetic precision issue, e.g., maybe it makes a line intersect a vertex instead of an edge, etc. Both the -R corner points and the input coordinates supplied to psxy in our scripts are generated by other script code, of course, so I don't have much control over them. We actually use higher precision, which I diminished in the above examples just to find the crossover point between buggy and correct behavior. Actual precision is more like:

psxy -A -R-131.742492674000/9.808773999345/-131.655783335000/9.883111414540r
-Ju9/1:47500 -L -W0.5p,0 <<END > /tmp/xx.ps
-131.695397722000 9.882795676250
-131.608078270000 9.883483995500
-131.607499857000 9.809839092070
-131.694800000000 9.809155999730
END

Any ideas?

Thanks!

Associated revisions

Revision 13471
Added by Paul about 3 years ago

Address issue #603 and related issues re oblique annotations at corners

History

#1 Updated by Paul about 3 years ago

  • Status changed from New to In Progress
  • Assignee set to Paul
  • Target version set to Candidate for next bugfix release
  • % Done changed from 0 to 10

There are some hard-to-pin-down irregularities with how points are deemed to be inside or outside the region. I found different slop values (1e-4 vs 1e-8) being used in different code sections. Changing them both to 1e-8 caused your test to run correctly but then other examples started to behave a bit oddly (e.g., missing an annotation exactly at the corner in an oblique projection). I have added a modified test based on your case as a new test (test/psxy/lineclip.sh) and saved the correct PS file. It will take some more forensic work to determine where this instability resides so it will continue to fail for now, but at least we have a record, this open issue, and some test scripts to work from.

#2 Updated by Paul about 3 years ago

  • Status changed from In Progress to Resolved
  • % Done changed from 10 to 100

While the initial post had to do with polygon clipping, I had to track down issues in the crossing/clipping machinery that also affected oblique map annotations. Many annotations exactly at a map corner were skipped due to internal round-off issues related to this issue. I've made numerous changes to that machinery. All tests involving these features now pass after updating several original PS files. The test added for this particular issue now passes. These changes have been applied in r13471 and may eventually be ported back to GMT 4 to the extent possible.

#3 Updated by Joaquim over 2 years ago

  • Status changed from Resolved to Closed

Also available in: Atom PDF