add validator about power lines crossing other lines #11200

nlehuby · 2025-07-10T14:14:03Z

This PR add a new check in the validators about power lines connected to non power feature.

Fix #8446 & #9488

I don't have much experience with javascript development, so please let me know what can be improved.

flacombe · 2025-07-10T22:22:45Z

I completely second this contribution. We highly need this. Thank you @nlehuby!

1ec5

Thanks for taking the time to implement this feature, and for your patience.

data/core.yaml

1ec5 · 2025-07-16T19:06:28Z

modules/validations/crossing_ways.js

        if (hasTag(tags, 'railway') && osmRailwayTrackTagValues[tags.railway]) return 'railway';
        if (hasTag(tags, 'waterway') && osmFlowingWaterwayTagValues[tags.waterway]) return 'waterway';

+        if (hasTag(tags, 'power') && tags.power === 'line') return 'power';


Like power=line, power=minor_line and power=cable shouldn’t be connected to roadways and land use areas either. However, if we add power=minor_line, we’ll need to add an exception for connections to buildings and possibly other features.

We should consider adding power=terminal on the connecting node with the building.
Other validators like Osmose will warn for an unfinished power line here

By te way that's really cool to map service supplies

Good idea, I didn’t know about that tag. Looks like openstreetmap/id-tagging-schema#653 is tracking adding a preset for power=terminal. Let’s wait until that happens before extending this validation rule to power=minor_line. Then we’ll be able to offer a second option to fix the warning by adding power=terminal to the connecting node. That would get us a little closer to being able to warn about islands in the power network as well.

I've also created the PR to add the power=terminal preset : openstreetmap/id-tagging-schema#1637

1ec5 · 2025-07-16T20:51:00Z

modules/validations/crossing_ways.js

+                        title: t.append('issues.fix.delete_connecting_node.title'),
+                        entityIds: [this.data.crossingNode],
+                        onClick: function(context) {
+                            var operation = operationDelete(context, [this.issue.data.crossingNode]);


This option should disconnect the power line, not delete the connecting node. The connecting node could be an intersection between two roadways or a node that defines the shape of a landuse area. Deleting the node could damage the other connected features’ geometry or topology.

Indeed, you are right.

I've switched to operationDisconnect (instead of operationDelete).

It's a bit annoying because I do think in most case, we want to keep the node in the other feature but we do want to delete the node on the power line... but I didn't manage to do that.

Yes, that is unfortunate. Maybe we could ticket out a followup improvement that warns about an extraneous vertex along a power line, especially if it causes a kink in the line. It could offer to straighten the line (by removing the node) or add a tower or pole in case it’s missing. This warning might need some extra care, because sometimes the line can branch without a pole, as I see frequently when mapping residential service drops.

For the last point about mid span branches, here are two facts:

It doesn't make a kink the line, the branch occurs in straight line between towers

Mappers must use power=connection + line_management=branch on the node, so there is always power on every nodes of lines.

It doesn't make a kink the line, the branch occurs in straight line between towers

What I mean is that power lines should be straight between towers, but some are very crooked, including most untouched TIGER-imported power lines but also potentially some lines where users have inadvertently added an errant node along the way. We could have a separate validation rule about such issues.

Mappers must use power=connection + line_management=branch on the node, so there is always power on every nodes of lines.

This isn’t guaranteed to be the case before the user clicks on the option to delete the node. We’d need to add another option for adding a power=connection line_management=branch node to prevent the user from damaging the existing features (quite possibly deleting one of the ways altogether). Moreover, id-tagging-schema has no preset for power=connection yet, so we can’t expect the user to know about that prerequisite.

flacombe · 2025-07-17T10:41:35Z

When seeking for non-power features a power line could be connected to, we should take care of life cycle prefixes.
A power=line connecting to disused:power=line shouldn't raise warning.

That requires to consider :power= and power=* as power features (disused:power=line shouldn't connect to roads or landuse as well)

- handle minor_line & cable - improve wording - allow building-power connexion, with power=terminal

1ec5

This looks good now, but we should wait until openstreetmap/id-tagging-schema#1637 lands so that the fix suggestions use supported tags.

data/core.yaml

1ec5 · 2025-07-23T21:24:50Z

modules/validations/crossing_ways.js

+                        title: t.append('issues.fix.delete_connecting_node.title'),
+                        entityIds: [this.data.crossingNode],
+                        onClick: function(context) {
+                            var operation = operationDelete(context, [this.issue.data.crossingNode]);


Yes, that is unfortunate. Maybe we could ticket out a followup improvement that warns about an extraneous vertex along a power line, especially if it causes a kink in the line. It could offer to straighten the line (by removing the node) or add a tower or pole in case it’s missing. This warning might need some extra care, because sometimes the line can branch without a pole, as I see frequently when mapping residential service drops.

1ec5 · 2025-07-23T21:30:41Z

modules/validations/crossing_ways.js

By the way, the warning’s title says the power line “crosses” the building, whereas “connects to” would be more accurate. It isn’t a big deal, but maybe the code already allows us to customize the language straightforwardly.

Co-authored-by: Minh Nguyễn <[email protected]>

tyrasd

Hi, sorry for the long wait in getting this reviewed. I noticed some things while trying out the branch and have a few general questions/remarks:

🐛 bug when terminal node is already is tagged

When the connection to a building already has tags (e.g. a simple note), the fix adds a second vertex at the same coordinates, see below:

Screencast.From.2025-09-02.16-32-19.mp4

In such cases this specific fix should either be not offered. Or, if it can be done safely, the fix should merge the new tags onto the existing node

compatibility with (proposed) preset

openstreetmap/id-tagging-schema#1637 seeks to add power=terminal as a preset, which (currently) has line_attachment=anchor as addTags. The fix in this PR does not add line_attachment, so the user would get a second validation warning about the incompleteness of the node's tags right after applying the fix. This could be addressed by adding the line_attachment tag here as well, or by removing line_attachment from the preset's addTags. (This is probably best to be discussed in the id-tagging-schema PR.)

interaction with `layer` tag on building

When a building is tagged with e.g. layer=1, the validation warning is not displayed. I assume this is not intentional, but rather a consequence of adding the logic in to crossing_ways which already handles layer tags for the detection of other data quality issues, and this resulted in an unwanted side effect?

In fact, it might be cleaner to extract this validation into a separate module instead of making the crossing_ways validation even more complex than it already is. Any reusable logic could be refactored out into a util library or simply be shared between the two modules directly.

`power=terminal` on non-end nodes

Is it reasonable to assume power=terminal can also be used on nodes that are not a start or end point of a way? The validation fix will happily offer to add the tag also to middle vertices. I have only ever seen it used on the extreme points of a way, never as a middle vertex, but maybe that's a false extrapolation of mine.

order of offered fixes

For example, when a power line connects to a building, but continues straight on, it was probably most likely the case that the mapper accidentally snapped the building to a power line (or vice versa). In this case, the first offered fix to add a power terminal is probably not the best to use by an inexperienced user to fix the issue.

Maybe the order of the offered fixes could be optimized to always show the most appropriate fix first. See #11329 for a general discussion around this topic.

other tags that can allow power line – building connection

From looking at the wiki, I had the impression that power=insulator could technically also be used to correctly tag a connection of a building with a power line. Especially in the case where the way itself does not end at that point, but it e.g. is rather a part of the power line's support structures, that might be even the only correct way to tag such situations.

Are there maybe even more tags that would allow connecting a power line to a non-power feature?

other features power lines should not connect to

The validation will only warns when power lines are connected to roads or buildings. But a similarly invalid case would be when e.g. a power line is connected to other structures (e.g. man_made=bridge, natural=water, landuse=meadow, etc.). Would it not make sense to extend this validator to also take those into account? Actually, as power features apparently should only interact with other map features at very specific features with well-documented tags, would it not make sense to warn on all occasions where the connection is between a power line and a non-power feature? Or would that lead in too many false positives?

"disconnect" fix results in two nodes at the exact same coordinate

When using the fix to disconnect the features, the result is two nodes with exact same coordinates. That is not ideal for multiple reasons (e.g. it is easy to accidentally snap the nodes together again, it will be flagged by many QA tools, data consumers that only look at the coordinates of the features might still end up with a false connection at that point, etc.). For the normal disconnect operation this is not a problem, as the mapper is already interacting with the particular intersection node and will likely follow up the disconnect operation by a move operation to reorganize the nodes appropriately. But that is not the case when the disconnect is the result of a validation fix.

Maybe an approach like ome ideas to approach this better:

If power line is almost straight at the to disconnect point: instead offer to remove the node on the power line (the node should remain only on the highway or building).
Otherwise this means that the power line has a kink at that location, which is strange, as power lines typically can only bend at a power pole or tower (or insulator/portal/terminal). In that case, the best fix might be to offer to create a new power pole or tower next to the intersecting feature. Maybe that's a little overkill, so instead the following could be an alternative:
Move the disconnected node of the power line a little bit to the side of the road or building.

extendability to non-power features

Some other OSM features can also benefit from a validation that checks for suspicious connections, e.g. path and address interpolation (#9589), highway and landuse (#6631), highway and administrative boundary, etc.

It would be awesome if the implementation in this PR could be flexible enough to support for easy extension to other feature combinations like the ones mentioned in the future.

nlehuby · 2025-09-04T15:23:41Z

Thanks for the extensive review.

I started reworking the code to create a dedicated module for validating incorrectly connected ways.

I fixed the following remarks along the way

interaction with layer tag on building
compatibility with the preset
order of the fixes
other valid tags for building-power connection
other features power lines can not connect to (I've only added landuse for now, still to be expanded)
better wording in the warning message ("is connected to" instead of "crosses")

Now comes the difficult part:

see if we can reuse the node instead of creating another one in the same position
see if we can avoid proposing a terminal if it's in the middle of the power line

Knowing that I haven't managed to have the fix to delete the node on the power line while keeping it on the other feature 😞

reuse the node instead of creating another one in the same position

only if last node of way

to remove the node from the power feature

nlehuby · 2025-09-08T14:06:53Z

I've updated the fixes:

only propose to add power=terminal if last node of the power feature way
add power=terminal to the connecting node instead of creating a new one at same position
the disconnect fix now disconnects the features + removes the node from the power feature.
I chose to always delete the node, without trying to calculate whether it significantly altered the geometry of the way, because I feel that most of the time it is a connection error and not an omission of a power tower or other power support. But there is always the possibility of doing a more detailed check, as proposed by tyrasd if it is a little too drastic.

Apart from this suggestion, I believe I have addressed all the comments made in the various reviews :)

nlehuby · 2025-10-28T09:07:57Z

Hello,

Would it be possible to have another code review on this proposal? I would very much like to see this in iD.

add validator about power lines crossing other lines

5851b70

k-yle linked an issue Jul 11, 2025 that may be closed by this pull request

Power lines connected to roads, landuses etc. #9488

Open

1ec5 reviewed Jul 16, 2025

View reviewed changes

improve power line crossing validator

9266d2b

- handle minor_line & cable - improve wording - allow building-power connexion, with power=terminal

nlehuby force-pushed the power_validator branch from f39d271 to 9266d2b Compare July 18, 2025 14:12

tyrasd added the validation An issue with the validation or Q/A code label Jul 21, 2025

1ec5 approved these changes Jul 23, 2025

View reviewed changes

Update data/core.yaml

b65ecb3

Co-authored-by: Minh Nguyễn <[email protected]>

tyrasd added this to the 2.37 milestone Sep 2, 2025

tyrasd reviewed Sep 2, 2025

View reviewed changes

add validation module dedicated to wrongly connected ways

157c865

nlehuby force-pushed the power_validator branch from 2891a91 to 157c865 Compare September 4, 2025 15:28

github-actions bot deployed to pr-preview-11200 September 4, 2025 15:33 View deployment

nlehuby added 4 commits September 8, 2025 10:54

improve power terminal fix

6e52e1f

reuse the node instead of creating another one in the same position

improve power terminal fix

5e03417

only if last node of way

improve disconnect fix

5a94443

to remove the node from the power feature

lint

c8a0141

nlehuby force-pushed the power_validator branch from 13d2906 to c8a0141 Compare September 8, 2025 14:03

github-actions bot deployed to pr-preview-11200 September 8, 2025 14:06 View deployment

1ec5 requested a review from tyrasd October 28, 2025 23:22

add validator about power lines crossing other lines #11200

Are you sure you want to change the base?

add validator about power lines crossing other lines #11200

Conversation

nlehuby commented Jul 10, 2025

Uh oh!

flacombe commented Jul 10, 2025

Uh oh!

1ec5 left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

flacombe Jul 16, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

flacombe commented Jul 17, 2025

Uh oh!

1ec5 left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

tyrasd left a comment

Choose a reason for hiding this comment

🐛 bug when terminal node is already is tagged

compatibility with (proposed) preset

interaction with layer tag on building

power=terminal on non-end nodes

order of offered fixes

other tags that can allow power line – building connection

other features power lines should not connect to

"disconnect" fix results in two nodes at the exact same coordinate

extendability to non-power features

Uh oh!

nlehuby commented Sep 4, 2025

Uh oh!

nlehuby commented Sep 8, 2025

Uh oh!

nlehuby commented Oct 28, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

flacombe Jul 16, 2025 •

edited

Loading

interaction with `layer` tag on building

`power=terminal` on non-end nodes

nlehuby commented Oct 28, 2025 •

edited

Loading