<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Fri, May 23, 2025 at 7:43 AM Frederik Ramm <<a href="mailto:frederik@remote.org">frederik@remote.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
Deleting an untagged way that has been sitting around for a longer time <br>
does not cause any damage (the way would not have shown up on any map, <br>
or be considered in any kind of evaluation). Deleting such a way is at <br>
most a missed opportunity to improve OSM (by finding the right tags for <br>
it) - it is not something that makes OSM worse than it was before!<br></blockquote><div><br></div><div>This was also my reaction.  An untagged way that isn't part of any relation isn't geodata and wasn't being used by any data consumer. The only time I would try to keep such objects is if it's clearly a trace of something complicated, for example someone traced the perimeter of a complex lake but forgot to add the water tags to it -- or, if it appears to be part of a botched edit.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
If, on the other hand, the data has been created by someone who seems to <br>
still be active in OSM then I will probably add a changeset comment <br>
asking them to look at it.<br></blockquote><div> </div>I do a lot of editing of boundaries, which is fairly complicated and detailed work when dealing with all the adjacent and overlapping boundaries at different administrative levels. It is really easy to make a mistake and leave behind sections of boundary member ways which invariably end up as untagged ways. This is always a mistake when it happens, and I always appreciate it when another mapper notices this and contacts me to point it out. So I also want to give a +1 to the idea that we should (a) not be afraid to delete things that provide no value but also (b) at least take a moment to look at the history of that object before deleting.<br></div></div>