Modify

Opened 2 years ago

Closed 2 years ago

Last modified 2 years ago

#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 gaben, 2 years ago

Keywords: power ref added
Owner: changed from team to Gazer75
Status: newneedinfo

Could you please provide an example where the issue is showing up?

Also please provide a status report. Help/Action/ShowStatusReport

comment:2 by Gazer75, 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 gaben, 2 years ago

Keywords: numbering added
Resolution: invalid
Status: needinfoclosed

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

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 Gazer75, 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 gaben, 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 gaben, 2 years ago

Cc: francois.lacombe added

Modify Ticket

Change Properties
Set your email in Preferences
Action
as closed The owner will remain Gazer75.
as The resolution will be set.
The resolution will be deleted. Next status will be 'reopened'.

Add Comment


E-mail address and name can be saved in the Preferences .
 
Note: See TracTickets for help on using tickets.