#22902 closed defect (invalid)
False validator warning ref node not matching ref on connected way for power lines
Reported by: | Gazer75 | Owned by: | Gazer75 |
---|---|---|---|
Priority: | normal | Milestone: | |
Component: | Core validator | Version: | |
Keywords: | power ref numbering | Cc: | francois.lacombe |
Description
As title says. Line ref and tower/pole ref will usually be different so this should be ignored for anything power related.
Attachments (0)
Change History (6)
comment:1 by , 2 years ago
Keywords: | power ref added |
---|---|
Owner: | changed from | to
Status: | new → needinfo |
comment:2 by , 2 years ago
Open up this spot and run validator. https://www.openstreetmap.org/#map=19/58.28601/6.87278
You get a warning saying "Reference numbering don't match majority of way's nodes".
Guessing it is because the line ref on those are different than the tower ref which of course is quite normal.
Can't add the status report as it is apparently to long. And there was some words that also was not accepted for some reason.
comment:3 by , 2 years ago
Keywords: | numbering added |
---|---|
Resolution: | → invalid |
Status: | needinfo → closed |
Thanks!
It isn't connected to line ref
values in any way. The check is for the wrong numbering on towers/poles only. Speaking about the example, the longest consecutive numbering is on node/5537750248 and node/1851140393, therefore this "segment" is used as a reference for numbering check. As extra info, internally we need to store the direction. In this case, it's following the way direction.
So
- node/1851181721 is the 108th node on the way with ref 403,
- node/1851175602 is the 110th node on the way with ref 405,
- node/1851140393 is the 126th node on the way with ref 521 (one of the reference nodes, part of a virtual segment).
Assuming
- there is no missing node in the line (there is a validator for that as well ;) and
- the line is split on connections (why? because line relations require the line to be split)
the offset calculation can be done for node 1851181721:
Math.abs(candidate.startIndex - reference.startIndex) == Math.abs(candidate.startRef - reference.startRef)
which translates to abs(107 - 125) == abs(403 - 521)
-> false, meaning it's not aligning up. Same for the other node (1851175602).
Looking at the index and ref differences 18 and 118, I'm sure it's a typo. Probably the original editor wanted to type 503 and 505 for node/1851181721 and node/1851175602 respectively.
I can add an obvious typo checker, but I feel like that would be a bit too much for JOSM.
comment:4 by , 2 years ago
In most cases refs will be in line, but it can happen during upgrades that numbers are skipped. It can also happen that they add a tower that then might get like a [number]A and [number]B. This ABCD system is used on longs spans with monopolar towers btw. Typically fjord spans in Norway have this due to the distance. 4 cables across with one being reserve.
comment:5 by , 2 years ago
I came across many misnumberings and with this validation, I already discovered a fair amount. Also, the [digit][ABCD] format is currently ignored by this validation.
What's your suggestion then for JOSM?
comment:6 by , 2 years ago
Cc: | added |
---|
Could you please provide an example where the issue is showing up?
Also please provide a status report. Help/Action/ShowStatusReport