Yikes, sorry I'm late to the party, guys. -_-
I rarely ever check the
unread replies page here on this forum, unlike on AARoads.
Everything from
Reply #7 onward is flagged as
. On that note:
Another issue: there are a bunch of U-turns on R-5 that I label by the nearest km post. R-5 has a zero point in Santiago, with *N and *S posts north and south of the city. So that leads to points like R5_U328N and R5_U1059S,
That explains those unusual looking labels. If I had seen this post I would have allowed more time for discussion and not been so quick to slap
DataProcessing#473 on top of
#472.
Now I understand why these points were labeled as they were, though I don't agree with the intent behind it.
which give a LONG_UNDERSCORE error that "is always a true error and cannot be marked false positive".
Sidestepping the issue of whether _U559 or _U1059S are "good" for the moment:
Even just going by
what's in the manual now, it's
possible -- however unlikely -- that a route could have 100 U-turn interchanges. If a
_U100 suffix flags an error that can't be marked as FP, that's plusungood.
So yes, this datacheck should be changed. And even if I don't like those letter sub-suffixes, I can avoid making the datacheck overambitious & flagging them.
So that's LONG_UNDERSCORE.
@yakra, what do you think about this? https://travelmapping.net/devel/datacheck.php?rg=CHL&show=LONG_UNDERSCORE,LABEL_SELFREF
As for LABEL_SELFREF?
DataProcessing#472 avoided flagging errors at
_U# labels. So far so good.
(Mostly. There was still a bug with INVALID_FINAL_CHAR cases with nothing after an underscore.)Then came
#473.
•
What I thought I was doing: fixing something still broken that #472 failed to fix.
•
What I arguably actually did: re-broke something that #472 fixed.
Reverting #473 while avoiding the bug in #472 is easy enough to do. Since for the moment it's already in there for better or worse, I'd still like to make the case that it stay.
First, I should clarify my comment:
Only problem is the manual sequential suffixes RN9_U1, _U2, etc., which would require a wholesale renumbering any time one is added.
It requires no such thing.
Then it needs to be clarified that it doesn't.
The potential need for renumbering is a maintenance issue, and the manual already says that
Care must be taken to ensure that changes do not "break" a user's list file.From a maintenance standpoint, _U1, _U2, etc. suffixes are similar to _A _B _C etc. suffixes. Or
fudged letter suffixes for same-numbered exits. Sure, when first added to a .wpt, they'll be neat & orderly. But sometimes necessary highway data changes + the need to avoid breaking .lists will result in
out-
of-
order labels or
breaks in the sequence.
That's what I meant by that.
We will have the same issue in ARG and likely other SA regions.
Will we though? IMO the issue of how to number U-turn ramps is secondary -- these cases aren't U-turn ramps at all! Even if ARG wants to
call them "retorno", that's a misnomer. They're just regular old interchanges.
Labeling them with _U### misapplies the rule, taking it outside the scope of
interchanges that are nothing more than a U-turn ramp in an attempt to fit a square peg into a round hole.
If it
does come to the point of adding km numbers tohave unique labels, why add the extra
R5_U clutter?
For the issue of
How to label unsigned junctions when there's no clear name available, I think a solution working within the existing rules is preferable.
My thoughts from the Rule Change thread:
How would we ever get to option 9? Are there situations where 8 can't be applied? IMO 9 is more limiting than 8, which could be used for roads without km-posts.
Seconded. I've only quickly skimmed the threads for the South American systems, but I don't see any reason we can't use truncated place names, or a need to introduce a new rule.
Have we exhausted all other possibilites for names, and there's not even a truncated distant placename to go with?
This, primarily. Do ARG or CHL have, say, county equivalents that could be used in a placename-type label?
If it fits the RN9_U111 criteria, which are already specified in the manual, let's go with that.
Emphasis added. I don't think it does, as noted above.
Then maybe a km number, (alone, no need for "km") if there are truly no other possibilities.
I don't see any reason "Mi", "Km", etc should be added. It's just extra cruft.
Thinking about this some more, I'm willing to walk back on it a bit -- "km" might be useful to indicate the label is not a standard exit number, but a placeholder for
inadequate highway data or other rare situations.