wrong angles in Inkscape

[Friedrich Volkmann]

I don't know if the bug is caused by cavern, the Inkscape import filter for Survex 3d files, or Inkscape itself, but the angles are different in Inkscape than in the original .svx file. Example:

*data normal from to tape compass clino
1       2       3.75    209.4   -14.1
3       2       6.57    18.3    -3.3
3       4       3.45    292.4   6.5
3       5       2.97    225.6   10.5
5       6       1.79    111.9   3.4

In Inkscape, the angles are:

1-2 ... 209.45°
3-2 ... 18.21°
3-4 ... 292.45°
3-5 ... 225.69°
5-6 ... 111.98°

The error in 3-5 is noticeable.

I've been noticing these differences for many years and blamed them on some maximum resolution or snapping in Inkscape. But the lines can actually be manually drawn with the correct length and angle in Inkscape. So there must be a serious inaccuracy somewhere in the transformation process.

[Friedrich Volkmann]

screenshot: angle in Inkscape is 18.21° instead of 18.3°

[Olly Betts]

I think this is because the coordinates are stored in the .3d file to the nearest cm, which in most cases will change the angle slightly, but are you really achieving sub cm station accuracy in cave?

$ dump3d trac130.3d
TITLE "trac130"
DATE "@1663435734"
DATE_NUMERIC 1663435734
VERSION 8
SEPARATOR '.'
--
MOVE 0.00 0.00 0.00
LINE -1.79 -3.17 -0.91 [] STYLE=NORMAL
LINE -3.84 -9.40 -0.54 [] STYLE=NORMAL
LINE -7.01 -8.09 -0.14 [] STYLE=NORMAL
MOVE -3.84 -9.40 -0.54
LINE -5.93 -11.44 0.01 [] STYLE=NORMAL
LINE -4.27 -12.11 0.11 [] STYLE=NORMAL
NODE -4.27 -12.11 0.11 [6] UNDERGROUND
NODE -5.93 -11.44 0.01 [5] UNDERGROUND
NODE -7.01 -8.09 -0.14 [4] UNDERGROUND
NODE -3.84 -9.40 -0.54 [3] UNDERGROUND
NODE -1.79 -3.17 -0.91 [2] UNDERGROUND
NODE 0.00 0.00 0.00 [1] UNDERGROUND
STOP

So 3->4 goes (7.01-3.84) = 3.17m West and (9.40-8.09) = 1.31m North and that gives the angle you get:

$ python -c 'from math import *;print(180/pi*atan2(-3.17,1.31)+360)'
292.4528223323595

Looks like 1cm more E-W would give a slightly closer angle:

$ python -c 'from math import *;print(180/pi*atan2(-3.18,1.31)+360)'
292.3891965384431

I think that's just because the coordinates are individually rounded to the nearest cm, so the distance between the rounded coordinates may be 1cm off the rounded distance between the true coordinates.

[Friedrich Volkmann]

Of course I do achieve sub-cm accuracy with a DistoX. But even if the mesurement involves some inaccuracy, I see no reason why computer calculations would need to add additional inaccuracies. Calculations should be done as accurately as possible. The times when we had to trade accuracy for speed or space are long gone. No one cares about 100 bytes when disks have 10 TB.

I suggest to not round the numbers at all, unless the 3d file specification (which I don't know) requires rounding.

[Olly Betts]

The calculations aren't the issue here - they are performed with double precision floating point.

The 3d file specification does require rounding - as I said above it stores coordinates to 1cm.

A disto-x can measure the distance to a few mm, but there's also the positioning error which is likely to be at least few mm. For any non-trivial survey, I'm doubtful the station positions are really known to better than 1cm.

[Friedrich Volkmann]

A workaround seems to be to type in no decimal dots in the .svx file (e.g. 123 instead of 1.23) and to scale down the lines by a factor of 100 after import in Inkscape, but that's really cumbersome. What will break if you add 2 more decimal digits to the 3d file? What about a new option to the cavern script to create 3d files that violate the specification, but can be used for Inkscape?

[Olly Betts]

The 3d file stores coordinates as 4 byte signed integers in cm, which gives a range of -21,474,836.48 to 21,474,836.47 metres.

The largest coordinate values are from UTM latitudes, which in the Southern hemisphere start at 10,000,000 metres at the equator and decrease as you go South.

Scaling coordinates up by 100 breaks for any coordinate value above 214,748.3647m, which for UTM excludes all of Europe, much of North America, and almost all land in the Southern hemisphere except Antarctica.

So there isn't a way we could add 2 more decimal digits without a major overhaul of the format.

You haven't really explained why sub-cm accuracy in the processed data actually matters to you so much. Even if you really can achieve better than 1cm accuracy in the surveyed positions of your survey stations, the positions of everything else on the sketched survey isn't going to at such a high accuracy.

[Friedrich Volkmann]

I have never used UTM coordinates in my life. I've meanwhile written a bash script that upscales the 3d files without changing the original .svx files:

#!/bin/bash fn="$1" tmp="$1".x100.tmp sed 's/\.' <"$fn" >"$tmp" cavern -o ${fn%.svx}.3d "$tmp" rm "$tmp"

In Inkscape, I import the .3d files in 1:10000 scale, so they become really 1:100. Everything works fine, but it's an ugly hack that nobody without background in software development would do or understand.

Sub-cm accuracy matters because the .3d file isn't an end result but an intermediate file. You should never do rounding on intermediate results, because rounding errors accumulate.

One visible effect of the rounding error is: When you have two legs from the same station (let's call it A) and with the same azimuth but with different horizontal distances (let's call the closer station B and the other C), then A-B appears thicker than B-C because A-B doesn't fully overlap with A-C.