Opened 5 years ago
Last modified 3 years ago
#20716 closed enhancement
[patch] Search for missing power line support features — at Version 17
| Reported by: | gaben | Owned by: | team |
|---|---|---|---|
| Priority: | normal | Milestone: | 22.09 |
| Component: | Core validator | Version: | |
| Keywords: | power line segment | Cc: | Klumbumbus |
Description (last modified by )
Problem
The power lines are sometimes drawn from low quality satellite imagery, and support features can be easily missed.
Proposed solution
Add a java validator test to sort these issues out. It works as following:
- an average node distance calculated for the whole way (
lineorminor_line) - using mean and individual segment lengths, the standard deviation calculated
- if exceeds a threshold, a warning message created where both nodes highlighted to make manual checks faster
Way requirements to lower false positives:
- the way has to have at least 5 nodes
- segment length must be higher than a specific value, calculated as follows:
default threshold
- power=line ->
1.6 - power=minor_line ->
1.4
if (mean / stdDev) < 4 (high inconsistency) an extra 0.2 threshold value added.
If any segment length exceeds mean * threshold, the warning fired. In my testing, they give good results.
Usage
Run the validator as usual, an extra warning appears if the issue detected.
Change History (22)
by , 5 years ago
| Attachment: | josm_20716_power_v1.patch added |
|---|
comment:1 by , 5 years ago
| Summary: | Search for missing power line support features → [patch] Search for missing power line support features |
|---|
follow-up: 3 comment:2 by , 5 years ago
I see no use in the cast to float.
I think I've seen power lines in Japan where the distance between towers isn't very regular. Did you test this in areas with steep hills and water between?
follow-up: 4 comment:3 by , 5 years ago
Hmm, there is another minor issue found outside the patch context.
If there is a long line with a missing tower in the middle and the towers are referred with a number, the whole needs renumbered. I saw the references are just added without an actual survey but still, it's a bit dangerous to automatically fix the numbering.
Replying to GerdP:
I see no use in the cast to float.
I thought float is more than enough and saves memory.
I think I've seen power lines in Japan where the distance between towers isn't very regular. Did you test this in areas with steep hills and water between?
Yes, although only in my country which is mostly flat.
Preparing the next version of the patch, the tag collection is a bit outdated.
comment:4 by , 5 years ago
I thought float is more than enough and saves memory.
If you don't store it somewhere (with multiple copies) then a downsizing conversion will have no real gain. Variable sizes only count when you have many or large objects :-)
comment:5 by , 5 years ago
I'm more familiar with the microcontroller C/C++ world where every bit counts 😄
Currently testing the 3rd version of the patch around the world. With a variable threshold, there are minimal false positives. The line has 1.6, while minor_line has 1.8 multiplier.
by , 5 years ago
| Attachment: | josm_20716_power_v3.patch added |
|---|
comment:6 by , 5 years ago
Current state:
- power tagset updated, contained deprecated tags like
sub_station - added line segment checker with variable threshold, depending on line type (
lineorminor_line), needs testing - fixed some existing false positive warnings inside substations, where
power=lineandpower=line + line=busbar|bayconnects
Maybe the ref checker could be added as well.
I looked at the MapCSS if I can use it to be more portable (Osmose) but these checks need more advanced techniques.
comment:7 by , 5 years ago
| Cc: | added |
|---|
@Klumbumbus, what do you think about a ref continuity checker on a power line? Is it worth it?
comment:8 by , 5 years ago
How can I detect crossing power=line|minor_line and water features like a river in MapCSS?
comment:11 by , 5 years ago
v5 adds
- reference number continuity test
- line type checking (power=line/minor_line)
- improved missing support node checker
I also optimised for performance because the crossing finder is a CPU heavy task, probably responsible 90% per cent of the test running time.
What do you think? :)
comment:13 by , 5 years ago
Yeah, I tried, but it just didn't find anything don't know why :/ Side note: the 'cell' meaning which used in that class isn't clear for me.
I'm happy with that if you can modify it to use the CrossingWays test.
comment:15 by , 5 years ago
I used the implementation from MultipolygonTest for reference, but it still didn't work. Maybe that is tuned for MPs, while this also has to work with ways (tagged as some water body).
by , 5 years ago
| Attachment: | josm_20716_power_v5.patch added |
|---|
comment:17 by , 4 years ago
| Description: | modified (diff) |
|---|
by , 4 years ago
| Attachment: | josm_20716_power_v6.patch added |
|---|
added some comments, minor code improvements



And the best part it's already done :)