“Properties” command corrupts coordinates (rounds to 6 significant figures)

Have come across a potential problem which I have not been able to find a solution in the forums.
 
I have a large mapping file of around 6,000 KB with 130 layers which is referenced to an origin some 500,000 m away (500km).  The Properties command functions correctly on polyline elements but line elements are corrupted – I assume the coordinates are being rounded to 6 significant figures and written back (and stored) in their rounded format.

Short lines (2 – 3m long ?) disappear whereas longer lines (around 8 - 10 m) are reduced to 10m in length and changed to vertical or horizontal orientation.  I reckon the coordinates on longer lines also become rounded to 6 significant figures (10m accuracy where the work area is more than 100km from the origin ?).

Lines can be constructed with mm accuracy which appears to be retained unless the Properties function is applied to them.

Hopefully I havnt missed a parameter somewhere and this is an unintended consequence.  Hopefully an easy fix – so long as my prognosis (as a novice programmer and beginner Cad user) is correct !.

I am using Librecad Version 2.2.0.1 and the data file (hopefully) is attached.  Layer 0000 are boundary (long) lines and layer 0001 are a building (short detailed) lines.  Most (if not all) of the other layers are polylines.

The easy workaround is to move the origin but I will be trying to load some SHP files in the future which I assume have the same grid so would like to stick with the grid.  Also, I could put all new data as polylines, but again a bit of a faff (or not use Properties).
 
Hopefully, the above is helpful and apologies if I’ve cocked up.  Librecad is a brilliant tool.  Keep up the good work.

Very interesting topic.

First, are you using spline or "spline through points"?

They are totally different things. For precision, please use spline through points.

I am pretty sure that we don't round off coordinates at file saving, but I need to verify that. Since dxf files are plain text, it's straightforward to verify the coordinates.

The actual interesting part: many cad softwares only provide precision level around 1 millionth, say 1mm over 1Km. We want to do better.

Holdstrong wrote

Have come across a potential problem which I have not been able to find a solution in the forums.
 
I have a large mapping file of around 6,000 KB with 130 layers which is referenced to an origin some 500,000 m away (500km).  The Properties command functions correctly on polyline elements but line elements are corrupted – I assume the coordinates are being rounded to 6 significant figures and written back (and stored) in their rounded format.

Short lines (2 – 3m long ?) disappear whereas longer lines (around 8 - 10 m) are reduced to 10m in length and changed to vertical or horizontal orientation.  I reckon the coordinates on longer lines also become rounded to 6 significant figures (10m accuracy where the work area is more than 100km from the origin ?).

Lines can be constructed with mm accuracy which appears to be retained unless the Properties function is applied to them.

Hopefully I havnt missed a parameter somewhere and this is an unintended consequence.  Hopefully an easy fix – so long as my prognosis (as a novice programmer and beginner Cad user) is correct !.

I am using Librecad Version 2.2.0.1 and the data file (hopefully) is attached.  Layer 0000 are boundary (long) lines and layer 0001 are a building (short detailed) lines.  Most (if not all) of the other layers are polylines.

The easy workaround is to move the origin but I will be trying to load some SHP files in the future which I assume have the same grid so would like to stick with the grid.  Also, I could put all new data as polylines, but again a bit of a faff (or not use Properties).
 
Hopefully, the above is helpful and apologies if I’ve cocked up.  Librecad is a brilliant tool.  Keep up the good work.

Thanks for responding.  I said I was a beginner and havnt used splines.  You might be reading more complexities into this.  

By way of further background the polylines in the file are short segments of straight lines (between a metre and several metres in length) which are combined as polylines to create the feature / contour on the map.  To cut out an area of interest (primarily to reduce the file size) I exploded the polylines, cut out the unwanted bits and then reformed the reduced polylines using the “Create Polylines from Existing Segments”.  Crude and long winded but it worked to maintain the structure of the existing file.

When I started to manually update features (and didn’t create polylines) the coordinates changed when using the Properties function.  The attached screenshot shows how the line changes after doing a “Properties” on the line.  The shape is about 10m square and the new line (I expect) is based on a 10m grid.

I assume the issue is caused by being so far away from the origin.  A couple of meter difference in 500,000 metres is not significant except when the other local / connected features don’t change by the same amount !!.

I note what you say about precision but have noticed in the past lines “drifting” by fractions of mm’s on house plans.  Not significant, and still accurate to a whole mm, but all the same a little surprising.

Currently, all internal properties(coordinates, to be specific) are kept as standard 64bit floating points.

This would cause precision issues, if a geometry, which is created around the origin, is moved to 1,000,000 m away.

The trouble starts with some internal tolerance of 1e-10. Using 64bit floating points, (1,000,001 - 1,000,000) starts to have rounding errors around 1e-10. Since we have to do multiple rounds of floating point calculations, the rounding offs quickly magnified, and starts to get noticable.

Another issue could be rendering, our rendering sometimes is not 100% following the logic positions. Especially, when you draw connected arcs, move/totate, and zoom in to connection points.

Holdstrong wrote

Thanks for responding.  I said I was a beginner and havnt used splines.  You might be reading more complexities into this.  

By way of further background the polylines in the file are short segments of straight lines (between a metre and several metres in length) which are combined as polylines to create the feature / contour on the map.  To cut out an area of interest (primarily to reduce the file size) I exploded the polylines, cut out the unwanted bits and then reformed the reduced polylines using the “Create Polylines from Existing Segments”.  Crude and long winded but it worked to maintain the structure of the existing file.

When I started to manually update features (and didn’t create polylines) the coordinates changed when using the Properties function.  The attached screenshot shows how the line changes after doing a “Properties” on the line.  The shape is about 10m square and the new line (I expect) is based on a 10m grid.

I assume the issue is caused by being so far away from the origin.  A couple of meter difference in 500,000 metres is not significant except when the other local / connected features don’t change by the same amount !!.

I note what you say about precision but have noticed in the past lines “drifting” by fractions of mm’s on house plans.  Not significant, and still accurate to a whole mm, but all the same a little surprising.

This has possibly nothing to do with tolerances or reading/writing DXF.

A common issue is to set floating point numbers into a QLineEdit and read it back. This is what happens in the properties dialog. The conversion float -> string -> float is often the cause of such errors.

Of course, this issue is favored by the big coordinate numbers.

When you search the forum, there is a bunch of topics addressing this.
I haven't heard about this properties dialog issue yet, but it fits into the series of issues with surveying applications.
There will be more issues concerning accuracy, finding intersections, snapping and more.
Those arise because of the big ratio between location and entity sizes.

The recommendation is to move the drawing towards the origin.

Armin

I think we may be talking different issues.

One is negligible errors that may occur due to rounding etc that are (at least for me) inconsequential.

The other is a noticeable shift where different rounding rules may have been applied in different parts of the program.

I have simplified the file and is attached (so long as it uploads) and include the screenshots.
Test.dxf
The first image shows the drawing elements after selecting Properties but before pressing OK.

The second image shows the drawing elements after pressing OK – line AB moves to a visibly different position albeit the displayed coordinates are the same shown (using Properties).  Seem to be rounded to 6 dec places and these rounded coordinates replace the original for on-going operations and saving ie the  64bit floating point accuracy is not retained after using Properties.

Hopefully the above clarifies and you can experience for yourself.

Thanks for the description Armin.  A bit beyond me but at least you are aware of the issue.

My latest reply to dxli (which perhaps more clearly describes the issue) overlapped with your comments.  As a lay person without intricate knowledge of Librecad programming it seemed specifically related to Properties.  If Properties is not used, or I change the lines into polylines, the issue doesn’t arise.

I agree that revising the origin is an option.  I did this previously when using Ordnance Survey mapping but for different reasons.  Given that I will be trying to import / combine this mapping data with other data available through GIS and then to set out points on the ground it seemed simpler to stick with the base origin.  At least I now know the constraints.

Many thanks

The direct issue is the GUI level reading and saving coordinates with the default QString precision of 6 digits.

We can switch to keep all 16 possible significant digits for all coordinates, but it's not user friendly either.

The problem is generic, meaning not limited line properties, or just xy-coordinates. A generic solution is needed.

Thanks for the update.  Seems logical (to a layman) given it only occurs once the command is executed.

I have found the info provided by the properties command can be displayed so long as the “ok” is not invoked ie exit the command using “cancel” or abort using Esc. It is also possible to do an “undo” which seems to restore the original coordinates.  Works for me at the moment but remains to be seen whether there have been other unnoticed changes in the file that are not critical.

Your recommendation to avoid distant origins is probably the best guidance for now but it still means potential discretions of 1mm when the object is more than 100m away from the origin.  Not significant in the real world but may be an annoyance if, for example, drawing a house plan in an acre plot.  

I don’t understand the programming issues but it is clearly not a quick fix and I’ll leave it to your good selves to decide how / when it gets tackled.

I started to fix the GUI issue in 2.2.2-alpha:

The coordinates should be displayed with 10 significant digits. Might be messy for some cases, but at least won't corrupt anything.

If it's acceptable, we can add the fix to 2.2.1 in time.

Holdstrong wrote

Thanks for the update.  Seems logical (to a layman) given it only occurs once the command is executed.

I have found the info provided by the properties command can be displayed so long as the “ok” is not invoked ie exit the command using “cancel” or abort using Esc. It is also possible to do an “undo” which seems to restore the original coordinates.  Works for me at the moment but remains to be seen whether there have been other unnoticed changes in the file that are not critical.

Your recommendation to avoid distant origins is probably the best guidance for now but it still means potential discretions of 1mm when the object is more than 100m away from the origin.  Not significant in the real world but may be an annoyance if, for example, drawing a house plan in an acre plot.  

I don’t understand the programming issues but it is clearly not a quick fix and I’ll leave it to your good selves to decide how / when it gets tackled.

Great to hear and thanks for the update..

At the moment I’ve been persevering by keeping all the lines as polygons.  Not particularly efficient as it means exploding to make changes and then recreating polylines but ok for an amateur on a personal project.

Whilst working on the file I’ve had several instances where it has locked up or gone very slow - not sure which or could be both.

In addition, the “file” menu sometimes uses the old 2.1.3 version (doesnt show the file names under “save” and “save as”) and also (sometimes !) filenames don’t get updated to the current (and subsequent) file names.

These effects appear random at present but if I can identify a specific sequence or operation I’ll let you know.