Getting the routine changes out of the way first:
- Added filter for URs with/without descriptions.
- Master enable state is saved between sessions.
- JS console debug output can be toggled on or off by clicking the version number at the top of the LMUR UI - when output is enabled "(dbg)" is shown after the version.
And now for the biggie.
Major reworking of the data retrieval code...
The LMURs of old would try to request as much data as possible in a single trip to the server (which translated into requests for blocks of data spanning a 1x1 degree area of the map), and would also perform all the required requests in a single tight loop, locking out the rest of the script until all the data had been received. With the growth in the amount of data required to service both the existing UR/MP filtering, plus the significant extra data now required for PUR filtering, this "big hit" approach to data retrieval was starting to struggle, with retrieval errors becoming more frequently experienced by more users.
2.15 adopts a two-pronged approach to this problem. Firstly, and quite sensibly, the data requests are now made for much smaller blocks at a time - 0.2x0.2 degree areas. This cuts down the amount of data returned in each request, making it more likely that the server will be able to return something other than an error. Secondly, each block request is now placed in a download queue, so that the required blocks can be streamed back and processed on an as and when available basis, leaving the script free to do other stuff in the meantime.
The most obvious evidence of this change is that, if you're viewing an area of the map wider/taller than 0.2 degrees, you'll now see each block rendered as it arrives, rather than (as in previous versions) seeing no change at all until everything had been downloaded and then having the whole screen change at once.
It's not all entirely sweetness and light however, as the UI is momentarily blocked each time one of the chunks is returned from the server and LMUR runs its rendering task, so if you notice the occasional click not being registered, or the occasional popup not, umm, popping up, then it's almost certainly because the render task is doing its thing. On my two development systems it doesn't cause any real problems, so I'm hoping it'll be acceptable for other users too - now I've got the new streaming code in place I'll look into improving this behaviour, but with all the problems the older "big hit" retrieval code is now causing, I wanted to release the streaming code as soon as I was happy with its core performance, and worry about the UI side of things later on...
The other glitch I'm aware of and intend to fix sooner rather than later is that enabling any of the script sections, or the master enable itself, doesn't intitiate the data download required to show any of the newly-enabled items - you'll have to persuade the download to begin by dragging or zooming the map view.
Given how much of the core code has been modified with this release, I'd really appreciate as much feedback as possible, especially comparing the networking performance of 2.15 against the previous releases. I fully expect there to be a fair bit of fine-tuning required before it's working nicely for everyone, but I hope the performance is good enough for you all to see the potential of this redesign. Having spent the last week or so living with this code as it went through pre-release shake down, I certainly wouldn't want to go back to the pre 2.15 way of doing things...
Firefox+Greasemonkey version: https://greasyfork.org/scripts/1948-livemap-ur-overlay
Chrome Web Store version: https://chrome.google.com/webstore/deta ... niefljookp