Not a bug, really, just probably an unforeseen situation:
http://tm.teresco.org/hb/index.php?units=miles&u=terescoj&r=nh.us004Note how Jim's travels end at the hidden point (
+NH120) between NH120_N and NH120_S.
Which is OK; US4 originally had one NH120 point, before I began development on USANH. Then, I split it into two points, to account for the 4/120 concurrency. As the "NH120" label was in use, I chose to hide it in situ rather than prefer either the new NH120_N or NH120_S.No one else is using the
NH US4 NH120 label.
Ergo, anyone clinching a segment with its east end at
NH US4 NH120_S has to have traveled at least as far as
NH US4 NH120_N.
Ergo, the 22.22% listed in the % column may represent the number of travelers clinching the
NH US4 NH120_S +NH120 segment, or the number of travelers clinching the
NH US4 +NH120 NH120_N segment, but not necessarily the number of travelers clinching the full
NH US4 NH120_S NH120_N segment.
The simplest way to fix this is for me to just make +NH120 a hidden AltLabel for a visible point. Then we just cross our fingers and hope this doesn't rear its head in the HB elsewhere.
(Only Jim is using +NH120, clinching a segment to the west, so NH120_N +NH120 may be the ticket; Jim can edit his .list & mark off a segment further east if appropriate.)(As an aside, I should probably move US4_E/NH120_S. The coords are appropriate for NH120, but not US4. Probably better off treating this like the functional rotary it is, and putting the point dead center.)I'm unaware of any other such instances in the project
(NY I-95 had +5 for a while, but that was merged into Exit 5A), but there could still be a few lurking about. (Anybody know of any? Europe? Si? Maybe?)
As far as how to head this off moving forward (short of a big rethink of how the HB is implemented)...
Maybe there could be a datacheck item, "HIDDEN_PT_INUSE" or something, though I'm not going to push for it very heavily.
There's always the possibility that Melvin could be hip to GitHub and could add
NB NB105 NB108 x22 to melvin.list, though I guess that could be marked off as a false positive...