Modify

Opened 2 years ago

Closed 2 weeks ago

#16247 closed defect (fixed)

Validator issues on power related items

Reported by: Gazer75 Owned by: team
Priority: normal Milestone: 20.10
Component: Core validator Version: latest
Keywords: power Cc:

Description

There are a few false notifications of missing poles/towers:
In substations busbars connected with bays.
Drawing the portals as a line and connecting power lines to them.

Another false notification is lines connected to buildings built as a multipoly relation.
The building relation will have tags like power=switchgear.

Attachments (1)

16247.patch (5.3 KB) - added by GerdP 3 weeks ago.

Download all attachments as: .zip

Change History (17)

comment:1 Changed 2 years ago by Klumbumbus

Please add an sample .osm files with the false positive cases (ideally real examples from the osm database). Thanks.

comment:2 Changed 2 years ago by Gazer75

The multipoly problem is easy to reproduce. Go to https://osm.org/go/0TrMGeKvs?m= and download. Move any of the 47kV lines connecting to the GIS (gas-insulated switchgear) building. It will trigger a warning when trying to upload.

For connections between bays and busbars, and the portal as lines it is a bit more random.

I'll see about adding a saved situation that is repeatable.

comment:3 Changed 2 years ago by Don-vip

Keywords: power added

comment:4 Changed 2 years ago by Gazer75

The problem with notification on missing pole/tower seem to be as follows:
Altering a line that is connected to a portal way, busbar or bay that has NOT been altered in the current session.
The connection will then be flagged as missing a pole.

There has also been instances where a node tagged as a power=compensator with a line to the bay was flagged as missing a pole. Not sure how to reproduce this as I've yet to figure out when it happens.

comment:5 Changed 4 weeks ago by Klumbumbus

Ticket #19693 has been marked as a duplicate of this ticket.

comment:6 Changed 4 weeks ago by Klumbumbus

I found no solution to fix the multipolygon false positive because classes on the left side of child selectors seem not to work.

/* #12577 */
way[power=line] > node,
way[power=minor_line] > node,
way[power=cable] > node {
  set node_in_power_way;
}

relation[type=multipolygon][building] > way,
relation[type=multipolygon][power] > way {
  set way_in_building_or_power_mp;
}

way[!power][!building]!.way_in_building_or_power_mp {
  throwError: tr("non_power_infrastructure"); /* for debug, selector works fine */
}

way[!power][!building]!.way_in_building_or_power_mp > node.node_in_power_way { /* selector left (same as above) doesn't work */
  throwWarning: tr("NNNNode connects a power line or cable with an object which is not related to the power infrastructure.");
}

comment:7 Changed 4 weeks ago by GerdP

Yes, doesn't work, and probably never will. The java code iterates over all OSM objects and applies all the rules to a single object, it cannot store the status of each object after each rule.
I think it would be good to change the rule parser so that it refuses such a rule as invalid.

comment:8 in reply to:  7 Changed 4 weeks ago by skyper

Replying to GerdP:

Replying to Klumbumbus:

I found no solution to fix the multipolygon false positive because classes on the left side of child selectors seem not to work.

Yes, doesn't work, and probably never will. The java code iterates over all OSM objects and applies all the rules to a single object, it cannot store the status of each object after each rule.

So, the rule needs to be rewritten without classes on the left. Sometimes it is an option to turn it up-side-down. Looking at the node's parents and grandparents might be a solution.

I think it would be good to change the rule parser so that it refuses such a rule as invalid.

+1, yes, please, with a proper message including the line number. Thanks.

comment:9 Changed 4 weeks ago by Klumbumbus

I also tried other solutions with JOSM_search("...") or parent_tag(key_name) but found no solution either. Does anyone has an idea if it could be fixed in mapcss? I guess this would require something like a parent_has_tag_key() or parent_has_tags_key() function.

comment:10 Changed 4 weeks ago by GerdP

Reg. power: we already have java code in PowerLines which treats power objects in multipolygons.
Maybe the existing power mapcss tests should be replaced by java code?

comment:11 Changed 4 weeks ago by Klumbumbus

That would be fine too.

Changed 3 weeks ago by GerdP

Attachment: 16247.patch added

comment:12 Changed 3 weeks ago by GerdP

Please try, the patch does not yet replace the mapcss test, instead it produces the same message with (java) appended.
Makes it easier to find new or missing messages.

comment:13 Changed 3 weeks ago by Klumbumbus

I found no issue with some quick tests.

comment:14 in reply to:  6 Changed 3 weeks ago by Famlam

Replying to Klumbumbus:

I found no solution to fix the multipolygon false positive because classes on the left side of child selectors seem not to work.

FYI, I guess that's #10215 :)

comment:15 Changed 3 weeks ago by GerdP

Milestone: 20.10

comment:16 Changed 2 weeks ago by GerdP

Resolution: fixed
Status: newclosed

In 17111/josm:

fix #16247: Validator issues on power related items

  • replace mapcss tests by java code, use new code 2502 for warning Node connects a power line or cable with an object which is not related to the power infrastructure.

Modify Ticket

Change Properties
Set your email in Preferences
Action
as closed The owner will remain team.
as The resolution will be set.
The resolution will be deleted.

Add Comment


E-mail address and name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.