Travel Mapping
Web Design Discussion => General Web Design Discussion => Topic started by: Jim on June 20, 2020, 05:59:23 pm
-
Now for your enjoyment and testing on tmtest: a new Highway Browser implementation to view chopped and connected route data, to replace the old functionality of /hb/index.php when r= was specified to load a route.
- The big new feature is to be able to show an entire connected route at once. When a connected route is displayed, labels in popups on the map include the .list name for easy selection of endpoints for the new 6-field .list entries that will be announced soon.
- When viewing a chopped route, there's a link below the .list name label to load the whole connected route (question: should this be there for connected routes consisting of just one chopped route?)
- When viewing a connected route with more than a single chopped route, you can link to individual chopped routes through the rows in the Route Stats table.
- Shading to indicate which segments are traveled in the Waypoints table now starts and ends in the middle of the rows corresponding to the endpoints of the travel. To me this is more accurate and intuitive, but I can put it back if there's an outcry against it.
- A single marker contains labels for both chopped routes where they meet at region boundaries.
- Much of this is a reimplementation for efficiency (no more dependency for the HB on waypoints.js.php!). It should also use somewhat less memory as some redundant or unused data is no longer created and stored.
- The Zoom to Fit link has been replaced with a button that just fits the existing data onto the screen, and does not require a reload.
- This reimplementation has been done with an eye toward future (long-requested) functionality to generate .list file lines by selecting points and segments on the map and in the waypoint table. That will be much more feasible with this simplified implementation.
Route selection using the big, ugly tables is unchanged so far, and still uses the /hb/index.php mechanisms for now, but links to routes will go right to the new showroute.php. Better search functionality is a project for another day.
I am sure I have some bugs, as this is several hundred lines of new or significantly reorganized or relocated code. Please report problems here or in GitHub Issues.
-
Shading to indicate which segments are traveled in the Waypoints table now starts and ends in the middle of the rows corresponding to the endpoints of the travel.
Nicely done. I like it.
Intersecting/Concurrent Routes:
When browsing a ConnectedRoute, clicking a link under Intersecting/Concurrent Routes links to the intersecting chopped, rather than connected, route.
Replacing the links in the popup with javascript:showRouteWithCurrentView('me.i095') is a step backwards IMO.
Those actual links to the HB were useful for copying link addresses to paste into the forum or GitHub or open in another browser window, and especially to right-click & open in a new tab, which I do frequently.
Was there something in particular that made the use of the javascript function desirable? In any case, we still need to query the DB and load all the new route's info...
-
When browsing a ConnectedRoute, clicking a link under Intersecting/Concurrent Routes links to the intersecting chopped, rather than connected, route.
I can change it if that's the preferred functionality.
Replacing the links in the popup with javascript:showRouteWithCurrentView('me.i095') is a step backwards IMO.
Those actual links to the HB were useful for copying link addresses to paste into the forum or GitHub or open in another browser window, and especially to right-click & open in a new tab, which I do frequently.
Was there something in particular that made the use of the javascript function desirable? In any case, we still need to query the DB and load all the new route's info...
Yes, I wanted to get the popups entirely created at startup time so I wouldn't need to store additional info to create them, but I don't know what the coordinates and zoom level will be when someone clicks, so instead I pass through to that JS function.
-
I can change it if that's the preferred functionality.
Seems most intuitive to continue browsing in the same mode.
OTOH, switching back to &cr mode is just one click away.
What will most travelers find more intuitive & useful?
Yes, I wanted to get the popups entirely created at startup time so I wouldn't need to store additional info to create them, but I don't know what the coordinates and zoom level will be when someone clicks, so instead I pass through to that JS function.
It's been a while since first implemented and I'm a little rusty, but I believe the bones of each popup was created at startup. Clicking on a waypoint marker or on the table would trigger some javascript to rewrite the innerHTML of the popup in question.
https://github.com/TravelMapping/Web/commit/701837f08c3bf7a861acfc3d69cd24de3e3d9c8a
If all popups are stored at startup, I can't see what additional info needs to be stored.
I'd love to be able to continue to copy links from the popup & especially open links in a new tab.
-
It's been a while since first implemented and I'm a little rusty, but I believe the bones of each popup was created at startup. Clicking on a waypoint marker or on the table would trigger some javascript to rewrite the innerHTML of the popup in question.
https://github.com/TravelMapping/Web/commit/701837f08c3bf7a861acfc3d69cd24de3e3d9c8a
If all popups are stored at startup, I can't see what additional info needs to be stored.
I'd love to be able to continue to copy links from the popup & especially open links in a new tab.
Yes, the main text was created at the start with an element whose contents would be replaced by the actual intersecting route links including the lat/lon/zoom.
I just changed the JS so it will open in a new window/tab. Maybe that's a good middle ground?
-
Re: the intersecting route link, I am going to be storing some extra data with each connection to support the .list entry creation, so it might not be much work or much more memory to store the info to create the popups on the fly and match the current HB's functionality.
-
Ooh, yes please! I would love that.
-
A lot of changes...
When clicking on "Intersecting / Concurrent Routes", a new tab is opened. That's really bad. It should just be opened in the same tab as in actual production HB version so that one can jump from route to route to map the travels.
-
The user list file entry should be presented a little bit more "visible". Maybe bold or in a different color.
And as mentioned before, I'd love to have a "copy to clipboard" button for it.
-
"related routes" is missing
-
"related routes" is missing
I don't plan to bring that back, given all of its flaws. If we want to have some sense of what routes are "related" to each other when not in the same connected route, I think we need to augment the data with information about what we mean by that.
-
"related routes" is missing
I don't plan to bring that back, given all of its flaws. If we want to have some sense of what routes are "related" to each other when not in the same connected route, I think we need to augment the data with information about what we mean by that.
But at least for now, the rte= functionality of mapview will remain for those cases when it provides some useful information.
We had discussion elsewhere about the flaws of rte=, but my quick summary:
- It relates routes that aren't related, like the unrelated routes worldwide that have names like "A4", the unrelated U.S. Interstates I-84, I-86, I-87, and I-88
- It fails to relate routes that should be related, like the I-35E/W pairs, and 3dis
-
When clicking on "Intersecting / Concurrent Routes", a new tab is opened. That's really bad. It should just be opened in the same tab as in actual production HB version so that one can jump from route to route to map the travels.
See upthread, I should be able to restore the same-tab functionality while still allowing a copyable link as I continue toward the .list entry toolbox functionality.
-
My first pass at .list entry generation in the new HB showroute is up on tmtest. To try it, click the "Show Toolbox" checkbox in the control bar at the top. Basic instructions appear in the draggable popup that appears when you enable that checkbox.
Useful?
-
I always get the whole route selected. From first to last wp. No chance to select anything else...
edit: Got it! Click on the segment, not at the wp as we are used to...
-
Screenshot of a DISCONNECTED_ROUTE error:
(http://yakra.teresco.org/images/chnjl.g25.png)
-
Marker popups now have links to intersecting/connected routes that should be the same as what we have in the production HB code.
-
I made a few minor fixes and enhancements here and there this afternoon, and then added some copy-to-clipboard functionality.
So like with the new Mapview a little while ago, I would like some help with testing, to make sure the new showroute on tmtest is still doing everything the old HB version of the same did for you, as well as get any additional comments/suggestions/problem reports about the new functionality.
I'm hopeful that the .list Entry Toolbox functionality (which I am going to leave with only segment-based selections, at least until after the initial version goes live) will be really helpful for new users, and even for experienced users who have been baffled over the years by beltways.
I'd like to merge this into the master branch and install it on the main site before I move on to other things, so if our regulars could take a look sooner rather than later, that would be appreciated.
-
It happens to me quite often that the "Processing Route Stats Data..." messages doesn't disappear. I jumped from small routes of about 10..20 wps to other small routes in Norway by using the intersecting routes link.
When I click on the intersecting routes link, the map is first loaded for Siena and then moved to the correct location. It doesn't happen with the old HB version. Loading times for jumping between intersecting routes are smaller with the old version.
When clicking on a wp on the wp list table, the map was centered with the old version but isn't with the new one.
-
It happens to me quite often that the "Processing Route Stats Data..." messages doesn't disappear. I jumped from small routes of about 10..20 wps to other small routes in Norway by using the intersecting routes link.
There's a timing issue there that I will resolve, hopefully today.
When I click on the intersecting routes link, the map is first loaded for Siena and then moved to the correct location. It doesn't happen with the old HB version. Loading times for jumping between intersecting routes are smaller with the old version.
For any showroute load, it shows the default map location until the data is loaded, then fits the map bounds to the data. This is because the DB reads for almost everything have moved from PHP on page load to PHP in AJAX calls, so the initial page shows up (with the default map) while data is loading. I'd expect overall loading times to be similar, since it's pretty much the same data, but I'm surprised that the new one is slower in the end given that we're no longer transferring and executing a giant chunk of JS code but instead getting only the data. Maybe the conversion to JSON and back takes more time than I think.
When clicking on a wp on the wp list table, the map was centered with the old version but isn't with the new one.
Do we want it to center? I can do that if that's the preference.
-
When clicking on a wp on the wp list table, the map was centered with the old version but isn't with the new one.
Do we want it to center? I can do that if that's the preference.
I think so!
-
It happens to me quite often that the "Processing Route Stats Data..." messages doesn't disappear. I jumped from small routes of about 10..20 wps to other small routes in Norway by using the intersecting routes link.
There's a timing issue there that I will resolve, hopefully today.
I think I've fixed this, please let me know if you encounter a message that doesn't go away.
-
Do we want it to center? I can do that if that's the preference.
I think so!
Seconded.
-
It happens to me quite often that the "Processing Route Stats Data..." messages doesn't disappear. I jumped from small routes of about 10..20 wps to other small routes in Norway by using the intersecting routes link.
There's a timing issue there that I will resolve, hopefully today.
I think I've fixed this, please let me know if you encounter a message that doesn't go away.
I think it happened in about 20..30% of the cases. I made about 30 tests now and it never happened again!
About centering at wp: It happend to me now that the route was not on the screen at all. Many cases where it was on the margin(?) but once the route was only on the visible screen when I zoomed out three times.
-
Centering on all marker popups is now in place. I did not do the same for segment popups, since I think all the bouncing around could be distracting for users trying to mark segments for .list entry generation.
Anything else missing or need fixing before this goes live on the main site?
-
This is live on the main site. Please report problems here or in a GitHub Issue.
-
This is live on the main site. Please report problems here or in a GitHub Issue.
Links need to be updated on the 'updates' page so we can 'bypass' the "Please continue with the new showroute page for this route" message and go to the new page right off the bat.
https://travelmapping.net/devel/updates.php
-
Thanks. Just fixed this and the datacheck.php links.
-
Would you prefer the "View Connected Route" link on chopped route pages in the new showroute.php to behave as it does now, where you are taken to an overview of the entire connected route, or would you prefer to have it link to the connected route with the current position and zoom level?
The current behavior is nice, because the link is static, and the functionality already works. It's easy to copy the link without following it, as there's no JS involved in it.
The other behavior would be nice for long routes, where you might be interested in seeing visible parts in neighboring regions without having to zoom your way back down. Plus, if you really do want the overview, Zoom to Fit is a single additional click to get it. It would also make this link consistent in behavior to the Connected/Intersecting Routes links in the popups.
-
The other behavior
This.
-
Was looking over the comments in Web#407 (https://github.com/TravelMapping/Web/issues/407).
What I would prefer:
• Center when clicking on waypoint table entries
• Do not center when clicking on waypoint markers on the map.
The current behavior makes opening an intersecting/concurrent route in a separate tab less usable, as the center lat/long will be different.
-
Was looking over the comments in Web#407 (https://github.com/TravelMapping/Web/issues/407).
What I would prefer:
• Center when clicking on waypoint table entries
• Do not center when clicking on waypoint markers on the map.
The current behavior makes opening an intersecting/concurrent route in a separate tab less usable, as the center lat/long will be different.
I think before I make any further changes related to https://github.com/TravelMapping/Web/issues/407 I'd like to get a better sense of what more people see as the preferred functionality. I think am far enough removed from having been a highway data manager that I am not noticing when small differences that seem inconsequential to me cause problems for those using these tools in plotting and updating highway data.
-
I fully agree with @yakra:
• Center when clicking on waypoint table entries
• Do not center when clicking on waypoint markers on the map.
-
• Do not center when clicking on waypoint markers on the map.
Does this mean don't move the map at all, because that will likely be more tricky since opening the popup might move the map even if we don't ask it to move.
-
I know that opening the popup can move the map. That's fine to me.
-
The previous behavior is fine. These cases are rare and minimal enough that I can live with them.
-
https://travelmapping.net/hb/?units=miles&u=yakra&r=nb.nb772 redirects to showroute.php.
https://travelmapping.net/hb/?units=miles&u=yakra&r=nb.nb772&lat=45.024233&lon=-66.938363&zoom=19 does not:
Fatal error: Uncaught Error: Function name must be a string in /home/www/tm/hb/index.php:251 Stack trace: #0 {main} thrown in /home/www/tm/hb/index.php on line 251
-
So from https://travelmapping.net/hb/showroute.php?r=fl.fl002 how do I find the other segment of the route (2Oke)?
-
Click on Florida State Highways (usafl) (https://travelmapping.net/hb/?sys=usafl), top-left, above the tables & shield, then look for it in the results? :(
-
Meh. It used to be possible to find related routes without getting the full list.
-
Yup. I'm not suggesting the solution I posted is the best solution.
-
Meh. It used to be possible to find related routes without getting the full list.
You used to get a full list of other sh.... Sure, all FL2 routes are in Florida and the result was accidentally what you expected. But have a try with routes like A1.
Related discussion, I think you are with oscar: https://forum.travelmapping.net/index.php?topic=3700
-
You used to get a full list of other sh.... Sure, all FL2 routes are in Florida and the result was accidentally what you expected. But have a try with routes like A1.
The way around that would have been to put a sys= filter into the link, as was temporarily done in the links from system.php:
https://travelmapping.net/user/mapview.php?rte=A1&sys=deua
...But we never did that for the Related Routes links, and now, for better or worse, the feature is gone.
I wouldn't mind having it back, and it seems others (oscar? neroute2?) might like it as well.
-
The way around that would have been to put a sys= filter into the link, as was temporarily done in the links from system.php:
https://travelmapping.net/user/mapview.php?rte=A1&sys=deua
...But we never did that for the Related Routes links, and now, for better or worse, the feature is gone.
That doesn't deal with:
1) bannered routes being related routes - a system filter is too narrow.
2) Jim's main gripe that duplicate numbers (eg I-88) are not related routes - a system filter is too broad.
It's a misdiagnose of the problem to just whack a system filter on it. Hence my thread to try and get a consensus on what the feature is there for in order to get it restored in a productive way.
-
Up on tmtest I have a version of showroute that includes a dropdown menu that lists the same routes we used to get in mapview when following the "Related Routes" link. I hope this serves the need while we sort out what related routes are and whether information will be added to the DB to give more meaningful results.
If this seems useful to anyone, I'll put it up on the main server.
-
If this seems useful to anyone, I'll put it up on the main server.
Love it :) :) :)
If there would be a checkbox "filter for same system" next to the dropdown, and the dropdown list would be reduce when it is on, the feature would be perfect! :)
-
If there would be a checkbox "filter for same system" next to the dropdown, and the dropdown list would be reduce when it is on, the feature would be perfect! :)
Instead of further cluttering the window, how about the contents are organized by the ones in the same system at the top, ones in other systems below, with some sort of separator?
-
If there would be a checkbox "filter for same system" next to the dropdown, and the dropdown list would be reduce when it is on, the feature would be perfect! :)
Instead of further cluttering the window, how about the contents are organized by the ones in the same system at the top, ones in other systems below, with some sort of separator?
Also fine to me! Is it possible to add a line afterwards?
DEU-BY B2
DEU-BY B2R
DEU-BY B2Wei
DEU-BY B2Bay
...
DEU-SN B2
DEU-TH B2
----------------- <== THIS
AB AB2ACal
AB AB2aGri
....
-
Why include routes from other systems at all?
-
^^
That doesn't deal with:
1) bannered routes being related routes - a system filter is too narrow.
2) Jim's main gripe that duplicate numbers (eg I-88) are not related routes - a system filter is too broad.
It's a misdiagnose of the problem to just whack a system filter on it. Hence my thread to try and get a consensus on what the feature is there for in order to get it restored in a productive way.
-
1) It doesn't deal with bannered routes in the context of usai <-> usaib and usaus <-> usausb. So I'll grant those cases, sure. I believe in all other cases bannered routes are in the same system as their respective parents. This, however, I see as running into the definition issue of "What's related?"
2) Not a problem. Incompletely filtering out some-but-not-all of the noise is better than filtering out none at all. Filtering by system may not get us all the way to where we want to be, but it can get us most of the way there.
the issue is the unrelated routes dragged in (and the related routes excluded by a filter).
1) is potentially related routes excluded by a filter.
2) is unrelated routes dragged in. We can at least tighten this up, even it by itself it doesn't solve the problem of #1.
-
Entries in the new dropdown menu are now grouped into those in the same system and those in other systems on tmtest.
-
Entries in the new dropdown menu are now grouped into those in the same system and those in other systems on tmtest.
Perfect, thanks! :)
-
Just FYI, the traveled/clinched routes page (https://travelmapping.net/shields/clinched.php?units=miles&u=the_spui_ninja&cort=traveled (https://travelmapping.net/shields/clinched.php?units=miles&u=the_spui_ninja&cort=traveled)) doesn't link to the new showroutes. It's not that big of a deal, but I thought I'd bring notice to it.
-
Just FYI, the traveled/clinched routes page (https://travelmapping.net/shields/clinched.php?units=miles&u=the_spui_ninja&cort=traveled (https://travelmapping.net/shields/clinched.php?units=miles&u=the_spui_ninja&cort=traveled)) doesn't link to the new showroutes. It's not that big of a deal, but I thought I'd bring notice to it.
Fixed, thanks.
-
Another FYI, the embedded maps in region.php and system.php still link to the old HB route display rather than showroute.
-
Another FYI, the embedded maps in region.php and system.php still link to the old HB route display rather than showroute.
Should be fixed, thanks.
-
Waypoints table percentages
(http://yakra.teresco.org/images/ny840.png)
ISTR that before, percentages were based on the total drivers of the route, not the total number of site users.
With each segment being traveled by 18/19 travelers, the percentages would be 94.7% rather than 6.67%
Clicking on waypoints
Right now, clicking on a waypoint marker on the map will cause the map to pan a small amount before opening the popup. Thus right-clicking & opening an intersecting/concurrent route in a new tab results in a map at a different center point. Makes 1:1 comparisons in different tabs a little tougher. Before, it would only scroll if the popup were partially offscreen. I'd like to get the old behavior back.
(Was there some other discussion about this upthread or in another topic?)