Update region.php and system.php

[jteresco]

These still use some older code (#572, #573) for the inline (smaller) map above the tables. These pages should be updated. The maps can likely reuse the new AJAX code written for showroute and mapview to load and display data. This would make those maps more consistent with others on the site. And much of the messy code could then go away.

[jteresco]

When redoing, could add shields to the tables.

[michihdeu]

When redoing, could consider a visual reorganization, e.g.:

https://forum.travelmapping.net/index.php?topic=4019.msg21519#msg21519

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

This proposal would also include #97 and #54 to some extent.

https://forum.travelmapping.net/index.php?topic=4019.msg24321#msg24321 ("direct link" request)

[yakra]

Suggest replacing system.php & region.php with one new page that can filter by any number of systems and regions.

[michihdeu]

one new page that can filter

A filter means that all data must be loaded first. Just like https://travelmapping.net/hb/findroute.php which is not very popular.

[yakra]

Nope. I mean filtering the way region.php and system.php already do, using a DB query before loading.

[jteresco]

A couple of quick things related to this.

I would use the new style of AJAX calls to load from the DB, but that does not mean the whole set of data would need to be loaded like in findroute.

As the amount of data has grown, having the smaller map there by default doesn't make much sense to me. I know if I want to see my stats in usaus, I really don't want to wait for the map data to load and display. It seems it would be better to have just the tabular representation of whatever systems/regions/countries/continents/etc, are selected for viewing, and a link to bring up a map of all of that using the newer mapping code on a separate page.

The big question on how difficult enhancements would be is whether we just need new queries on the existing DB tables or if new tables or columns of tables will need to be added.

[michihdeu]

I fully agree!

[vdeane]

I think the idea behind one page for both region and system is to have the code done once, and have it know whether to load a regions or system based on whether it gets "region=X" or "system=X" passed in the URL, similar to how the existing pages know which region or system to load based on what's passed in the URL.

If we're going to get rid of the existing maps on system.php, we should probably find a way to make maps of whole systems display faster in the new code. The testing I did on the forum thread a while ago showed that it's still significantly slower than the existing code (to the point where it's not practical to load usaus in the new code, and even usai is painful), unlike regions, where the new code is faster.

[yakra]

I think the idea behind one page for both region and system is to have the code done once

That's part of it. Everything under 1 roof with 1 file to maintain is a good thing...

and have it know whether to load a regions or system based on whether it gets "region=X" or "system=X" passed in the URL

More precisely, load any combination of any number of regions & any number of systems. Versatility. I thought we didn't have have this capability now, but it looks like we do. https://travelmapping.net/user/system.php?units=miles&u=yakra&sys=usasf,usausb&rg=NH,ME https://travelmapping.net/user/region.php?units=miles&u=yakra&rg=ME,NH&sys=usausb,usasf Tested it out before; must have done something wrong. I don't see recent changes here... Edit: Maps work. Stats?

The idea here is to take a step toward "only include the stuff you care about".

---

I like having the maps here, and would be sad to see them go. The UI's a bit suboptimal, having to scroll the map off the screen to look at the tables. Maybe have a map on the left in a DIV, with the tables on the right in another.

'Course, I'm running1680x1050; it may not work so well for those with narrower displays unless the tables are slimmed down.

[vdeane]

Yeah, the display could be an issue. I'm not sure how it would work on mine, and I'm not much less, though I don't routinely have Chrome maximized, either (I think I have it around 60% the width of the screen).

I wonder how hard it would be to have a check box or drop-down menu for how the map should be displayed ("None", "Left", and "Top"?).

[michihdeu]

I wonder how hard it would be to have a check box or drop-down menu for how the map should be displayed ("None", "Left", and "Top"?).

I think that displaying is a small issue but loading times are a huge painful issue... I'd prefer getting rid off them. They are perfectly available on mapview.php - with much more options!

[vdeane]

Could it be possible to default it to "none" and have it load only if another option is selected? We have some of that now on mapview.php - the names of travelers on a given segment are only displayed after clicking on the number of travelers to reduce the load on the database. As mentioned, at least for systems, it is currently far more practical to load anything large (like the interstates, or especially US routes) on system.php than on mapview.php.

[michihdeu]

As mentioned, at least for systems, it is currently far more practical to load anything large (like the interstates, or especially US routes) on system.php than on mapview.php.

If I got it right, it is caused by the AJAX code. Jim plans to use AJAX for region.php + system.php too.....

[jteresco]

I don't think there should be anything fundamentally less efficient about AJAX (new code) vs. PHP on load (old region and system). The old code needs to go some time, so aside from the quick and very welcome fixes @yakra is providing, I would like to focus on how we can make the new code as efficient as possible.

[vdeane]

I would hope there would be some way to get the new code to work as well for systems as it does for regions (it's interesting that there's such a disparity; regions load faster in the new code, but systems are the opposite). Until that time, the old code should probably be kept at least for systems, as otherwise maps for ones like usaus would be difficult to view.

[michihdeu]

@vdeane is there a Github issue describing this mapview.php behavior?

[vdeane]

Not sure, so there's a good chance there isn't. I don't even remember which forum thread prompted me to measure how long regions/systems took to load (and therefore has the results).

[yakra]

https://forum.travelmapping.net/index.php?topic=4019.msg21520#msg21520 https://forum.travelmapping.net/index.php?topic=4019.msg21550#msg21550