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.
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.
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...For the sake of simplicity, let's assume a perfect world with no duplicate labels.
Gee whiz. That didn't age too well now, did it?
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.
