Das löschen dieser Information erzeugt aber nur neuen Datenmüll. Denn dadurch wird eine neue Version des Objektes erzeugt, welche keine neuen Aussagen enthält.
Im Ernst, man sollte diese - an Knoten im Prinzip unnötige - Information nur dann löschen, wenn man auch anderweitig etwas an den Knoten ändert. Beide Änderungen zusammen erzeugen dann nur eine neue Version.
PS:
Die Editoren sollten seit längerem das Verhalten an jedem neuen Objekt ihr created_by dranzuhängen, zugunsten der Angabe im Changeset aufgegeben haben. Wenn man genau hin sieht, waren das in der Regel ältere Versionen der Editoren.
Mehr noch: Die Editoren - zumindest JOSM und Potlatch (2) laut Key:created_by - löschen mittlerweile sogar stillschweigend created_by-Tags von Objekten, die bearbeitet werden. Damit sollte dieses Tag hoffentlich mit der Zeit einfach im Rahmen der alltäglichen Bearbeitungen ausgerottet werden.
AFAIK findet man mit JOSM die leeren nodes per Klick (Stochern im Heuhaufen) oder über die Prüfroutine, mittels derer man diese auch Reparieren/Löschen kann.
Merkaartor dagegen zeigt diese mit einem eingerahmten Fragezeichen. Diese Option habe ich auf alle von mir genutzten Stile, abgeleitet aus den internen, übertragen.
Das kommt immer darauf an.
Was löschen denn Potlatch und JOSM an created_by Taggs?
Nur die eigenen
Die drei großen Editoren (Potlatch 1/2, JOSM, Mercaartor)
Alle bekannten Editoren
Alle created_by Taggs
Bei einigen Objekten finde ich es durchaus interessant/wichtig zu sehen, dass sie durch Importe oder Skripte angelegt worden sind.
Beispiele: OpenGeoDB, almien coastline, naptan2osm, …
Laut Taginfo sind es 27,7 Mio Punkte mit 543 Werten, 3,8 Mio Wege mit 1158 Werten
Da ist also noch einiges zu tun.
Bei der Umstellung auf ODBL müssen ja viele Objekte geändert werden.
Für diese kann auch das created_by Tagg gleich mit entfernt werden.
Bei den verweisten Nodes gibt es auch noch eine andere Möglichkeit: Jemand macht gerade einen grösseren Import. Dabei kann es vorkommen, dass zuerst tonnenweise Nodes eingefügt werden und erst in späteren Changesets die dazugehörigen Ways. Ein Indiz dafür den hier diskutierten Fall ist, dass beim ersten Check die Nodes ohne Ways waren, beim späteren Kontrollieren aber mit!
Ich erinnere mich mal an ein Posting, wo einer über sein Leid bei grösseneren Imports geklagt hat. Da gab es ständig Fehler beim Einfügen der Ways wegen fehlender Nodes. Seit her habe ich mir angewöhnt solche Nodes nur zu löschen, wenn sie mindestens ein paar Monate alt sind (grobe Abschätzung über die ID.)
Erschwert bitte nicht solche Importe durch übereifriges Löschen!
Einmal das und Importe sollten in mehreren Schritten (Changesets) durchgeführt werden, die jeder für sich wieder einen konsistenten Zustand ergeben. Dazu unterteilt man z.B. den Import in regionale Bereiche. Dann ist es auch einfacher alles zurück zu drehen, wenn doch etwas schief gehen sollte. Siehe die Bearbeitungen vom VRS Haltestellen-Import