Arc in the Wrong Place

If you are having problems with QCAD, post here. Please report bugs through our Bug Tracker instead.

Always attach your original DXF or DWG file and mentions your QCAD version and the platform you are on.

Moderator: andrew

Forum rules

Always indicate your operating system and QCAD version.

Attach drawing files and screenshots.

Post one question per topic.

Post Reply
TheEnglishPatient
Active Member
Posts: 35
Joined: Sun Feb 19, 2012 12:56 pm

Arc in the Wrong Place

Post by TheEnglishPatient » Wed Feb 18, 2015 8:35 pm

As I had record viewings on my earlier topic (Circle does not fit[solved]) but no answer to my latest addition for a couple of weeks can I ask for some help please by creating a new topic? If this cannot be solved I will go away and shut up (promise).

So, the issue simply is that arcs with very large radii show up in the wrong place.

First the fun part (our friends from Redmond):
Iluustration 7.1. shows a real digitised (railway-)track together with a segmented arc fit: The red circles are at 5 m radius around the original digitised points – the four blue lines are circular arcs calculated by non-linear least-squares fit through appropriate sub-sets (not highlighted here) of the points. These are rendered as 'EllipseGeometry' in C# WPF on a Win 8.1 System with Nvidia GeoForce GTX770M. The orange lines are 'Polyline' of points in 25 m distance along the respective arcs periphery, externally calculated using the very same centre and radius data.
Note that for the smaller two arcs (radius in the order of 1000m) EllipseGeometry and Polyline coincide, and pass visually closely by the digitised points – however, for the very large arcs (radius around 150,000 m) the EllipseGeometry is shown significantly (tens of metres!) off its true (orange) position.
Further investigation suggest, that the problem lies with the graphical representation/sub-system, as the mathematical arc solutions appear verifiable with spreadsheet arithmetic (i.e. double precision calculation).

Now for the serious bit:
A similar effect albeit only tens of centimetres could be observed in QCAD 3.7.5.
From the same dataset as above, Fig. 7.2 shows a close-up of point 6 (counting from top-right) in QCAD 3.7.5. The blue line is again the very large arc and is displayed by the QCAD 'Arc' function. The orange line is again the polyline of externally calculated points at fixed increments along the arc's periphery. One of these peripheral points is shown by the orange dot. Interestingly, in QCAD further lines (for example the dashed blue perpendicular) actually 'snap' to the correct position (orange), not the displayed arc (blue). The same behaviour applies to hit-testing: it selects the blue line when you hit the orange position, but fails to select anything if you hit the blue line itself.
This may point to a problem with the visual display/grahics subsystem/hardware rather than the underlying data or calculation. But who knows how the coordinate information is actually passed down the line and further digested. For example,a recalculation of the peripheral point (orange) with simulated single precision (blue point) suggests that numerical truncation is a possible answer for at least the QCAD error (Indeed there is some talk on the internet that GeForce GPU's calculate 2D rendering in single precision). Where the two-order magnitude larger WPF error comes from remains a mystery though.

Why does this matter and gets me hot under the collar?

In essence, the overall problem in hand involves segmentation of sparsely sampled and noisy data into simple geometric elements such as straights and circular arcs. This is not a trivial task and needs some sophisticated strategies and complex algorithms. Without reliable, and accurate graphical representation of the output, quality control of any proposed scheme becomes very difficult indeed: For example, Fig. 7.2 shows the actual, digitised point (light green) with its uncertainty circle (light grey), which is apparently bypassed by the calculated arc (blue), thus suggesting that the point belongs to a new, different segment. However, the real (orange) arc does very much run through the uncertainty circle, indicating the opposite.

I accept that we will not cure Redmond, but can we fix QCAD?
Attachments
Fig 7.2 - Poor Arc Rendering - QCAD.PNG
Serious from QCAD
Fig 7.2 - Poor Arc Rendering - QCAD.PNG (21.54 KiB) Viewed 5511 times
Fig 7.1 - Poor Arc Fit - Line AHAR 63.PNG
Fun from Redmond
Fig 7.1 - Poor Arc Fit - Line AHAR 63.PNG (67.02 KiB) Viewed 5511 times

User avatar
andrew
Site Admin
Posts: 9037
Joined: Fri Mar 30, 2007 6:07 am

Re: Arc in the Wrong Place

Post by andrew » Thu Feb 19, 2015 9:25 am

Could you attach the DXF drawing file for testing please, thanks.

TheEnglishPatient
Active Member
Posts: 35
Joined: Sun Feb 19, 2012 12:56 pm

Re: Arc in the Wrong Place

Post by TheEnglishPatient » Thu Feb 19, 2015 11:02 am

Here is the file
Attachments
Digitised Fitting Points (with Results)- AHAR line [63].dxf
(102.91 KiB) Downloaded 390 times

User avatar
andrew
Site Admin
Posts: 9037
Joined: Fri Mar 30, 2007 6:07 am

Re: Arc in the Wrong Place

Post by andrew » Thu Feb 19, 2015 1:33 pm

Thanks.

For performance reasons, arcs are rendered as a series of small line segments in QCAD. For arcs with a very large radius, these line segments can become quite large and cause these kinds of display errors. The reason why the segments are not simply scaled down to the length of a few pixels is rendering performance. Rendering such a huge arc with line segments of a few pixels length would be very slow and consume a lot of memory (even though only a small segment of the arc might be visible, the whole arc has to be rendered in memory, again for performance reasons).

I've added a user preference for the next release to make this behavior configurable, so users can fine tune performance vs. display precision.

TheEnglishPatient
Active Member
Posts: 35
Joined: Sun Feb 19, 2012 12:56 pm

Re: Arc in the Wrong Place

Post by TheEnglishPatient » Fri Feb 20, 2015 12:34 pm

Ok I understand, that seems eminently sensible.

I approach this in my program to get first the start and end angle of the visible arc section, then segment that into sufficiently detailed sub-intervals along the arc's periphery, calculate for those points xy's separately, and convert with them the arc to a polyline - but you have indeed to be very careful with numerical errors particularly when you call trigonometrical functions because the angles involved are so small. And I am not too bothered with memory/performance as I will have only a few of these beasts at any one time - obviously for an all singing, all dancing CAD program to be considered differently.

Post Reply

Return to “QCAD Troubleshooting and Problems”