-
Notifications
You must be signed in to change notification settings - Fork 26
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Efficiency of the (currently very slow) spatial queries in scrollable Mapview #424
Comments
Not sure if this is related to the slow response, but is it necessary to generate the table on each scroll, especially if a user is scrolling multiple times in quick succession? For example, I waited for the original location (Siena) to load fully, then scrolled to the west multiple times until it was focused on northern Ohio, and waited for the segments to be drawn. I don't know if the number of times the table regenerated matched the number of click-drags, but it populated with data from Pennsylvania at least twice, even though nothing from that state showed on the initial or final map. |
#423 is about how we might be able to wait until the pan/zoom operations have stopped before making the request. As of now, we have two efficiency problems: each query is slow, and queries are generated for each pan/zoom, even if part of a quick sequence. I hope the box to jump to a desired starting location will reduce the need to lots of scrolling around to get from an area to another that's far away, making this a less urgent issue at the moment. |
Disappointing experiment today with the mysql spatial data types. No consistent speed differences when I introduced a The query as in the current mapview implementation:
has similar run time to the equivalent with the spatial functions:
|
New possibility: break into three queries instead of two.
|
Leaving open until there's some testing of a good threshold for when to use the list of points for the segments query and when to use segment endpoints coordinates in a join. Web/lib/getVisibleSegments.php Lines 55 to 59 in 8f0c4fb
|
To investigate related to efficiency of the (currently very slow) spatial queries:
https://dev.mysql.com/doc/refman/5.7/en/spatial-analysis-functions.html
If that's too complex or unhelpful, another idea is to add a "latlngblock" field to record which lat/lng block each waypoint is in, and query on that hoping it would short circuit the actual lat/lng comparisons for points not in any of the blocks currently visible. Also maybe only when zoomed in fairly far.
Originally posted by @jteresco in #212 (comment)
The text was updated successfully, but these errors were encountered: