iD icon indicating copy to clipboard operation
iD copied to clipboard

Power lines connected to roads, landuses etc.

Open Dimitar5555 opened this issue 2 years ago • 3 comments

Description

Currently it is very easy to create an extra node on a power line and connect it to anything (like a landuse, road, waterway). In almost all cases, such connections are not desirable.

It would be very nice if such connections are not allowed by default. Alternatively, there can be a warning about it with an option to disconnect and delete the node, or to add some power related tag.

Screenshots

No response

Dimitar5555 avatar Feb 05 '23 08:02 Dimitar5555

Routinely i tag power lines as being at layer=1 tough I read somewhere it's considered unnecessary. If that were returned as obligatory same as where an underground line is at layer=-1, one could set a fail to connect to any line that has not set these -1 or 1 layer levels, were it not that end nodes connect to buildings by terminal e.g and those are usually without a layer tag i.e. considered layer=0.

Anyway, would you do this or modify/touch a line that has such a connection you'd see an alert entry showing up in your personal OSMI or Osmose report that a non-power node exists on a power line. Just tested, JOSM does flag a node with 'missing tag - node without power' during the pre-save validation cycle. And for fun, if you map a tree for instance too close to a road or power line there's moan too. Seen that a few times. 😎

sekerob avatar Feb 27 '23 18:02 sekerob

Hello

I second this issue and confirm it is kind of important thnig to warn contributors about.

We had make a clean up in France, at the beginning of 2023. It now raises again quickly and will have tot be redone the same 1 year later. https://osmose.openstreetmap.fr/fr/issues/graph.png?item=1250&class=1&country=france%2A

That would be really good iD help contributors to not make this mistake.

flacombe avatar Sep 07 '23 20:09 flacombe

Any chance of prioritizing this? This would be very useful, because there are many issues in the map that could be avoided with iD's help.

AntMadeira avatar Oct 11 '24 13:10 AntMadeira

Hello !

2 years after the beginning of this thread, those 2 charts speak for themselves: cleaning doesn't worth the effort as errors come back even faster.

Image https://osmose.openstreetmap.fr/fr/issues/false-positive?item=7040&class=4&country=france%2a

Image https://osmose.openstreetmap.fr/fr/issues/open?item=1250&class=1&country=france%2a

Many people spent days to reduce the amount of issues with no success to encourage anyone to make tidier topology. We didn't even got an answer from maintainers or product owner. I can't believe power=* is the only field of knowledge which watch erroneous connection with other features. How does it go for rivers, railways or so maintenance?

flacombe avatar Feb 02 '25 22:02 flacombe

Unfortunately, with the stalled development of iD (4 months without any update), this and many other important issues aren't probably going to be addressed anytime soon...

AntMadeira avatar Feb 03 '25 02:02 AntMadeira

Hello @AntMadeira

I wasn't aware of that, a bit far from iD development. However paid or not, iD development is at the core of OSM contribution, particularly newbies. It's not good news for anyone as it produces errors that should be fixed downwards. We have been struggling with it for years, it's clearly a missing part in the community.

Best regards

flacombe avatar Feb 03 '25 08:02 flacombe

Done one again yesterday and been disconnecting ways passing under bridges from them, ways at different layers are not expected to connect other than the end points of bridges. Think there's one problem,... we first draw lines, then add the feature tags, so it becomes difficult to determine if it should or should not connect. Would be nice at close up of the CS these things are flagged to resolve. I do, others have thousands and tens of thousands of ignores shown on their Neis HDYC page.

Image

Since Ive switched to JOSM for 99% of my mapping these values are pretty much static..

sekerob avatar Feb 03 '25 08:02 sekerob

Hello @sekerob

Drawing geometries and putting tags afterwards shouldn't be an issue since consistency check is done right before saving. Editors aren't supposed to warn mappers permanently but only when they click "save" at least. For the matter here, the same error should raise when you connect an existing power line to a river and when you add the power line tag to a blank line which was previously connected to the river. The drawing order doesn't matter here.

I could edit thousands of features in JOSM, implying hundred of errors in the making but only the final result matters. I solve errors one by one and then commit to the database.

flacombe avatar Feb 03 '25 09:02 flacombe

Editors aren't supposed to warn mappers permanently but only when they click "save" at least.

Both JOSM and iD can warn about issues while editing, not just when saving a changeset, unless I’m misunderstanding the suggested change?

1ec5 avatar Feb 03 '25 16:02 1ec5

Disallowing connections by default would only be feasible for existing ways that get extended or connected after being tagged. It wouldn’t be desirable to make the user choose a tag before allowing them to connect the way to anything. Otherwise, mapping roads or paths would become extremely tedious.

Short of this default behavior, a validation rule would make plenty of sense. We already have quite a robust rule about highways etc. crossing without a connection, so logically a similar rule could check for connections that shouldn’t exist. This would be similar to the suggestions in #4173 and #6631, but focusing on power lines would be a very good start, because there should be few if any edge cases to consider.

1ec5 avatar Feb 03 '25 16:02 1ec5

Hello

Both JOSM and iD can warn about issues while editing, not just when saving a changeset, unless I’m misunderstanding the suggested change?

JOSM always validates changes upon request and particularly on commit. iD warns on the fly but it warns users while they are editing and probably improving what they are doing, it's not the same behavior.

Disallowing connections by default would only be feasible for existing ways that get extended or connected after being tagged.

The point isn't to disallow anything but to warn about a possible mistake. Then the user should be warned when:

  • He connects a power line to anything else but power
  • He tags with power=* a line already connected to anything else but power (the feature is similar to real life: connecting a power line to a forest will not only kill you but hurting a lot the whole time you are dying)

It's possible that existing logic with waterways and highways will be suitable for power. I'm not so familiar with iD code. JOSM has got a config file: https://josm.openstreetmap.de/browser/josm/trunk/resources/data/validator/geometry.mapcss#L325

This issue, beside of #4173 and #6631 have been hurting us for years. It's important to improve iD validation capabilities, not only for power but any field of knowledge as to match affinities and compatibilities discussed in wiki (among other points, see #9200).

flacombe avatar Feb 03 '25 19:02 flacombe

Then the user should be warned when:

  • He connects a power line to anything else but power
  • He tags with power=* a line already connected to anything else but power

The validation rule I’m describing would catch both of these cases. A newly drawn line is the second case, not the first, which is why preventing the connection isn’t feasible – but we can still warn the user before and while they save.

1ec5 avatar Feb 03 '25 19:02 1ec5

We agree about that, good.

Question is to know how to get that planed in the iD roadmap and how long will it wait to get merged. There are 107 opened PR and only few of them are drafts. Even if I had time to propose a change in validation process, it won't be useful as no one will care to merge it.

iD is the most important editor for the community and we struggle to get adopted a yet functioning process for other features. The whole project will suffer from that someday.

flacombe avatar Feb 03 '25 20:02 flacombe