thomasgwatson
commented
6 years ago Been chatting with @jcallin about this.
What is our summary? 1) Move the viewport, triggers state update 2) Normally deck.gl would see the state change but not recalc, since the data object didn't change 3) However, the data is now filtered in the deckgl-overlay render function; it returns a new object 4) So deck.gl triggers recalc in workers 5) Recalc now has a different latitude at which to bin the hexagons 6) A defacto different hexagon grid means that some points fall into different hexagons, thus hexagon values shift (and thus their size and sometimes their color shift)
@jcallin also specifically found that pure east/west movements didn't change the output; I assume it is still running a recalc but that the hex grid is being generated from the latitude. So if it is the same, the hex binning produces the same result.
I'm guessing if we moved the filtering of data outside of any render functions, it would help deck.gl to avoid triggering the recalc. Even if the sensitivity-to-initial-conditions (the latitude's impact on the hex binning) issue would still remain.
Anywhoo, looking forward to H3 integration :D
I am looking at the map at http://vis.academy/#/building-a-geospatial-app/6-linking-it-all and was able to replicate the issue in my local environment.
Observed behavior: After an hour is selected on the chart, moving the map with the mouse (zoom, perspective change, or drop) causes the hexagons to change position, elevation, and color. It looks like the hexagons get translated as the user moves the map vertically.
Expected behavior: The hexagons should not change when the user changes their view of the map.
I'm not sure if this is an issue with the example code or with how the overlay is matched up to the map via the viewport.