You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
queryRenderedSymbols is always based on the size/location of symbols at the time the last placement/collision detection completed. This means that when the map is changing, the results will tend to be a little stale (symbols with *-allow-overlap: true may be rendered on screen but not show up in the collision index, symbols may be rendered at larger/smaller size than recorded in the index, etc.). Having some delay in when items show up or disappear from query results is not ideal, but we think it's usually not too big a deal.
There's another problem, though: if you change the position of the map, the same viewport coordinates will map to different lat/lon values. So, if you query a recently moved map, you won't get stale results from the same lat/lon -- you'll get stale results from the viewport coordinate, which now has a different lat/lon. This has the potential to be pretty confusing: imagine an interactive feature that uses flyTo animations in combination with some sort of hover effect. If the user brought their cursor over the map while it was animating, the hover effect would work as if their cursor were at a random offset from its actual location (depending on how long it had been since the last placement).
Fixing the "stale results" problem entirely is hard, but I think we should be able to do a decent job of keeping coordinates in sync. At the time we call queryRenderedSymbols, instead of just using the current viewport query coordinates, we should use the current transform to convert the viewport coordinates to lat/lon, then use the last placement's transform to convert back into the viewport coordinates that would have obtained when the last placement ran.
From #6497 (comment):
queryRenderedSymbols
is always based on the size/location of symbols at the time the last placement/collision detection completed. This means that when the map is changing, the results will tend to be a little stale (symbols with*-allow-overlap: true
may be rendered on screen but not show up in the collision index, symbols may be rendered at larger/smaller size than recorded in the index, etc.). Having some delay in when items show up or disappear from query results is not ideal, but we think it's usually not too big a deal.There's another problem, though: if you change the position of the map, the same viewport coordinates will map to different lat/lon values. So, if you query a recently moved map, you won't get stale results from the same lat/lon -- you'll get stale results from the viewport coordinate, which now has a different lat/lon. This has the potential to be pretty confusing: imagine an interactive feature that uses flyTo animations in combination with some sort of hover effect. If the user brought their cursor over the map while it was animating, the hover effect would work as if their cursor were at a random offset from its actual location (depending on how long it had been since the last placement).
Fixing the "stale results" problem entirely is hard, but I think we should be able to do a decent job of keeping coordinates in sync. At the time we call
queryRenderedSymbols
, instead of just using the current viewport query coordinates, we should use the current transform to convert the viewport coordinates to lat/lon, then use the last placement's transform to convert back into the viewport coordinates that would have obtained when the last placement ran./cc @ansis
The text was updated successfully, but these errors were encountered: