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
Currently, in nearby, when a user scrolls (which also includes resizing) to a new position in the map), a query is made for items in the rectangular geographical area. Although the query is lightweight (made for only P625), it goes on endlessly until timeout for large enough areas.
When a user zooms out enough, the initial query is made for a large area, so the query takes a long time only to end up in a timeout. When the user then zooms in, a second query should be initiated (discarding the first), but it never happens as per the current logic, which ideally shouldn't happen.
This part is easy to fix (by ignoring currently running query after a shorter timeout).
But ideally, the expensive query should never be made in the first place. Reason:
Say, the area is small enough for the query to return (but still large enough for it to return much greater than 1000 items).
Then the resulting items are sorted in-app (by their distance from the map centre), and only the nearest 1000 items are actually utilized.
A workaround would be to first query for the items count. If it's much greater than 1000, then query on a smaller square bound centered on the user (in the same manner as a binary search). Do it till the number of items in the queried area is under $1000 \times \frac{4}{\pi}$.
Also, if the area is absurdly big, then even the count-binary-search queries (proposed above) can be dropped and a simple overlay saying "zoom in to display pins" can be shown (maybe similar to how chromium based browsers show "No Internet Connection").
The text was updated successfully, but these errors were encountered:
Currently, in nearby, when a user scrolls (which also includes resizing) to a new position in the map), a query is made for items in the rectangular geographical area. Although the query is lightweight (made for only P625), it goes on endlessly until timeout for large enough areas.
When a user zooms out enough, the initial query is made for a large area, so the query takes a long time only to end up in a timeout. When the user then zooms in, a second query should be initiated (discarding the first), but it never happens as per the current logic, which ideally shouldn't happen.
This part is easy to fix (by ignoring currently running query after a shorter timeout).
But ideally, the expensive query should never be made in the first place. Reason:
Say, the area is small enough for the query to return (but still large enough for it to return much greater than 1000 items).
Then the resulting items are sorted in-app (by their distance from the map centre), and only the nearest 1000 items are actually utilized.
A workaround would be to first query for the items count. If it's much greater than 1000, then query on a smaller square bound centered on the user (in the same manner as a binary search). Do it till the number of items in the queried area is under$1000 \times \frac{4}{\pi}$ .
Here's an example:
Also, if the area is absurdly big, then even the count-binary-search queries (proposed above) can be dropped and a simple overlay saying "zoom in to display pins" can be shown (maybe similar to how chromium based browsers show "No Internet Connection").
The text was updated successfully, but these errors were encountered: