Mouse events do not trigger correctly on LineStrings that are offset with line-offset

[elementalhub]

mapbox-gl-js version: 1.8.1

browser: Chrome 80

Steps to Trigger Behavior

1. Draw a LineString and offset it with line-offset by any amount (e.g. line-offset: 25)
2. Add a map click event and use map.queryRenderedFeatures() to query the features under the mouse pointer.
3. The mouse event will trigger inconsistently along the line. It seems at one end of the line the mouse event is in sync with the painted line and while moving along the line towards the other end it seems the line-offset is not respected any longer.

Link to Demonstration

In the image below the dark green line is the LineString with a line-offset as drawn by mapbox. The yellow line (added via photoshop) represents where the mouse pointer needs to be to trigger a click or hover event on that green line.

Expected Behavior

I expect that the mouse event triggers precisely when the mouse pointer is over the offset line. In my example image above I would expect both lines (the green and the yellow) to match up.

Actual Behavior

The mouse event triggers inconsistently along the line.

It seems the features that get returned from queryRenderedFeatures are not the same features that are painted on a layer.

I also found these issues about text-offset and icon-offset, maybe this related? https://github.com/mapbox/mapbox-gl-js/issues/6624 https://github.com/mapbox/mapbox-gl-js/issues/6075 https://github.com/mapbox/mapbox-gl-js/issues/4798

Also something to note: if I use line-translate instead of line-offset the mouse events trigger correctly.

Any help or advice is greatly appreciated. Thanks!

[josh-p-thompson]

I'm encountering this bug as well. Any updates on this? line-translate is an onerous work-around.

[jack9ye]

Just come up with a primitive fix: https://github.com/jack9ye/mapbox-gl-js/commit/ad2df2df734d26c85b9daa81c76eca9dc4f4508d

[vahagnsarg]

I am experiencing this problem at the moment. When offsetting either direction, the mouse hover seems to only trigger from the “original” location of the the LineString.

So when zooming in, the offset becomes larger but the hover section stays in the same place.

[karen1au]

I'm getting the same behaviour on icon-translate for symbol layers. Visually the icon is in a new place but the event is still attached to the original coordinates.

[vahagnsarg]

I have come up with a work around that works quite well.

Instead of using the offset feature from LineString options I offset the feature JSON via turf utilities using the lineOffset util.

https://turfjs.org/docs/#lineOffset

It offsets the coordinates rather than the LineString graphic so the mouse events also gets offset.

Example: lineOffset(featureJson, -4, { units: 'meters' })

[sreejithvelath]

I am also facing the same issue. The mouse clicks are still pointing to the original line instead of new line-offset. In my case I cannot use line-translate because line-translate doesn't work with expressions - (https://github.com/mapbox/mapbox-gl-js/issues/6480). ANY UPDATE on this line-offset and mouse events issue would really help.

[vahagnsarg]

I am also facing the same issue. The mouse clicks are still pointing to the original line instead of new line-offset. In my case I cannot use line-translate because line-translate doesn't work with expressions - (https://github.com/mapbox/mapbox-gl-js/issues/6480).

ANY UPDATE on this line-offset and mouse events issue would really help.

Have you looked at the work around provided above? It works quite well if you know the offset distance in meters/kilometres.

[sreejithvelath]

Hi @vahagnsarg I haven't tried it. I don't want to change the actual coordinate values because those values are required for backend processing. I want the offset only for visualization purpose. Also, my layers are Vector Tile layers and not loaded from GeoJSON. Hence the I cannot apply the offset on featureJson

[nrathi]

+1 on this issue, could you please prioritize a fix? As others have mentioned, line-translate is tedious workaround.

[wade-flow-labs]

+1 on this issue, this is still broken.