Produce a "things to check out" in user logs?

[jteresco]

Thinking about some of the emails I get from users when they send in .list updates, where they find the errors in their lists from highway data updates over the course of a few days, it might be nice to have a report for users indicating which routes they have in their lists that have recent updates entries.

[michihdeu]

the long list is also fine. It's just ctrl+End

[yakra]

I wrote:

Anything that generates an error message doesn't flag a Route as traveled, and we won't see an update notification. So users won't be helped when they're wondering what's going on when they see new error messages. In cases where the Region + Route combo is valid and lookup of labels fails, we still have a valid Route object with a pointer to an updates entry. It would be helpful to include info in these cases too. 6-field entries will be ~slightly~ more complicated ~but still easy enough~.

• [x] Equivalent waypoint labels mark zero distance traveled implemented locally
• [x] Waypoint label... not found (6-field)
• [x] duplicate label cases shouldn't be included. Never implemented for 6-field; removed from 4-field.
• [x] Unknown region/highway combo cases will be no-build because reasons.
• [x] not in same connected route gets tricky. Consider cases where a ConnectedRoute gets broken. It's possible for HighwayData changes to turn a valid 6-field .list line into an error. Imagine that we had 6-field list lines in place before splitting US20 at Yellowstone. OR US20 US101 MA US20 MA2_E is broken not because of a change in OR or MA, but because 2019-01-06 | (USA) Wyoming | US 20 | wy.us020 | Route truncated at west end from Montana border to Yellowstone National Park Entrance. What I'm thinking is, list updates entries for the first & last chopped routes in each ConnectedRoute. Sure, there will be a little extraneous info (worst case, 3 extra update entries), but hopefully some info about the route that got truncated/split/decommissioned/etc. should also be there to point users in the right place. Note that these errors should be pretty rare; there are currently no not in same connected route errors in anybody's .log file. Thoughts?

---

Thinking about loosening the requirements for logging updates in the short list when the .list line has an error. This won't be a problem for users like @michihdeu or me, who always work to keep our .lists up-to-date and .logs free of errors. Any extra clutter will be minimal and transient.

• [x] Don't limit these cases to updates more recent than the last .list update. These can be considered supplementary info, part of the error message. The error messages themselves stay around until the underlying error is fixed.
• [x] Mention a route update even if that route has already been mentioned. (Arguably less useful?) ~Nope. Route entries tend to cluster together. I saw one log file where a 6-field entry with two bad labels was followed by another entry for the same route, yielding 3 Route updates: notes together back-to-back. The point is gotten.~ Yes, do this after all. Otherwise, routes previously entered on a valid .list line that were last updated before the .list file won't get noted in the log at all. Yes, there will be notifications for multiple routes, but that's a small price to pay for keeping .list processing relatively fast. Users should fix .list errors anyway. ;) At least for 6-field lines with 2 bad labels on the same chopped route, having just 1 notification is easy enough.

[jteresco]

Re: the use of non-ascii with Python and FreeBSD. I'll have to refresh my memory on it, and I think it should be a separate issue. Created #372.

[yakra]

Unknown region/highway combo should be treated the same as not in same connected route. A truncated ConnectedRoute that doesn't have a corresponding new ConnectedRoute created at the same time will fall into this category. Broken ConnectedRoutes are really just a special subset of truncated ones. Edit: Or would that just be creeping featurism? A truncated ConRte or a broken .list due to such would be rare. Seems Unknown region/highway combo would be just as or more likely a typo or garden-variety error, and a message about some other connected route segment might only muddy the waters...

[yakra]

Another reason to not do anything extra for multi-region Unknown region/highway combo cases: Seeing the most recent updates entries for NC US220 or PA US220 won't help when the only relevant entry is 2017-06-11;(USA) New York;US 220;;Deleted route.

[yakra]

"Last update" notes for duplicate labels shouldn't be added for 6-field entries -- they should be removed from 4-field entries. These aren't UserData problems; they're HighwayData problems; it's on us to fix them. Knowing when the last update happened does not help the user. That little extra prompt to "Please report this error in the Travel Mapping forum" does.