Highway Browser Design

[Jim]

Our current Highway Browser code is a bit of a mess.  The same php code is used to generate the list of systems, list of routes within a system, and the actual map of a route.  I'd like to streamline this code to make it easier to search for a route, and to separate out the map code from the clunky waypoints.js.php that was thrown together quickly based on how CHM worked (note it's still the "Draft" HB) when TM was rising from the ashes of CHM.

Looking at some discussions here on the forum and in GitHub Issues, it looks like there are a number of things we'd like to see work differently with the HB.  Some have to do with finding continuing and adjacent routes, others have to do with automatically generating list file entries, I'm sure there are many others.

With the new support of 6-field list file entries, does it make more sense to have the HB, by default, deal with connected routes?

So I open this thread as a place to start gathering ideas.  I don't promise I'll be able to get to a new HB soon, but I hope I can.  This is working toward some new HDX algorithm visualization functionality that's of higher priority for me, but all I'm learning in the development of the Scrollable Mapview and top stats pages, and possibly in a new and improved HB, would help me toward that goal.

[si404]

I think connected route browsing as default needs to be tied to automatic list entry generation. But then that could be me not being familiar with the new 6-field .list file entries.

If browsing by region, you are going to want to get chopped routes. Connected routes make no sense as you browse say, MA, and click I-90 and suddenly are presented with a route that spans to the Pacific - that's not helpful if mapping Massachusetts travels!

But browsing by system, then connected routes makes sense - at least as an end game.

[michih]

Why do we still need region-segments at all and don't go with "connected routes" as "routes" per default? with the 6-field user list file option? the old style is still supported and would still work. The UI would need this feature only: https://github.com/TravelMapping/Web/issues/421#issuecomment-636612618

I prefer doing ONE well-thought-out change instead of multiple minor steps with much more effort on coding and for users getting familar with.....

I don't talk about wpt files and our maintenance by regions but what we present on the UI.

[michih]

Idea of how to browse routes/waypoints (from 2017)

[yakra]

I think connected route browsing as default needs to be tied to automatic list entry generation. But then that could be me not being familiar with the new 6-field .list file entries.

If browsing by region, you are going to want to get chopped routes. Connected routes make no sense as you browse say, MA, and click I-90 and suddenly are presented with a route that spans to the Pacific - that's not helpful if mapping Massachusetts travels!

But browsing by system, then connected routes makes sense - at least as an end game.

This.

Edit: Bolded the bits I agree with.

[michih]

If browsing by region, you are going to want to get chopped routes. Connected routes make no sense as you browse say, MA, and click I-90 and suddenly are presented with a route that spans to the Pacific - that's not helpful if mapping Massachusetts travels!

But if the I-90 route would be opened with the same zoom-level and at the same lat/lon...

[si404]

But if the I-90 route would be opened with the same zoom-level and at the same lat/lon...

Still, if you are browsing by region, you want to browse the region specifically.

You don't want to be looking at, say, Brandenburg and click E30 and have it draw not just the 171.15km of route in Brandenburg, but the whole 5416.91km of the 11-segment connected route from Hoek van Holland to Omsk. Because you have actively filtered the list to look at only Brandenburg.

It doesn't matter if you can only see from Eilsleben to Swiebodzin when it loads (rather than a couple of zoom levels out and centred on somewhere roughly south of Moscow as you would to get the whole connected route in) - what matters is that you'd get the bits west of Ziesar and east of the Oder drawn when you didn't want them.

We don't want to flip to the other extreme - where instead of routes being chopped up by region in the browser whether you like it or not, we end up with routes not chopped up whether you like it or not.

[yakra]

But if the I-90 route would be opened with the same zoom-level and at the same lat/lon...

Not sure I understand what your concern is here.
Sure, the route would extend far off the end of the screen, but we already get that now with chopped routes.

Still, if you are browsing by region, you want to browse the region specifically.
...
We don't want to flip to the other extreme - where instead of routes being chopped up by region in the browser whether you like it or not, we end up with routes not chopped up whether you like it or not.

Agreed.

[si404]

But if the I-90 route would be opened with the same zoom-level and at the same lat/lon...

Not sure I understand what your concern is here.
Sure, the route would extend far off the end of the screen, but we already get that now with chopped routes.

I think the point being made was that it doesn't matter whether the route extends at the west end off screen to Stockbridge or Seattle.

It does, as I've now explained why, but it was a fair point given the issue at hand hadn't been adequately explained.

[michih]

But if the I-90 route would be opened with the same zoom-level and at the same lat/lon...

Not sure I understand what your concern is here.

I said that it's fine. Si has concerns.

[yakra]

Ah, got it. I wasn't fully following the flow of the discussion.

I think, WRT Intersecting/Concurrent Routes links:
When browsing in "chopped route" mode, links should go to another chopped route.
When browsing in "connected route" mode, links should go to another connected route.

With the new support of 6-field list file entries, does it make more sense to have the HB, by default, deal with connected routes?

I think connected route browsing as default needs to be tied to automatic list entry generation.

I don't share the opinion that it needs to be tied to automatic list entry generation, though I don't think it should be default either.
Should there be a "default", per se?

If browsing by region, you are going to want to get chopped routes. Connected routes make no sense as you browse say, MA, and click I-90 and suddenly are presented with a route that spans to the Pacific - that's not helpful if mapping Massachusetts travels!

But browsing by system, then connected routes makes sense - at least as an end game.

One possibility:
When browsing a route list filtered by region, link to only chopped routes, of course.
When browsing a route list filtered by system and not region, then we can link to a connected route.
Thoughts?

[michih]

Thoughts?

Seconded! All you wrote (based on your last edit about 36 minutes ago)

[Jim]

I'm deciding if I have time to tackle this before I need to move my attention over to the HDX world.

Current thoughts:

• The HB's functionality needs to separate out the lists of routes and systems from the actual browsing of a route's waypoints and connections.
• Some or all of the listing part probably can be replaced with the current region.php and system.php pages, either as-is or with some enhancements.  Interested in opinions on this. I would not miss our current ugly lists.
• It might also be nice to have a search box like what HDX uses to load graphs as you type away and see partial matches.
• For the actual viewing of routes on maps, I believe the new HB needs to be able to handle either r= to display a chopped route, or cr= to display an entire connected route, independently of how a user arrives at that page.
• The DB access will be replaced with AJAX calls to remove the dependency on waypoints.js.php.
• A page loaded with an r= to get a single chopped route should look much like the current HB maps.  The info in the tables on the left should be similar.  Marker popups should show similar information to what they do now.
• A page loaded with a cr= to get a connected route should have a similar look, but the info in the tables on the left needs to represent the entire connected route (maybe with some separators at region boundaries).  Marker popups should show labels with route info, suitable to be pasted into a 6-field list entry.  Markers at region boundaries should list the waypoint labels from both routes.  I'm not sure if there should be any visual indication on the map or in the tables about which parts are from which chopped routes (different colors?).
• In either case, I would like users to be able to select segments and have a convenient way to copy-and-paste one or more .list entries that correspond to the selected segments.  Possible ways to manipulate the selection might include clearing the selection, selecting all segments currently marked as traveled by the user in the DB, selecting individual segments, or a sequence of clicks to select a start and end waypoint/segment.  When viewing with r=, the list entry/ies would be 4-field, when viewing with cr=, they'd be 6-field (even if within the same region/chopped route).

[michih]

• It might also be nice to have a search box like what HDX uses to load graphs as you type away and see partial matches.

Nice? That would be great! I was about to ask for it many times in the last days but just didn't dare.... It should be used all over the site in HB, mapview, region.php, system.php and datacheck.

• In either case, I would like users to be able to select segments and have a convenient way to copy-and-paste one or more .list entries that correspond to the selected segments.  Possible ways to manipulate the selection might include clearing the selection, selecting all segments currently marked as traveled by the user in the DB, selecting individual segments, or a sequence of clicks to select a start and end waypoint/segment.  When viewing with r=, the list entry/ies would be 4-field, when viewing with cr=, they'd be 6-field (even if within the same region/chopped route).

Seconded. I prefer having a button for "copy to clipboard".

[yakra]

• The HB's functionality needs to separate out the lists of routes and systems from the actual browsing of a route's waypoints and connections.

The functionality is already different, pretty separate. Do you mean separate tem out into separate PHP pages, the way CHM had selecthwys.php & hwymap.php?

• Some or all of the listing part probably can be replaced with the current region.php and system.php pages, either as-is or with some enhancements.  Interested in opinions on this. I would not miss our current ugly lists.

Replaced? Unless I'm missing something, I don't like this -- region.php and system.php are for user stats, and should remain focused on that function. Searching & filtering routes to browse should be something distinct from that.

• For the actual viewing of routes on maps, I believe the new HB needs to be able to handle either r= to display a chopped route, or cr= to display an entire connected route, independently of how a user arrives at that page.

Agreed.

• The DB access will be replaced with AJAX calls to remove the dependency on waypoints.js.php.

Had a go at waypoints.js.php for Web#101, and found it pretty hard to understand.

• A page loaded with an r= to get a single chopped route should look much like the current HB maps.  The info in the tables on the left should be similar.  Marker popups should show similar information to what they do now.
• A page loaded with a cr= to get a connected route should have a similar look, but the info in the tables on the left needs to represent the entire connected route (maybe with some separators at region boundaries).  Marker popups should show labels with route info, suitable to be pasted into a 6-field list entry.  Markers at region boundaries should list the waypoint labels from both routes.

Agreed.
I wondered as I read, about how waypoints at boundaries would be handled in the table. Following along from the idea in the last sentence, we're acknowledging their "dual identity", so it makes sense to list one route's waypoint, the separator, then the other route's waypoint.

I'm not sure if there should be any visual indication on the map or in the tables about which parts are from which chopped routes (different colors?).

I don't like the idea of different colors. Better to not disrupt the clinched/unclinched color scheme we have already.

Maybe something like drawing a short perpendicular (dotted?) line at the boundaries.
Or using a different waypoint marker for the begin/end of the chopped routes.

How do we get that info from the DB?
Compare the root values of adjacent pointId values.
It's possible, I donlt really know how fast or efficient that might be.

Seconded. I prefer having a button for "copy to clipboard".

Yes.