LineOffset does not respect distances...

[atdx-lim]

trafficstars

Hi,

II read several posts on the subject but I did not really find the answer. I have a line expressed with WGS84 coordinates:

let myline = turf.lineString([4.101441, 44.279814]
,[4.101386, 44.279732]
,[4.101333, 44.279696]
,[4.10132, 44.279696]
,[4.101225, 44.279696]
,[4.101051, 44.27973]
,[4.100738, 44.279791]
,[4.100121, 44.279911]
,[4.099466, 44.280038]
,[4.099459, 44.280039]
,[4.09937, 44.280057]);

let rightline = getLineOffset(myline , 4, {units: 'meters'});
let leftline = getLineOffset(myline , -4, {units: 'meters'});

Right coordinates returned :

[4.101411124977849, 44.27983403812462]
,[4.101360013256536, 44.279757835194665]
,[4.101321938085819, 44.27973197281455]
,[4.10132, 44.27973197281455]
,[4.101228481662364, 44.27973197281455]
,[4.101057889945491, 44.279765306828196]
,[4.100744874438115, 44.2798263098504]
,[4.100127857509158, 44.2799463131429]
,[4.099471971015376, 44.280073485027955]
,[4.099465114251917, 44.280074464565594]
,[4.099377131019004, 44.280092258927304]

Left coordinates returned :

[4.101470875022152, 44.279793961875384]
,[4.1014119867434635, 44.27970616480534]
,[4.1013440619141805, 44.27966002718545]
,[4.10132, 44.27966002718545]
,[4.101221518337637, 44.27966002718545]
,[4.101044110054509, 44.279694693171805]
,[4.100731125561884, 44.27975569014961]
,[4.100114142490841, 44.279875686857096]
,[4.099460028984623, 44.28000251497204]
,[4.099452885748069, 44.28000353543441]
,[4.099362868980997, 44.280021741072694]

As you can see in the following picture, the offset seams to be ok for horizontal segments, but wrong for oblique segments. (myline in blue, buffer of 4 meters around myline in red, left and right lines in black)

is this a bug or am i forgetting something ?

What is the alternative to circumvent the problem?

Thanks for your help

[stebogit]

@atdx-lim why do you say result is wrong? In other words, what do you consider correct?

To me it actually seems like the buffer does not keep constant distance from your line. Just eyeballing (I might be wrong), looking at the oblique sections, the buffer lines seem to be further apart from your line than the left/right lines compared to the horizontal sections. Assuming the horizontal bits are not affected by any possible projection distortion, the distance between lines in there should be your reference.

[atdx-lim]

The coordinates are expressed in Latitudes/Longitudes in a WGS84 system. Visually the distance between the blue axis and the red buffer does not seem constant. This is normal because we are in a spherical system. If I calculate the distances between points, I always have 4m between the blue line and the red line. In this system, I try to generate lines at a distance of 4 m to the right and to the left. On certain portions this distance is not respected. The function behaves as if we were in a planar system...

[atdx-lim]

To complete my previous post. If i transform my axe coordinates to mercator system.

let mercator_line = turf.lineString([[ 456570.323639, 5508846.647763 ], [ 456564.201067, 5508833.897801 ], [ 456558.301134, 5508828.300262 ], [ 456556.853980, 5508828.300262 ], [ 456546.278629, 5508828.300262 ], [ 456526.909037, 5508833.586826 ], [ 456492.066037, 5508843.071552 ], [ 456423.381911, 5508861.730058 ], [ 456350.467644, 5508881.477018 ], [ 456349.688408, 5508881.632506 ], [ 456339.780973, 5508884.431291 ]]);

let right_line = turf.lineOffset(mercator_line, 4, {units: 'meters'});
let left_line = turf.lineOffset(mercator_line, -4, {units: 'meters'});

The distance beetween, any point of the axe and its projected point on left/right line is constant. Unfortunately the problem is the same. The distance is not 4 meters, but a very small value : 0.0000261 meters !!!!

I think the problem comes from a bug in the lineOffset function. Maybe relative to units conversion...!

[Simage]

The core issue here is that distances are converted to angular measurements at the equator and then applied to the coordinates as if they were on a cartesian plain rather than a globe. This means that the observed error will continue to increase in the east-west axis as you move away from the equator.

Out of curiosity, I looked at the buffer algorithm as I noticed it did not display this behavior. the buffer algorithm projects the WGS84 coordinates to a meters projection, performs the math needed, and then projects back to WGS84 to avoid this issue

[atdx-lim]

Yes the buffer generation works as it should. But in my case, I really need lines. And cutting the buffer seems complicated, if you don't know the ends to be cut...I plan to use another library.