Travel Mapping
Highway Data Discussion => Updates to Highway Data => Solved Highway data updates => Topic started by: dave1693 on July 05, 2022, 02:52:25 pm
-
My log file just flung up this error message this morning, which was not present when I generated a log file late last week.
VA: duplicate label ELDST in va.va228trkher
Please report this error in the Travel Mapping forum.
Unable to parse line: VA VA228TrkHer VA228_S EldSt
This is in the log file I JUST generated. What's going on?
-
Thanks for reporting! It's also indicated on https://travelmapping.net/devel/datacheck.php?rg=va. @mapmikey changed the route file yesterday (https://github.com/TravelMapping/HighwayData/commit/20b7d92639184816d5f8df13a30ce038f42a7a5c#diff-63e9ecc749fcae70b53c5380a2b505d2805343e06c92147bfa0e977e62895749). I guess mapmikey made the change in the file without loading it to the wpt editor. The change is likely based on this report (https://forum.travelmapping.net/index.php?topic=4904.msg28214#msg28214).
-
Right1 Even if VA 228 Truck is limited (as intended) to the eastern side of Herndon Parkway, it intersects Elden Street twice. (Once at its southern end and once on the east side of Herndon.)
-
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.
-
corrected and sent in.
sorry about that...
-
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 (https://travelmapping.net/logs/unusedaltlabels.log)? Or pointsinuse.log (https://travelmapping.net/logs/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. (https://forum.travelmapping.net/index.php?topic=3613)
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? :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 (https://github.com/TravelMapping/HighwayData/commits/master/hwy_data/VA/usava/va.va228trkher.wpt), VA228TrkHer was a complete loop (https://github.com/TravelMapping/HighwayData/blob/dfb934fc3ca1b4637262f386a9a432b5e7004071/hwy_data/VA/usava/va.va228trkher.wpt). 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. (https://github.com/TravelMapping/DataProcessing/issues/412#issuecomment-1379852528)
-
HD @ 20b7d92639184816d5f8df13a30ce038f42a7a5c
UD @ df786e01466418949faf02ee40f68306b864b11f