OpenStreetMap

What is the utility of this edit?

It appears this only creates the opportunity to introduce erroneous deviation to lines that are straight by definition and contradicts:
https://wiki.openstreetmap.org/wiki/Good_practice#Keep_straight_ways_straight

IMHO, that makes complete sense for straight, smaller ways. But for massive ways it becomes a problem when the nodes that define the way are far outside of the bbox that you are querying for. You aren't aware that a way is traversing your work and that might cause an issue. It's one of the reasons OSM Inspector calls it out as a problem.

That may be somewhat true for a road, but what valid interaction local detail could have with the Bermuda Triangle is beyond me (save at the end points).

I think the utility of this view on OSM Inspector is that many long ways are caused by things like a node being drastically misplaced accidentally (e.g. moved to 0,0) and are not realistic.

In other cases the way needs further legitimate refinement from imagery or survey (as you have done in some of your other recent edits). Artificial division of those ways masks a problem that still exists from people who may be able to resolve it. If no more detailed information is available, then I think the sparse data we have should remain as is rather than being further ingrained by interpolation.

In some cases though these long segments are real and I think should remain as is. In this particular case I think there is far greater danger from the way getting falsely entangled with objects in the Atlantic than there is from accidental duplication etc.

Another reason for breaking these up is that any accidental moves of a way (to 0,0 for instance) would be masked by all of the other long segments that exist. If we segment the long ways, any mistakes that are made will be more likely to stick out rather than be obscured by many other valid long ways. So my argument is that you need to "clean" them all up in order for mistakes to stand out.

Also, thanks very much for the discussion. I appreciate the feedback.

From the OSM Inspector wiki page: "So while it might not be a "proper" solution its certainly pragmatic to make the segments shorter. Another problem is due to the current implementation of the OSM API: When requesting all objects inside a bounding box only nodes in this bounding box and ways having a node in this bounding box will be returned. (This is done because it is more efficient.) So the longer the segments are and the smaller the bounding box the bigger the chances that some object will not be returned from the API call and might not appear on the map."

Some more discussion on the topic is taking place on the US Slack instance: https://osmus.slack.com/archives/C029HV951/p1540853913092600

Hi,

I am one of the developers of OSMI.

Not everything which is shown by OSMI is an error. Some things are correct but difficult or impossible to distinguish from real errors.

You should not insert nodes into long segments to make something disappear from OSMI or any other quality assurance tool. That would be mapping for the QA tool and is not better than tagging for a specific renderer/map style.

Best regards

Michael

Note: I don't use Slack because I don't agree their terms of use and avoid proprietary software in my spare time.

@Nakaner, maybe you can add a feature to only show actual errors (self intersecting ways, duplicate nodes, etc). Also, it would be helpful if OSMI could put some language in the pop-up for long segments saying that people shouldn't fix them.
As for the Bermuda Triangle, I reverted my change a day or two ago as the consensus seems to be to not fix this class of (non-)problem.