Deck.gl: Weird position transitions behaviour

Created on 13 Aug 2019  路  16Comments  路  Source: visgl/deck.gl

Description

Not quite sure if this is expected, but please check out this codesandbox, it explains best:
https://codesandbox.io/s/tender-forest-2no5i

Environment (please complete the following information):

  • Framework Version: deck.gl 7.2.0
  • Browser Version: Chrome 76.0.3809.100
  • OS: Windows 10

Logs

N/A

Edit Also, when in large zoom level, panning the map affects the positions of the moving icons

bug

Most helpful comment

Hello, I am currently facing the same issue. Whenever data are changed (when a plane is added or removed), then everything is moving in a different position. I guess this happens cause there is no unique id for each icon displayed. @1chandu @Pessimistress Is there a way to avoid this bug and to change position only in case icon' s position has changed?

All 16 comments

        onClick={() => setViewState({
          ...viewState,
          latitude: 15,
          longitude: 15,
          zoom: 3,
          transitionDuration: 2000,
        })}

By default LinearInterplator is used, with default transition props, that includes bearing too. Two ways to fix:

  1. the viewState you are using in above code is invalid, you are not saving it correctly.
  2. If you are only interested in transitioning a set of props, you can pass a custom interpolator using `LinearInterpolator(['longitude', 'latitude', 'zoom']);

@1chandu Hi and thanks for the reply. I think you are getting the issue wrong. I didn't have any issues with viewport transitioning, but position transitioning (you can see the plane icons were flying around in some random order). Can you please have a look again?

Ok, it wasn't clear what the problem is, so you are referring to position transitions (attribute transitions).

          transitions={{
            getPosition: 10000
          }}

So when position is changed (i.e. data is changed), it performs transition of each object (element of data) from its original position to new position, the transition you see are caused by new data. If this is not expected behavior you should verify how the data is changed, current and new position for each data element. Also what is the behavior you are expecting?

@1chandu If you disable the transitions prop, you can clearly see that the planes are moving slowly in the direction of its nose, which is expected. As soon as I enable transitioning, the planes move in random order. I noticed some of them stay at the same position after moving around. Not quite sure what caused it. If you don't mind, please select a single icao24 to request (which is data[0] in this case). The url would be /states/all?icao24=<your_icao24_here>. Cheers :)

I digged more into this, there are two issues :

1. this is deck.gl issue, when data is changed from null to valid array transitions are wrong, I am working on the fix, but meanwhile you can workaround this problem by enabling transitions only when you have valid data :

          transitions={
            airData === null
              ? {}
              : {
                  getPosition: 10000
                }
          }

2. Invalid data, some of the objects have null position and then they get update to correct values, causing those weird transitions, here is the log when I am only rendering 5 objects, you would see more of these when render all objects :

airData: 8301 filterData: 5
0 : -97.2615,33.3816,3619.5
1 : -106.5617,38.4276,11887.2
2 : ,,
3 : -80.4844,35.7537,3962.4
4 : -111.7601,39.3792,10972.8

airData: 8314 filterData: 5
0 : -97.2533,33.4123,3619.5
1 : -106.5007,38.4243,11887.2
2 : ,,
3 : -80.5054,35.7287,3848.1
4 : -111.8218,39.3672,10972.8

airData: 8314 filterData: 5
0 : -97.2533,33.4123,3619.5
1 : -106.5007,38.4243,11887.2
2 : ,,
3 : -80.5054,35.7287,3848.1
4 : -111.8218,39.3672,10972.8

airData: 8302 filterData: 5
0 : -97.2492,33.4272,3619.5
1 : -106.4608,38.4222,11887.2
2 : -80.5198,35.7113,3726.18
3 : -111.8516,39.3614,10972.8
4 : 102.0716,17.5856,9448.8

With the last update object #3 is transitioning from -80.5054,35.7287,3848.1 to -111.8516,39.3614,10972.8 causing wrong transition.

To fix this you need to process your data and make sure objects location in the array don't change.

@1chandu I think deckgl should implement something like React's key prop, which helps identify which piece of data has changed. What do you think?

@1chandu Also, since deckgl doesn't draw when the tab is not active, all the transitions are re-ran when the user focuses on the tab again. Try running the example, focus on a different tab, then switch back after 10-15 seconds, you should see all the planes transitioning from the centre of the map. I tried unmounting deckgl on visibilitychange and it works, but it's kinda hacky. Is there an 'official' way of doing this?

I think deckgl should implement something like React's key prop, which helps identify which piece of data has changed. What do you think?

deck.gl Attribute transitions are GPU accelerated that can handle large amounts of data, but it does need data in particular format. To resolve the above issue, data has to be first processed by CPU (using a key to index map), if you can contribute to that, we are happy to take a look and will consider integrating into deck.gl.

It's kind of hard to just have to keep the data in the same positions and any array manipulations such as adding/removing will result in wrong transitions. I will have a look at the source code.
Also, is there any way to solve the 'fast-foward' transitions when the user focuses on a different tab? As in when you view another tab and come back after around 15s, the transitions become really fast, which is expected but not desired in my case.
Edit: The transitions not just are really fast, but also comes from the centre of the map. To solve this i unmount deckgl and remount it again, but it's a bad experience for the users. You can see it for yourself by viewing the codesandbox, view a different tab for a minimum amount of time of 15s, then view the sandbox again (make sure to do it immediately after all the aircrafts have been loaded)
Edit again :p Forgot to mention my expectations. It would be nice to just immediately plot the icons without any transitions when tab is focused again.

@1chandu @Pessimistress also last question, if you checkout my sandbox again, zooming in affects the aircraft's position. To get what I mean:

  1. Choose an aircraft and zoom in at around 18 zoom level
  2. Pan around
    You should see the aircrafts moving around as you pan, which I'm not sure is expected. It clearly affects the actually positions of the planes.

@1chandu @Pessimistress also last question, if you checkout my sandbox again, zooming in affects the aircraft's position.

Assuming we are talking about same issue, it is the elevation of the planes, when you zoom in closer to the plane and pan, you see the plane moving faster releative to the base map, since your plane has elevation, you can quickly verify by changing your getPosition to return [data[5], data[6], 0];

Edit: The transitions not just are really fast, but also comes from the centre of the map.

Transitions coming from the center of the map could be same issue as I mentioned earlier, should go away that bug is fixed.

@1chandu That's weird. I really want the "z-index" of the aircrafts to reflect their actual heights. Is there a workaround to this issue?

@1chandu That's weird. I really want the "z-index" of the aircrafts to reflect their actual heights. Is there a workaround to this issue?

They are correctly rendered at the specified z value, I don't see any problem in their position.

Hello, I am currently facing the same issue. Whenever data are changed (when a plane is added or removed), then everything is moving in a different position. I guess this happens cause there is no unique id for each icon displayed. @1chandu @Pessimistress Is there a way to avoid this bug and to change position only in case icon' s position has changed?

Is there a solution for the above comment? I have a map where users can add and delete points and whenever the array is shifted around the transitions make all the points jump around due to this.

Merging with #2570

Was this page helpful?
0 / 5 - 0 ratings