Author Topic: New HB findroute implementation  (Read 1550 times)

0 Members and 1 Guest are viewing this topic.

Offline Jim

  • TM Collaborator
  • Hero Member
  • *****
  • Posts: 1903
  • Last Login:Yesterday at 11:33:32 pm
New HB findroute implementation
« on: June 26, 2020, 06:50:09 pm »
I have a first version of a new way to search for routes in the Highway Browser to be viewed with showroute.

https://tmtest.teresco.org/hb/findroute.php

It will take some time to load at first - it has to deal with our nearly 60,000 chopped routes.  On my MacBook Pro it takes 10-15 seconds before the full table comes up.

Once it's up, you can filter routes by any of the dropdowns, or search for a pattern within a route name (hit enter in the box to perform the search).  Searches can take a couple seconds, as it needs to filter all 60,000 of the routes.

You can also provide rg= and/or sys= QS parameters to set the filters at the start.

I intend this as a new option for people to find routes, not necessarily as a complete replacement for our existing HB lookup capabilities.

I know speed is an issue but probably isn't anything that can be helped too much if we want to be able to search all routes on a single page like this.

For now, I'm looking for comments, suggestions, etc.

Offline michih

  • TM Collaborator
  • Hero Member
  • *****
  • Posts: 2816
  • Last Login:Yesterday at 02:16:24 pm
Re: New HB findroute implementation
« Reply #1 on: June 27, 2020, 03:49:03 am »
1. Cool :)

2. When filtering anything from column tier to region, it always takes a while. I would be nice to get a message "in progress" or whatever

3. Route name column is case-sensitive. Typing "a1" does not output "A1" but it would be nice if it would

4. Route name column just outputs what matches. Typing "A1" outputs everything starting with A1, e.g. A1, A11, A12 etc.; It would be nice to make an exact match for A1 only. Maybe optionally "A1*" for all? However, what should be output when I filter for "*1*"? Hm...

5. A "Reset all filters" button would be nice

6. A different color for active filters would be nice, e.g. when I filter tier for "1", it could be displayed in a different color, e.g. blue.

7. Maybe some color would be nice, e.g. active/preview/devel color code or system color code?

8. Do we need the ".list Name" column? If we keep it, we should also be able to filter it

9. I like that there is a "country" column. Is it possible to add a "continent" column?

10. I'd reorganize the columns:
Tier - System - Country - Region - Route Name - .list Name - Level - Link
->
Tier - Continent - Country - Region - System - Route Name - (.list Name) - Link - Level
I'm just not sure about the "Level" column

11. Maybe "Route Name" and "Link" could be merged?

Offline michih

  • TM Collaborator
  • Hero Member
  • *****
  • Posts: 2816
  • Last Login:Yesterday at 02:16:24 pm
Re: New HB findroute implementation
« Reply #2 on: June 27, 2020, 03:54:30 am »
I intend this as a new option for people to find routes, not necessarily as a complete replacement for our existing HB lookup capabilities.

A simple "Don't show routes" check box (default = true) would make the trick... ;)

Omit Route Name - (.list Name) - Link columns and just show:
Tier - Continent - Country - Region - System - Level

It's the very same like https://tmtest.teresco.org/hb/ but with filter option!

Offline Jim

  • TM Collaborator
  • Hero Member
  • *****
  • Posts: 1903
  • Last Login:Yesterday at 11:33:32 pm
Re: New HB findroute implementation
« Reply #3 on: June 27, 2020, 10:38:18 am »
Thanks for the suggestions.  Many are easy enough and I'll get them in.

For the Route Name filtering text, I'd like to come up with something intuitive to regular users but very flexible for power users.

Idea 1: a dropbox next to the text with choices for things like exact match, substring match, match at beginning, full regex

Idea 2: have special notations available, possibly by default a substring match, in quotes an exact match, prepend ^ for match at beginning, and enclose in // for full regex matching.

Offline michih

  • TM Collaborator
  • Hero Member
  • *****
  • Posts: 2816
  • Last Login:Yesterday at 02:16:24 pm
Re: New HB findroute implementation
« Reply #4 on: June 27, 2020, 01:01:07 pm »
Is it possible to apply the (Region + system) selection from HDX to the site? The logic behind is quite good! I thought there is a Github issue for the web repository but I cannot find it right now.

Offline yakra

  • TM Collaborator
  • Hero Member
  • *****
  • Posts: 2847
  • Last Login:Yesterday at 02:31:39 pm
Re: New HB findroute implementation
« Reply #5 on: June 27, 2020, 02:36:09 pm »
Is this also AJAX-based like much of the other new code?
I sent my browser to https://tmtest.teresco.org/hb/findroute.php?units=miles&u=yakra&rg=ME straight away, and initially saw results for AFG, AGO, ALB, etc. while applying filters.
Seems that going directly to the routes specified in the filter without the intermediate everything step would save a lot of time.

Offline Jim

  • TM Collaborator
  • Hero Member
  • *****
  • Posts: 1903
  • Last Login:Yesterday at 11:33:32 pm
Re: New HB findroute implementation
« Reply #6 on: June 27, 2020, 10:04:48 pm »
Is this also AJAX-based like much of the other new code?
I sent my browser to https://tmtest.teresco.org/hb/findroute.php?units=miles&u=yakra&rg=ME straight away, and initially saw results for AFG, AGO, ALB, etc. while applying filters.
Seems that going directly to the routes specified in the filter without the intermediate everything step would save a lot of time.

It's AJAX mostly, but I wanted to load the whole mess at the start to make all searching and filtering afterward much faster.  Pay the price on load.

Offline oscar

  • TM Collaborator
  • TM Collaborator
  • Hero Member
  • *****
  • Posts: 1064
  • Last Login:Today at 03:23:22 am
    • Hot Springs and Highways pages
Re: New HB findroute implementation
« Reply #7 on: June 28, 2020, 11:47:31 am »
I previously suggested elsewhere that the old "related routes" feature should be retained. It isn't in the new findroute, replaced by a "View Connected Route" link. I think there should be also a "View Related Routes" link alongside the connected route link, to help users find related but non-connected routes. It would be very helpful to me, with the way I use the HB.

Offline yakra

  • TM Collaborator
  • Hero Member
  • *****
  • Posts: 2847
  • Last Login:Yesterday at 02:31:39 pm
Re: New HB findroute implementation
« Reply #8 on: June 29, 2020, 11:29:46 am »
It's AJAX mostly, but I wanted to load the whole mess at the start to make all searching and filtering afterward much faster.  Pay the price on load.
It will take some time to load at first - it has to deal with our nearly 60,000 chopped routes.  On my MacBook Pro it takes 10-15 seconds before the full table comes up.
Hmm. Hell of a price to pay though. On BiggaTomato, the full results appear at around 22s, with the filter not being applied until almost 1m51s.
The way I use the HB, there's almost zero chance of amortizing this. I'll set filters once when initially loading and go, almost never changing them.
With the old page, getting the results I needed was almost instantaneous.

I intend this as a new option for people to find routes, not necessarily as a complete replacement for our existing HB lookup capabilities.
Considering the time it takes to load, yes, I'd hate to lose the existing page, or at least something of comparable speed.

Offline Jim

  • TM Collaborator
  • Hero Member
  • *****
  • Posts: 1903
  • Last Login:Yesterday at 11:33:32 pm
Re: New HB findroute implementation
« Reply #9 on: June 29, 2020, 02:04:37 pm »
Wow, on the computers I've been using, the loading time tends to be 10-15 seconds, with maybe another 5 at most for the filters to apply the first time.  Changing the filters after initial load takes only a second or two.

I'd be interested to hear other reports.

Offline michih

  • TM Collaborator
  • Hero Member
  • *****
  • Posts: 2816
  • Last Login:Yesterday at 02:16:24 pm
Re: New HB findroute implementation
« Reply #10 on: June 29, 2020, 02:56:18 pm »
I'd be interested to hear other reports.

17 seconds on my notebook, 15 seconds on my smart phone. Initial load.

Offline si404

  • TM Collaborator
  • Hero Member
  • *****
  • Posts: 1336
  • Last Login:Yesterday at 05:40:13 pm
Re: New HB findroute implementation
« Reply #11 on: June 29, 2020, 03:24:05 pm »
I just got a load of about 30 seconds. It's not quick, but it's not horrific.

Offline michih

  • TM Collaborator
  • Hero Member
  • *****
  • Posts: 2816
  • Last Login:Yesterday at 02:16:24 pm
Re: New HB findroute implementation
« Reply #12 on: June 29, 2020, 03:40:35 pm »
Is it possible to apply the (Region + system) selection from HDX to the site? The logic behind is quite good! I thought there is a Github issue for the web repository but I cannot find it right now.

Apply UI selection mechanism from HDX


Offline michih

  • TM Collaborator
  • Hero Member
  • *****
  • Posts: 2816
  • Last Login:Yesterday at 02:16:24 pm
Re: New HB findroute implementation
« Reply #13 on: June 29, 2020, 03:44:19 pm »
I don't know whether the mechanism is just route-based. If not....

A simple "Don't show routes" check box (default = true) would make the trick... ;)

...could this reduce loading times? Maybe the table could be generated without routes and routes are just loaded in the background. If one disables "Don't show routes" they might already be loaded.

Just my 2c. Just an idea..........

Offline yakra

  • TM Collaborator
  • Hero Member
  • *****
  • Posts: 2847
  • Last Login:Yesterday at 02:31:39 pm
Re: New HB findroute implementation
« Reply #14 on: June 29, 2020, 04:33:20 pm »
Changing the filters after initial load takes only a second or two.
Also my experience as I recall, though I didn't test it out very much.

I'd be interested to hear other reports.
BiggaTomato has a Q6600 with 2xDDR2-800, running UbuntuMate 16.04
On lab1.5, Xeon E3-1230 with IIRC 2xDDR3-1333, running UbuntuMate 18.04, I get 16s to load the page, wither another 42s to apply the filters, for a total of 58s.

RAM:
Forgot to mention before, the page takes up about 800 MB while loading, and appears to free up about 200 MB once fully loaded. Yowch!
I expect this would use even more RAM as more systems & routes are added.