Scrollable Mapview on tmtest

[Jim]

The version on tmtest now has the first attempt to use the debouncing idea to avoid multiple DB reloads and map updates while panning/zooming.  I've set it for now at a 1 second delay after each pan/zoom to see if any additional pan/zoom operations will occur before fetching the data from the DB.  Thoughts and observations welcome.

[michih]

Even loading the initial graph (and table) with default zoom takes a few seconds. It's more when panning/zooming. Is it possible to display a "Loading..." message?

[Jim]

Even loading the initial graph (and table) with default zoom takes a few seconds. It's more when panning/zooming. Is it possible to display a "Loading..." message?

Yes, I plan to look into that.

All DB queries will take 4-5 seconds, and that's after the 1 second delay to avoid multiple reloads, regardless of how much is on the map (it has to search all segments, globally).  Transfer of the query results, and getting things into the table and map once the DB queries are complete are very fast operations by comparison, but depend on the number of segments returned.

When panning/zooming if the 1 second delay passes and a DB query starts, and then you start to pan and zoom again, you will be waiting both for the first query to finish and its results to be displayed (the results of which might no longer be visible), then the second DB query and display.

[michih]

What takes so long, only getting DB info for the table? Or getting the graph too?

[Jim]

It doesn't load graphs.  Just segments from the DB.  The reason it's expensive (as far as I can tell) is that it needs to look at both endpoints of each of 874,000+ segments and see if either is within the visible area of the map, and that we need to join the segments with waypoints (twice) to get locations, and with clinched to get whether each segment is clinched for the traveler.  Even with all that, it's not perfect as a segment that clips the corner of the visible area but has neither endpoint visible would not be included.

[Jim]

I just made a change that speeds things up quite a bit on maps without too many segments visible.  It finds visible waypoints first, then gets segments based on that list.  Unfortunately, it's slower than the previous mechanism for large numbers of waypoints, so when over 500 (just a best guess) waypoints are found, it falls back to the original query to find segments.

In any case, for fairly close-in maps, this is a big improvement.  Most of the delay we see now in those cases is from the debouncing to avoid rapid reloads during panning/zooming.

[mapcat]

Working great now.

When the route table is more than one page long, if I have scrolled down the table a page or two and then pan to a new location, the table refreshes at approximately the same place rather than the top. Is that by design?

Would it be possible to give users the option of loading a scrollable mapview at the country or state level? Example: loading http://tmtest.teresco.org/user/mapview.php?units=miles&u=mapcat&rg=CO includes routes in surrounding regions. Entering "colorado" as the initial location and choosing "far"for the zoom level centers the map close to the center of Colorado, but the far northern part of the state is cut off. For someplace larger than Colorado, there's no way to see the entire region without zooming out, which requires a great deal of finesse and/or luck if you want the map to be perfectly centered.

[Jim]

Working great now.

Good to hear!

When the route table is more than one page long, if I have scrolled down the table a page or two and then pan to a new location, the table refreshes at approximately the same place rather than the top. Is that by design?

Not by design and I didn't even notice.  I am not sure why, but I think it probably makes most sense to force it back to the top if I can.

Would it be possible to give users the option of loading a scrollable mapview at the country or state level? Example: loading http://tmtest.teresco.org/user/mapview.php?units=miles&u=mapcat&rg=CO includes routes in surrounding regions. Entering "colorado" as the initial location and choosing "far"for the zoom level centers the map close to the center of Colorado, but the far northern part of the state is cut off. For someplace larger than Colorado, there's no way to see the entire region without zooming out, which requires a great deal of finesse and/or luck if you want the map to be perfectly centered.

Yes, that's something I'd like to do.  First, I would like to replicate existing mapview functionality with the new back-end code.  Then I'd like to add some controls, one of which would be to enable showing all routes in the visible map area at any time.  Other possibilities for the new controls would to be able to bring back up the initial popup to jump to a location, to show/hide segments that are clinched/unclinched, or maybe swap which are more opaque.

[yakra]

Polylines do not appear to be stacked by tier.
Looking at my travels in Worcester MA, MA70 renders atop I-290.

[Jim]

Polylines do not appear to be stacked by tier.
Looking at my travels in Worcester MA, MA70 renders atop I-290.

Already noted: https://github.com/TravelMapping/Web/issues/436

[Jim]

It's not perfect, but I feel like the debouncing and the faster loading for relatively close-in views have made this usable.  It's now on the production site and in the master branch on GitHub.  I've also added links (temporarily) in the motd shown on the home page and (more permanently) at the top of user pages.  I also changed the title of the mapview page to "Mapview" from "Draft Map Overlay Viewer".

I do not believe any previous Mapview functionality is impacted.

[mapcat]

Devel systems are showing up on the scrollable maps. I don't see them on pages without the &v parameter.

[Jim]

Devel systems are showing up on the scrollable maps. I don't see them on pages without the &v parameter.

Thanks, I'll fix: https://github.com/TravelMapping/Web/issues/447

[compdude787]

I really like this! It's a great improvement over the old mapview as it shows all the systems in a particular area without having to type it into the URL. My thoughts for some improvements (sorry if these have already been mentioned):

-When you open the page, the first thing you see is something to enter in the lat/lon. Only after a few seconds of me looking at that and going "uhhh..." then I saw that I could enter in a city to go to. I think you should make this more prominent because nobody is going to know what lat/lon coordinates they want to start out at.

-Also, add an option to that screen to input username. It's kinda clunky to have to type that into the URL.

-When you have the route table open, and the route table doesn't take up the whole length of the screen, you can't drag the map if you have the mouse cursor in that area.

Other than that, I think this is a great feature that will add a lot to this site.

[yakra]

The reason it's expensive (as far as I can tell) is that it needs to look at both endpoints of each of 874,000+ segments and see if either is within the visible area of the map, and that we need to join the segments with waypoints (twice) to get locations, and with clinched to get whether each segment is clinched for the traveler.

Thoughts on including beginning/end latitude/longitude directly in the segments table and eliminating the JOINs for a potential speedup?