Travel Mapping
Web Design Discussion => General Web Design Discussion => Topic started by: Jim on June 01, 2020, 10:46:25 pm
-
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.
-
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.
-
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.
-
Idea of how to browse routes/waypoints (http://forum.travelmapping.net/index.php?topic=2018) (from 2017)
-
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.
-
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...
-
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 (http://travelmapping.net/hb/?units=miles&u=si404&r=deubb.e30) 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.
-
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 (http://travelmapping.net/hb/?r=ma.i090&lat=42.346420&lon=-71.060308&zoom=13).
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.
-
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 (http://travelmapping.net/hb/?r=ma.i090&lat=42.346420&lon=-71.060308&zoom=13).
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.
-
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.
-
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 (http://travelmapping.net/hb/?rg=MA), link to only chopped routes, of course.
When browsing a route list filtered by system and not region (http://travelmapping.net/hb/?sys=usai), then we can link to a connected route.
Thoughts?
-
Thoughts?
Seconded! All you wrote (based on your last edit about 36 minutes ago)
-
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).
-
- 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".
-
• 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 (https://github.com/TravelMapping/Web/issues/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.
-
• 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.
region.php (https://travelmapping.net/user/region.php?rg=ALB) already has a "HB" column (which is called "Map" ;) ). I think it's pretty fine to open the HB this way instead of using the superfluous HB list (https://travelmapping.net/hb/index.php?sys=alba).
system.php (https://travelmapping.net/user/system.php?sys=alba) opens the route in mapview and you can open the HB route (https://travelmapping.net/hb/?r=alb.a001thu). If mapview would directly be a kind of HB..... that would be pretty perfect too!
The issue is that region.php and system.php can only be opened (by clicks, not talking about url manipulation as I always do) from the user page and only for the desired region or system if you already have some mileage there. This is the only reason why one currently needs to go via HB (https://travelmapping.net/hb/). If this issue could be solved, so that you can even open routes without previous user selction (that means what NEW users would do), I would be very happy to get rid off the current HB section lists!
Let's get rid off:
- https://travelmapping.net/hb/
- https://travelmapping.net/hb/index.php?sys=alba
-
That would be, like, some Microsoftian kind of unnecessary change just for the sake of change.
Which would make the site less intuitive & navigable.
If we got rid of https://travelmapping.net/hb/, then what would we link to from the header panel?
Travelers are most likely used to having that link, and many probably surf straight there to start looking at routes.
Issues with region.php & system.php include how a bunch of real estate is taken up at the top of the page by the map, and there's a bunch of extraneous info about a user's stats. Why not have a clean page of just a table of routes that a user is searching for, as we have it now? The table we have now does a good job of showing what's available without too much extra cruft.
I think it's pretty fine to open the HB this way instead of
This is certainly true.
But simply because one method of opening a route works, why should we remove another, arguably better, method?
If this issue could be solved, so that you can even open routes without previous user selction (that means what NEW users would do)
Which is one thing the HB is for.
-
Idea: perhaps we could retain the HB index but move route display to region and system? If something like that were to be done, there could be a URL argument and/or checkbox(es) to enable/disable the map and/or stats, and the HB index could have a flag that allows one to browse by either system or region.
On another note, I think it's interesting that we're now arguing about whether to keep the HB given that the HB actually pre-dates both TM and CHM. The entire project was originally just the HB for usai, an "interstate highway browser" that Tim posted to MTR one day.
-
The table we have now does a good job of showing what's available without too much extra cruft.
I cannot open mapview for a region I've not yet traveled. That's how I plan trips in advance. It's only possible by editing the url.
-
I was referring specifically to the HB there.
-
I cannot open mapview for a region I've not yet traveled. That's how I plan trips in advance. It's only possible by editing the url.
With the change that just went live on the main site, you can get to any region in Mapview through the popup that previously only supported giving a start location.
-
I cannot open mapview for a region I've not yet traveled. That's how I plan trips in advance. It's only possible by editing the url.
With the change that just went live on the main site, you can get to any region in Mapview through the popup that previously only supported giving a start location.
True! :) Should we add it to the TM header?
btw: I don't say that we should but only that we could eliminate the HB (https://travelmapping.net/hb/) since the mapview popup has the very same selection option. Only system status info (active, preview, devel) is missing.
-
I've decided I can put a little time into an HB redesign this week.
One change from above, I'm making r= a required QS param, and cr an optional one. You always would provide any TM root for r=, and if cr (no "=", like Mapview's v QS param) is also specified, the entire connected route with that (chopped) root is displayed.
I am thinking a single chopped route view will include a button or link to expand to the whole connected route (if it's more than just that one chopped route), and a connected route will have links within the page to restrict to an individual chopped route.
-
Making sure I parsed that properly...
https://travelmapping.net/hb/?r=me.me113
https://travelmapping.net/hb/?r=me.me113&cr
Yes?
-
Making sure I parsed that properly...
https://travelmapping.net/hb/?r=me.me113
https://travelmapping.net/hb/?r=me.me113&cr
Yes?
Yes. I could also go with the original r= and cr=, one of which would be required, but this simplifies things a bit, at least from the coding side.
-
I agree that it simplifies things. No need to worry about how to handle both r= & cr= in the same URL, for example.
I have no problems with this syntax.
-
I've noticed that now that HB windows have "mark current location", at the size I keep Chrome the top bar spills over into a second line, which is partially cut off. It looks like there should still be room for everything without changing the map size if the text were moved up a little closer to the top.
-
I've noticed that now that HB windows have "mark current location", at the size I keep Chrome the top bar spills over into a second line, which is partially cut off. It looks like there should still be room for everything without changing the map size if the text were moved up a little closer to the top.
I did a little tweaking of positions and font sizes on the new tmtest version. See what you think.
-
It still does that, but I do like the new font sizing in any case. For what it's worth, I have Chrome at a width where the tabs are full-size only if there are three or fewer (not for that reason, just an easy way to measure for this thread) when not maximized, if that would make testing easier.
-
It still does that, but I do like the new font sizing in any case. For what it's worth, I have Chrome at a width where the tabs are full-size only if there are three or fewer (not for that reason, just an easy way to measure for this thread) when not maximized, if that would make testing easier.
You hit on a site-wide problem, where we have long had many absolute positions and sizes for things that do not work well when pages are viewed on different size screens.
-
I have noticed a bunch of the recent changes and I like a lot of them. I'll admit that I haven't been following the forum too closely or really understand all of the details of the changes. So, I'm not sure if this is the right thread for this or if it is one of the others. It may be a little rambling, but here goes.
One thing I've noticed related to these new connected routes.
So, I usually have tabs up on the overall stats, then our stats, North Carolina (our home state), and then one with the state or states I'm looking at for trip planning. From our stats page, I use the Map link to open the state into its own tab or sometimes I just click on the row to go to region.php if I want to see where we rank in the state and the stats about systems and routes and the ranking of travelers. And sometimes I scroll down to the Stats by System. And I'll frequently click into the U.S. Interstate Highways or U.S. Numbered Routes.
https://travelmapping.net/user/?units=miles&u=mikeandkristie
https://travelmapping.net/user/system.php?units=miles&u=mikeandkristie&sys=usai
https://travelmapping.net/user/system.php?units=miles&u=mikeandkristie&sys=usaus
I noticed the new behavior when I scrolled down to one of the US routes and clicked on it. Looks like it has switched from "rte" to "cr" which I figured out. It was a little jarring at first as it only showed mainline in each state and none of the auxiliary or business routes. As I was trying to see if we had completed the mainline and auxiliary or just the mainline to sort them in our list. I started playing around and did find that I could play with the URL to switch over to "rte". Is there an easy way to view the auxiliary ones without changing the URL now?
I noticed it first on I-40 when it wasn't showing me the whole country. It is centering around the TX-OK border and showing from a little west of Amarillo to Oklahoma City. I tried lots of other long ones, both interstates and US routes. The east-west ones are centering in the middle and not showing the full route. The north-south ones do show the full US though.
Example of I-40 - https://travelmapping.net/user/mapview.php?units=miles&u=mikeandkristie&cr=ca.i040
[Long E-W that don't show everything]
https://travelmapping.net/user/mapview.php?units=miles&u=mikeandkristie&cr=ca.i010
https://travelmapping.net/user/mapview.php?units=miles&u=mikeandkristie&cr=ut.i070
https://travelmapping.net/user/mapview.php?units=miles&u=mikeandkristie&cr=ca.i080
https://travelmapping.net/user/mapview.php?units=miles&u=mikeandkristie&cr=wa.i090
https://travelmapping.net/user/mapview.php?units=miles&u=mikeandkristie&cr=ca.us006
https://travelmapping.net/user/mapview.php?units=miles&u=mikeandkristie&cr=wa.us012
[N-S that work]
https://travelmapping.net/user/mapview.php?units=miles&u=mikeandkristie&cr=ca.i005
https://travelmapping.net/user/mapview.php?units=miles&u=mikeandkristie&cr=ca.i015
https://travelmapping.net/user/mapview.php?units=miles&u=mikeandkristie&cr=nm.i025
https://travelmapping.net/user/mapview.php?units=miles&u=mikeandkristie&cr=fl.i075
https://travelmapping.net/user/mapview.php?units=miles&u=mikeandkristie&cr=fl.i095
https://travelmapping.net/user/mapview.php?units=miles&u=mikeandkristie&cr=fl.us001
https://travelmapping.net/user/mapview.php?units=miles&u=mikeandkristie&cr=fl.us023
I think this way just changed today after I was looking at it yesterday. I start looking at I-40 in NC. If I'm understanding, the "Related Routes" link is replaced by "View Connected Route". When I did I-40 this way, it sized out properly to show the whole country.
https://travelmapping.net/hb/showroute.php?units=miles&u=mikeandkristie&r=nc.i040
https://travelmapping.net/hb/showroute.php?units=miles&u=mikeandkristie&r=nc.i040&cr
So there seems to be some difference in how mapview.php and showroute.php handle the bounds on really wide east-west routes.
Mike
-
As I was trying to see if we had completed the mainline and auxiliary or just the mainline to sort them in our list. I started playing around and did find that I could play with the URL to switch over to "rte". Is there an easy way to view the auxiliary ones without changing the URL now?
Please add your expectation to this discussion: https://forum.travelmapping.net/index.php?topic=3700
-
As I was trying to see if we had completed the mainline and auxiliary or just the mainline to sort them in our list. I started playing around and did find that I could play with the URL to switch over to "rte". Is there an easy way to view the auxiliary ones without changing the URL now?
Please add your expectation to this discussion: https://forum.travelmapping.net/index.php?topic=3700
Thanks for pointing me to the right place.