Highway Data Discussion > Solved Highway data updates

VA: new error message on VA 228 Truck

<< < (2/2)

yakra:
So in the wee hours of Tuesday morning with consciousness rapidly fading, I was staring at some old code I'd changed & committed but never merged, and noticed a bug that would have kept duplicate AltLabels out of the unused_alt_labels set. (See the attached image if you're into that sort of thing.)
And it got the ol' gears turning. Do we want duplicate labels to be in unusedaltlabels.log? Or pointsinuse.log?
Did I introduce a new bug where there wasn't one before? Inadvertently fix a bug I didn't know existed? Replace an old bug with a new bug? Change the behavior of an existing bug? Or add a new bug on top of an old one? Probably that last one.

So I came to the forum, searched "please report", and found this thread.
Got just what I was looking for; it's an excellent case study.


--- Quote from: Markkos1992 on July 05, 2022, 04:03:21 pm ---EldSt by itself is fine in the new file.  The best thing to do here IMO is to remove EldSt as an alternate label under VA228_S.

--- End quote ---
There are a few different potential rationales for Mark having said this. For the sake for going down this rabbit hole, I'll assume he checked the logs and saw that EldSt was not in pointsinuse.log, and/or was in unusedaltlabels.log.
My bad!
It probably should have been flagged as in-use, but labels are only flagged as in-use when in a valid .list line that successfully credits at least one traveler with some mileage. Both labels must be found.
Speaking of that thread...

--- Quote from: yakra on May 15, 2020, 10:33:29 pm ---For the sake of simplicity, let's assume a perfect world with no duplicate labels.

--- End quote ---
Gee whiz. That didn't age too well now, did it? :pan:

That approach works fine for .list lines (like WY US89 YelNP WY/MT) where two valid labels map to the same point and credit a traveler with zero mileage. But duplicate labels are a different beast. There is a segment there to be clinched; it's just that travelers can't claim it if their .list lines can't be parsed. If the label is in a .list, someone's trying to mark the segment. And sometimes, as in the OP here, it can be a previously good line that was invalidated when the 2nd occurrence of the label was added.
Thus I think that duplicate labels should be added to pointsinuse.log and removed from unusedaltlabels.log, to avoid falsely giving the impression they can be safely removed from .wpts, and breaking .lists.

In this case though, no harm no foul! :)
Currently, 6 travelers use EldSt.
Using the git blame feature reveals their VA VA228TrkHer lines were added to their .lists between 2017 & March 2022. During this time period, VA228TrkHer was a complete loop. Load the old revision of the file into wptedit, and you can figure out what their travels were at the time.

* One user only had travels on the west side of the loop. There's nothing there to clinch anymore, so in their case it's a Good Thing their western waypoint was deleted and their .list line is broken entirely.
* Another four have VA VA228TrkHer VA228_S EldSt. If the AltLabel had been left in place, their .lists would be more broken -- they'd get an Equivalent waypoint labels mark zero distance traveled line in their user logs, and have no travels marked at all. So at least they have some travels logged, even if not their full clinches. But hey, this is what route update notifications in user logs are for! ;)
* Only terescoj.list was really broken-broken. Instead of travels going south to the old EldSt, his travels are shown going north to the new EldSt. I sent him a PM; he'll update his .list.
Yeah. Anyway.
It's a very easy fix to implement this; I'll get on it.
Longer-term, I have some ideas to make DUPLICATE_LABEL info more helpful on the datacheck page.

yakra:
HD @ 20b7d92639184816d5f8df13a30ce038f42a7a5c
UD @ df786e01466418949faf02ee40f68306b864b11f

Navigation

[0] Message Index

[*] Previous page