region.php and system.php

[Jim]

These two pages were left behind during last summer's updates to Mapview, and breakout of the HB functionality to the new showroute and findroute pages.  I'm not sure when I'll try to do so, but I'd like to update them.  Before I do so, I'd like to hear some ideas about what people think those pages should look like.  If you go to them now, you'll see some controls at the top, then a short and wide fixed-size map, followed by the tabular data about the region or system.  Thinking about the history, I recall this design being modeled after similar pages from CHM.  How would you like to see the information currently on that page displayed and organized?  Do you find the map useful?  Too big?  Too small?  I think it's annoying when I try to look at stats for a larger system or region and it's taking forever for the map to load.  Is there other information you'd want to see on those pages?

[vdeane]

Given your comment about waiting for the map to load, perhaps a checkbox for whether to show the map and a cookie to remember the setting?  I actually still use those pages for viewing maps sometimes, especially for larger regions and systems like usai that take forever to load in Mapview, but yeah, it can be annoying when I just want some stats.

One thing that's been mentioned on other threads is how region has the list of other travelers and system doesn't.

[michih]

I don't like the map on those pages and think that a well visible link is enough. It's too large and at a too prominent position. When I wanna scroll down with the mouse wheel in the page, I often zoom in the map instead...

I'd like to have the very same info on the page (all data loaded) but with improved navigation on the page (hide/unhide what you currently wanna see).

I'd like to have kinda "tabs" for a quick jump to the desired table:
user/region.php: Overall region stats / stats per system | Stats by Route | Travelers in Region
user/system.php: System stats / stats per region | Stats by Route | Travelers in System (new)
user: Overall stats / Links | Travelers in continent (new) | Travelers in country (new) | Stats by region | Stats by system

The first "tab" should always be visible when the page is reloaded.

The link to the map could be on top next to user + units (+ system + region) selection which should always be visible independent of the "tab".

[yakra]

One thing that's been mentioned on other threads is how region has the list of other travelers and system doesn't.

Per some recent discussion, I was about to dust off some long-procrastinated plans to add a list of rankings to system.php. Shouldn't be too hard.
Although, is that he best place to present that info?
I think it might be better to have it on separate pages -- CHM called them travregion.php & travsystem.php IIRC.

I'd like to hear some ideas about what people think those pages should look like.  If you go to them now, you'll see some controls at the top, then a short and wide fixed-size map, followed by the tabular data about the region or system.  Thinking about the history, I recall this design being modeled after similar pages from CHM.  How would you like to see the information currently on that page displayed and organized?  Do you find the map useful?  Too big?  Too small?

It's been enough years since I've looked at CHM that I can't remember how it was laid out. ISTR the map .gifs (generated by PHP) being 700x700 and that's about it.
I was almost thinking something along the lines of frames or iframes or divs  or however it's done, to keep the map in place while the user scrolls around the table(s), but...
Keeping the map its current height would leave little to no room below for the table.
I'm unsure how practicable displaying map & table side-by-side would be, especially for those running lower resolutions. I was at 1280x960 for many years.
I don't have a good solution to offer. Maybe CHM worked as TM does now, where we would just scroll the map off the top of the screen.

I think it's annoying when I try to look at stats for a larger system or region and it's taking forever for the map to load.

Comparing loading times between region.php & mapview.php for a couple large states, the newer mapview code loads a lot faster. (More efficient SQL queries?) It'd be nice to similarly improve region.php.
Mapview does redline one CPU core on my client machine the entire time it's loading, whereas region.php just has a short burst of activity after the data comes over the network and it renders the map & table.
If we could get the faster loading times along without all the CPU use, that'd be gravy. (Or is the CPU use a necessary side effect of JSON/AJAX?) If we can't have that, then I'll take the faster load times of course.
Any performance improvement from using MySQL 8.0? Unclear. Mapview load times vary quite a bit on lab2 between successive loads.

Is there other information you'd want to see on those pages?

How about splitting tables across multiple pages for large regions? Think Kentucky, or Texas (esp. if usatxf & usatxr ever see light of day). I know CHM did this for hb/selecthwys.php, but I forget about userpages.
This is nothing I care about much one way or the other, but maybe other have an opinion on this.

Jim, ISTR you posted in the last couple days about changing some MySQL settings and getting faster load times (on findroute?) but I can't find the thread. Got a link? What did you change?

[michih]

I think it might be better to have it on separate pages -- CHM called them travregion.php & travsystem.php IIRC.

That's basically the very same idea I mentioned. You can load the pages in different browser tabs. Less comfortable but simpler to implement.

[bejacob]

I tend to ignore the map when looking at the region.php page. I use all the existing tables depending on what info I'm seeking at any given time, but will open a separate mapview.php tab for the same region and switch back and forth as needed. On the system.php page, I tend to look at the map a little more, but since there is an option to click "View Larger Map" at the top of the page, I think it may better to ignore the map at the top of the page too. The wait time to load a large system or region in mapview isn't really a concern for me. It takes as long as it takes (which so far hasn't been too long). Having a link that will open the mapview with the system or region would be good enough for me instead of having the map load in the frame a the top. That would save a few steps to open another browser tab and find the region/system map I want (which is what I usually do now anyway).

In both the region and system pages, the most important thing for me is to find out which routes I'm closest to clinching or haven't driven at all. The map at the top of the page doesn't help much with that.

I'll have to give a bit more thought as to whether there is additional info that might be useful on either page. Nothing immediately comes to mind.

[Jim]

Jim, ISTR you posted in the last couple days about changing some MySQL settings and getting faster load times (on findroute?) but I can't find the thread. Got a link? What did you change?

Within the last month, I turned off some logging that was resulting in a large DB table I was never going to look at and taking up valuable space on the /var partition.

[yakra]

Within the last month, I turned off some logging that was resulting in a large DB table I was never going to look at and taking up valuable space on the /var partition.

It's probably something I don't need either. What setting was it?

[Jim]

Within the last month, I turned off some logging that was resulting in a large DB table I was never going to look at and taking up valuable space on the /var partition.

It's probably something I don't need either. What setting was it?

I set slow-query-log to 0 in my.cnf.  The table it created was several GB in size.

There are probably other settings to be optimized in there based on TM's usage patterns.

[vdeane]

It's been enough years since I've looked at CHM that I can't remember how it was laid out. ISTR the map .gifs (generated by PHP) being 700x700 and that's about it.
I was almost thinking something along the lines of frames or iframes or divs  or however it's done, to keep the map in place while the user scrolls around the table(s), but...
Keeping the map its current height would leave little to no room below for the table.
I'm unsure how practicable displaying map & table side-by-side would be, especially for those running lower resolutions. I was at 1280x960 for many years.
I don't have a good solution to offer. Maybe CHM worked as TM does now, where we would just scroll the map off the top of the screen.

CHM only required the map to be scrolled past once it was displayed.  There was a drop-down for which map to display (as the CHM maps couldn't be zoomed in or out, one had to select between the statewide map and closer-in maps from around the region).

I like the idea of using a check-box to show/hide the map, but maybe that's a bit much?  When michih proposed his tabs, I was originally thinking switching what was displayed with JavaScript, but it seems that he's actually envisioning separate pages.

Yeah, displaying it sideways wouldn't work, unless the CSS was responsive enough to be able to switch to the current view if there isn't a certain width available (FYI, the resolution on my desktop (Antares) is "only" 1600 x 900, and I don't keep Chrome maximized, either; my laptop (Vista) has more room with 1920 x 1080).

Comparing loading times between region.php & mapview.php for a couple large states, the newer mapview code loads a lot faster. (More efficient SQL queries?) It'd be nice to similarly improve region.php.
Mapview does redline one CPU core on my client machine the entire time it's loading, whereas region.php just has a short burst of activity after the data comes over the network and it renders the map & table.
If we could get the faster loading times along without all the CPU use, that'd be gravy. (Or is the CPU use a necessary side effect of JSON/AJAX?) If we can't have that, then I'll take the faster load times of course.
Any performance improvement from using MySQL 8.0? Unclear. Mapview load times vary quite a bit on lab2 between successive loads.

Interesting.  I wonder when that happened.  I remember Mapview taking a significantly longer time than region/system for everything, so I've been avoiding unless I wanted to use the color by traveler count feature or the scrollable version.  I did some tests today for various regions/systems and put the results below (the results are the same for both Antares and Vista, at least for NY; I didn't feel the need to re-run everything, and quite frankly, I have no desire to ever load usaus in mapview ever again).

Code: [Select]

KY R - 1m 15s
KY M - 31s
NY R - 17s
NY M - 10s
DC R - 2s
DC M - 1s

usaus S - 15s
usaus M - 8m 18s
usai S - 10s
usai M - 50s
usaky S - 2s
usaky M - 20s
usany S - 2s
usany M - 5s
canqca S - 0s
canqca M - 1s

Looks like region is now significantly faster in mapview, but system is still significantly slower.  Given how long it takes to load usai and especially usaus (which resulted in multiple Chrome popups asking me to kill the page (!)), I do not think it would be a good idea to remove maps from system at this time.

I also decided to do a test on my phone.  NY took 1m 45s to load with Mapview and only 24s to load with region.  Given this, and that Mapview isn't exactly phone accessible (not that TM as a whole is, but Mapview is especially bad), it would be a good idea for the maps to remain in region as well.

[SSOWorld]

I agree on phone accessibility of MapView - yet it turned out handy in phone Chrome so I could "hover" on it to see where I am with the route (without killing myself that is )

[yakra]

Odd that there would be such a time difference on a phone. Different browsers' JSON implementations, or something?

Interesting.  I wonder when that happened.

Surely with the scrollable version.

Looks like region is now significantly faster in mapview, but system is still significantly slower.

Never thought to check system. Interesting. I only had the patience to try to duplicate your results with usai, but indeed I did.

With system so much faster than mapview, this suggests there are still some more efficiency gains to be had.

Longer term, maybe some new database tables could speed up loading times, and cut down on the # of JOINs.
Or maybe indexes to speed things up; aren't some of those used already?

[Jim]

I think there is a lot of room for DB improvements, in the design of the tables, adding things like more indexes, configuration and hardware improvements on the server, and rewriting queries to run more efficiently.  I keep hoping someone with more expertise than me in databases will take interest in the project and tell us what we're doing poorly, or better yet, implement some fixes!

[osu-lsu]

I know of a "roadgeek" that works for Google (or Alphabet) out in California. Jimmy (James) Lin has been part of the crew assembling the digital Lincoln Highway map, for the LHA, over the last decade. I'd be willing to reach out and see if he be interesting in helping out here.

[vdeane]

Interesting.  I wonder when that happened.

Surely with the scrollable version.

I think Mapview was comparable to region/system before the scrollable version, which initially slowed things way down, but there might have been efficiency improvements since then.