BEV-Adressen (incl. Subadressen) als .osm-Files (neue Daten 10/19)

Die Ebenen können jetzt nicht nur nicht direkt hochgeladen werden, sondern sie sind auch noch gelocked. Zum einen bedeutet das, dass man sie nicht bearbeiten kann, die spannendere Auswirkung ist allerdings, dass man dadurch auch nichts in diese Ebene hinein laden kann. Wenn daher eine gelockte Ebene aktiv ist und man lädt diesen Bereich herunter, landen diese Daten stattdessen in der Arbeitsebene, solange man nur eine offen hat, und ansonsten eben automatisch in einer neuen Datenebene.

addr:city wird jetzt durchgehend die Gemeinde zugewiesen. Wenn eine Straße in einer Gemeinde mehrfach vorkommt, wird bei den Adressen dieser Straßen zusätzlich ein addr:suburb mit dem Ort gesetzt. Ich finde das zwar auch noch nicht ganz optimal, aber überall möchte ich auch kein suburb setzen und es entspricht grob der Möglichkeit 2 aus dem Leitfaden der Post und ist konsistent

Und dann hat der Output jetzt eine neue Struktur und ist u.a. nach Gemeinden gruppiert, die Ordner- bzw. Dateistruktur sieht nun nämlich so aus:
PLZ-Bereich / Gemeinde / Ort / Strasse_PLZ_Ort_(Gemeinde).osm
Wenn man sauber vorgeht, ist das völlig ironiefrei sogar ein großer Fortschritt. Sehr hilfreich ist auch der Shortcut “2” um auf den Bereich der Ebene zu zoomen.

Pro Halbjahr sind etwa 10.000 Adressen mit neuen IDs dabei, also umgerechnet um die 400 pro Woche, wobei gerade bei neuen Einträgen die Qualität oft noch sehr mangelhaft ist und diese einfach mal irgendwie grob in die Gegend geworfen werden bzw. dort oft auch noch mehr zu tun ist, wie neue Straßen anzulegen - das ungeschaut zu übernehmen ist kontraproduktiv. Und ja, ich erwarte von dir, dass du bevor du etwas hochlädst, dir das zumindest einmal anschaust, denn danach wirst du das nicht mehr machen und “irgendwer” darf sich dann darum kümmern, dass das korrigiert und aktualisiert wird. Es sind weder der Konverter, noch die Duplikatsprüfung (die nicht einmal auf das Mergen von Imports ausgelegt ist), noch die Basisdaten perfekt - wenn dem so wäre, bräuchte es auch keinen manuellen Schritt und von blind kopierten Adressen ohne Straße irgendwo im Nichts, wie von Negreheb gezeigt, hat auch niemand etwas. Es hält höchstens noch jemand anderen davon ab, die Gegend mit Straße etc. zu erfassen, denn laut regio-osm ist dort ja alles perfekt (und bevor du das jetzt wieder als Diskreditierung von regio-osm deutest: das ist natürlich nicht die Schuld von regio-osm, ich halte das für ein tolles Tool, aber es ist eben auch nur ein Werkzeug und wie bei so vielen QA-Tools sollte es nicht darin ausarten, nur noch blind dieses zufrieden stellen zu wollen). Wenn dein Filter soviel weg filtert, dass du nicht einmal siehst, ob dort überhaupt eine Straße ist, oder ob diese mit den Adressen zusammen passt, dann ist das nicht sinnvoll.

Na zum Glück war der plan.at-Import “vollständig”, damit wir auch heute noch was davon haben :roll_eyes:

Nein, ich schlage vor, so wie bisher bspw. auch mit dem AddressHelper selektiv vorzugehen. Der “Quelltext” sind mehrere Tabellen mit Dutzenden Feldern, aber nur zur völligen Transparenz: im Gegensatz zum AddressHelper unterschlage ich auch den HAUSNRBEREICH und generiere nicht so Hausnummern wie “1-3, alle Zahlen des Intervalls”. Was jetzt gar so furchtbar daran ist, dass einige mit “str.” abgekürzte Straßennamen daran angeglichen werden, wie die Straßen sowieso schon in OSM heißen, hast du uns auch noch nicht richtig begründen können, außer dass dann vielleicht einzelne Gemeinden auf regio-osm evtl. orange statt gelb angezeigt werden könnten. Ich lasse mich ja überzeugen, dass das keine gute Idee ist, aber bis jetzt warst du als einziger dieser Meinung, ohne das gut begründen zu können.

Ich nehme an, mit dem Filter meinst du das hier, aber zum einen ist das ein unabhängiger Schritt vom Konvertieren (und wäre auf diese Art für so große Mengen und nicht on demand gar nicht machbar. Es ist auch jetzt mit der Abfrage je Datei nach der Umstellung auf Straßennamen etwas suboptimal) und weder importiere ich einfach alles, was über bleibt, noch ignoriere ich alles andere, wenn mir Unstimmigkeiten auffallen. Es ist halt nur ein weiteres Hilfsmittel, wenn auch ein sehr sinnvolles, wenn man soviel mit diesen Daten macht wie du.

Um das ganze unter Windows zu verwenden: Python 3.x installieren und dabei die Checkbox “Add Python 3.7 to PATH” wählen.
Dann eine Commandline öffnen (Startmenü “cmd”) und

pip install overpy

eingeben.
Das zip-File mit der osm-toolbox herunterladen und entpacken.
Diesen Ordner kann man jetzt noch zu den Umgebungsvariablen hinzufügen: Startmenü “Umgebungsvariablen” => “Umgebungsvariablen” => Path Bearbeiten und dort den Pfad zur osm-toolbox angeben.
Wenn du jetzt eine neue Commandline aufmachst (evtl. musst du dich vorher nochmal ab- und neu anmelden) solltest du unabhängig vom aktuellen Verzeichnis “filter_address_files.py” eingeben können, ohne Fehlermeldung.

Jetzt den Ordner einer Ortschaft öffnen, im Windows-Explorer auf Datei->Windows Powershell öffnen und

filter_address_files.py .

eingeben.
edit 2019-04-15: statt mehreren einzelnen Files akzeptiert das Script nur mehr ein einzelnes Verzeichnis, daher habe ich "" auf “.” geändert*

Beim ersten Mal musst du es anscheinend tatsächlich ausschreiben und kannst keine autocompletion verwenden, aber beim nächsten Mal brauchst du nur CTRL+R filter eingeben.

Damit wird neben den vollständigen Dateien auch noch eine entsprechende mit postfix _filtered.osm angelegt, wo die vorhandenen Einträge entfernt sind. Du kannst dann also im Explorer nach _filtered suchen und die Dateien per drag&drop in JOSM öffnen.
Was aktuell zB nicht heraus gefiltert wird: Adressen mit einem anderem addr:city, oder Subadressen, die mit “/” angegeben sind.

Hallo Luzandro,
Du kennst den von mir verwendeten JSOM Filter
vielleicht solltest Du parallel zu Deinen jeweiligen Aufbereitungen, auch den dazu passenden JOSM Filter definieren.
Wenn es Sinn ergibt, warum nicht auch die Straße mitnehmen.
Was mir aktuell dazu aber fehlt ist eine dazu notwendige allgemeine Beteiligung.

Es ist leicht zu sagen, du hast die Kartoffel ins Feuer geworfen, nun bist du für diese verantwortlich.
Nein so ist das nicht, niemand verlangt schließlich von anderen OSM Usern -deren Steckenpferd zum Bespiel darin besteht Landnutzungspolygone zu zeichnen-, dass diese zugleich auch noch etwas anderes machen müssten. Warum verlangst Du von mir aber wenn ich Adressen Mappe, dass ich zugleich auch Straßen benennen soll. Ein weiterer -sich selbst zur Community hochstilisierter- User -Id Anwender-, phantasiert sogar, dass ich hierbei auch noch mögliche doppelte Gebäudepolygone bereinigen soll, das ergibt keinen Sinn.

Es ist ganz klar ersichtlich, Adressen sind von Dir, und per addresshelper als Zuckerl gedacht, Lockmittel um andere Interaktionen wie das Zeichnen von Gebäudepolygonen, und neuerdings das Benennen von Straßen zu erzwingen.

Es gibt keinen legitimen Anspruch auf Erfüllung einer derart gesteuerte Interaktion. Wenn OSM Mapper dann aus deinen sorgsam gelegten Schienen ausbrechen, machst Du den Beleidigten, und baust allerlei Erschwernisse ein.

Was mich freut, ist dass es bei Deinen Adressen eine stete Optimierung gibt. Ich gehe diese Schritte gerne mit, wenn diese Änderungen Verbesserungen bringen. Sofern diese hingegen das Ergänzen von Adressen verunmöglichen, dann verweise ich auf ältere Versionen, zu finden als Link in meiner Signatur. Was erlaubt ist und was nicht, bestimmst keinesfalls Du, du bist schließlich ein OSM User wie jeder andere auch. Auch Deine älteren Aufbereitungen sind daher legitim.

Deinen Aktuellen Schritt, die Ausschreibung von Namen eigenmächtig zu ändern gehe ich nicht mit. Aber Du könntest ja die amtliche Schreibweise ebenfalls im Changeset belassen. Sofern OSM Nominatim hierbei in Namensauflösung mitzieht bin ich für solche Vorschläge aufgeschlossen.

Ein größeres Problem ergibt sich aus Deiner aktuellen Initiative in Langausschreibung mit bereits in Österreich gemappten Adressen. Mein Vorschlag dazu, solche Langnamen im bislang vielfach ungenutzte Datenfeld name:de unterzubringen. Beispiel Semperitstraße in Ternitz. https://wiki.openstreetmap.org/w/index.php?title=Key:addr&uselang=de#Multilingual_Addresses wurde aber leider bereits wieder vom Moderator emga unterbunden. Dass hier in Luzandros Thread dieses Thema nun untergeht, entlarvt emgas Eingriff in Form der Themensperrung meines dafür gestarteten Artikel https://forum.openstreetmap.org/viewtopic.php?id=63954 als manipulativen Eingriff in die Diskussion.

Edit: Text ergänzt, es hat noch niemand geantwortet.

Zurück zum Thema:

Gibt es in dieser Annahme, regionale Unterschiede oder trifft diese Aussage auf gesamt Österreich zu ?

wie gesagt ist das mittlerweile auch nicht mehr ganz aktuell, nicht zuletzt weil auch du dich beschwert hast, dass du immer noch nicht verstehst, warum nicht immer die Gemeinde als addr:city geliefert wird und es tatsächlich nicht immer ganz konsistent war:

Aber gibt es da regionale Unterschiede? Ob in einer Gemeinde Straßennamen mehrfach vorkommen, ist tatsächlich regional sehr unterschiedlich. In den PLZ-Bereichen 4-6 (“Westen”) kommt das fast gar nicht vor, 7-9 (“Süden”) etwas mehr und am häufigsten im Osten.

Das wiki sagt zu addr:city

Wie im oben verlinkten “Richtig Addressieren” der Post, ist der “Bestimmungsort” bspw. in der Gemeinde Götzendorf an der Leitha aber nicht die Gemeinde, sondern die Ortschaft, da bspw. die Hauptstraße 65 sowohl in der Ortschaft Götzendorf an der Leitha, als auch ein paar Hundert Meter weiter in der Ortschaft Pischelsdorf vorkommt und die Adressen nach der ersten Variante der Post dann folgendermaßen lauten müssen:

Hauptstraße 65
2434 Pischelsdorf

und

Hauptstraße 65
2434 Götzendorf an der Leitha

addr:city=Pischelsdorf ist dafür also völlig korrekt, v.a. aber ist es zwingend erforderlich, dass Pischelsdorf in der Adresse überhaupt aufscheint. Warum habe ich es für die Ausgabe des Konverters dann trotzdem nochmal geändert? Man könnte nur bei den Straßen oder Adressen, die ansonsten nicht eindeutig sind, ein anderes addr:city setzen, aber das ist völlig inkonsistent und für User und Mapper ohne zusätzlichen Hinweis schwer nachvollziehbar, warum das so ist und dass das v.a. Absicht ist und es einen Grund dafür gibt. Wenn man es für den gesamten Ort / die gesamte Gemeinde ändert, ist es zwar lokal konsistenter, das Problem mit der Nachvollziehbarkeit ist aber immer noch ein wenig gegeben und wenn jemand daher kommt und meint, diese Angabe wäre falsch, weil doch immer die Gemeinde in addr:city stehen muss, und das entsprechend ändert, gibt es plötzlich wieder Adressen, die nicht mehr eindeutig sind. Daher ist die Variante 2 der Post mit addr:suburb vermutlich etwas sicherer und konsistenter, wobei ich es aktuell nur bei den Straßen setze, die ansonsten nicht eindeutig sind. Warum nur bei den Straßen? “Ortschaft” kann wie gesagt alles mögliche und auch sehr klein sein, für alle Ortschaften ist es also mMn. nicht sinnvoll, auch nicht wenn man die abzieht, die unter die addr:place Regel fallen. Man könnte es auch nur in den Orten setzen, wo mehrdeutige Straßennamen vorkommen. Das kann aber auch etwas irritierende Ergebnisse liefern, wo bei “gleichwertigen” Katastralgemeinden einmal überall suburb vorkommt und bei der anderen dagegen nur die Gemeinde aufscheint. Umgekehrt für die gesamte Gemeinde würden dann auch kleine Ortschaften dieser Gemeinde (und wieder nur dieser Gemeinde) ein Suburb bekommen, daher scheint es zumindest für diese automatisch generierten Dateien jetzt einmal nur dort auf, wo es am ehesten auch tatsächlich notwendig ist, auch wenn es an mehr Stellen passend sein könnte.

Zum Key selbst: ich weiß nicht, wie verbreitet der für Ortschaften/Katastralgemeinden ist, aber auch nach den Reaktionen einiger anderer User auf diversen Kanälen zu schließen, ist es nicht falsch, aber bisher auch nicht unbedingt üblich - so zumindest mein Eindruck. Beim Durchforsten des Forums (und auch bei den Overpass-Abfragen in Grenznähe) hatte ich den Eindruck, dass das in Deutschland eher verbreitet ist und so wie man “city” nicht zu wörtlich nehmen darf, ist das bei “suburb” wohl genauso.
Man findet bei den Werten für addr:city auch die Angaben “Gemeindename”, “Gemeinde Gemeindename”, “Ortsname”, oder “Gemeindename-Ortsname” bunt gemischt, was bei einem Community-Projekt wie OSM auch nicht weiter überraschend ist, aber mittlerweile bin ich auch der Ansicht, dass der Ortsname (wenn es nicht nur ein Place ist) unter suburb wohl am besten aufgehoben ist, wenn man ihn angeben will oder muss.

Das Filter-Script ist mittlerweile übrigens wieder freundlicher zum Overpass-Server und damit auch wieder deutlich schneller, also falls das jemand verwendet, sollte man es aktualisieren

@ Luzandro:

Es gibt natürlich noch eine weitere Möglichkeit, nämlich: Ortschaft-Beistrich-Straße. Konkret beim Bsp. Pischelsdorf: Götzensdorf an der Leitha, Hauptstraße 65 2434 Pischelsdorf.
im Addr:city Feld steht IMMER die pol. Gemeinde, niemals die Katastralgemeinde, die speziell durch die Gemeindezusammenlegungen in der Stmk. vor einigen Jahren vermehrt entstanden sind.
Und das ganze kommt dann in das addr:street Feld, die Straße davor muss natürlich gleich heißen.

Unsere Post stellt beide Varianten zu.

Wenn ich die Wahl habe, wähle ich daher die nicht so elegante aber dafür konsistente Variante.

Eine Alternative wäre in OSM, Regionalverantwortliche zu ernennen. Regionalverantwortliche mit Ortskenntnis welche den jeweiligen regionalen Status per regelmäßiger Sichtung und Kontrolle aufrechterhalten.
Aufgrund mangelnder Ressourcen ist das aktuell aber nicht zu machen. Daher meine Meinung, eine einheitliche Umsetzung über ganz Österreich mit dem Gemeindenamen im Feld addr:city ist derzeit die besser Variante.

Wie gesagt machen das manche Gemeinden so (entsprechend taucht dort dieses Problem dann auch nicht auf), der Ortsname ist dann allerdings auch tatsächlich Teil des Straßennamens. In den Fällen, wo das nicht so ist, ist das nach Ansicht der Post keine korrekte Form der Adressierung und es ist auch für OSM nicht sinnvoll das dort dennoch einzuführen, eine Straße mit diesem Namen gibt es dort schlicht nicht.

Ich habe das vor zwei Jahren in der Gemeinde Wildschönau -nach viel Probieren- ebenfalls so umgesetzt, und das Thema daher für mich damals abgeschlossen.
Manchmal fällt es schwer eine eigene Erfahrung in einem kooperativen Projekt zu transportieren. Aber siehe da, andere kommen auf die selbe Lösung.

Leider ist das Handstricken solcher Adressen (addr:street=Straße,Ort) sehr zeitaufwendig. Wildschönau du hast mich Wochen beschäftigt.

Ich zweifle nicht mal näherungsweise, dass die Post mit der Kombination Ortschaft-Beistrich-Straße + PLZ & Ort, ein Problem haben wird. Denn, präziser kann man kaum einen Brief/ein Paket adressieren, als zu einer Ortschaft/Gemeinde, in der es in der Tat 2 oder mehr gleichnamige Straßen gibt, noch zusätzlich die Katastralgemeinde in den Straßennamen zu schreiben. :wink:
Ich habe eh schon hier im Forum vor 1-2 Jahren auf diese Thematik hingewiesen. Es wird jedoch - grade durch die Gemeindezusammenlegung in der Stmk auch bedingt - hier die einzige praktikable Lösung bleiben. Denn, wie auch in den BEV-Daten vorhanden, steht im addr:city Feld immer der Name der Gemeinde drinnen. Beim zuvor genannten Bsp. ist es "Götzendorf an der Leitha"lt. Wikipedia.

Ich gehe auch nicht davon aus, dass es nicht ankommen wird, aber der vorgesehene Platz dafür ist für die Post entweder statt der Gemeinde nach der PLZ - was wie oben ausgeführt für OSM unpraktisch ist und Nachteile hat - oder in der vorletzten Zeile, was der Angabe von addr:suburb entspricht:

Hauptstraße 65
Pischelsdorf
2434 Götzendorf an der Leitha

Wenn die Gemeinden solche Sonderfälle nicht von sich aus umgehen und Straßennamen verhunzen, indem sie den Ortsnamen mit oder ohne irgendwelchen Zeichen davor schreiben

Welten, Hauptstraße 25
8383 Sankt Martin an der Raab

Rax-Raxer Hauptstraße 4
8380 Jennersdorf

Walbersdorf Berggasse 3
7210 Mattersburg

Überfeld/Dorfstraße 25
9311 Frauenstein

oder danach schreiben

Feldgasse, Rattersdorf 7
7443 Mannersdorf an der Rabnitz

Gartengasse (Seyring) 12
2201 Gerasdorf bei Wien

gibts keinen Grund, warum wir das unnötigerweise verfälschen und verschandeln sollten

Luzandros aktuelle BEV Adressaufbereitung liegt nun in einem derart massiv fragmentierten Format auf, als dass seine Aufbereitung nur noch maschinell weiterverarbeitet werden könnte.
Somit kann man sein Projekt -für laienhafte Mapping Aktivitäten- nun als unbrauchbar erachten.

Schade,
was als ambitioniertes Projekt begonnen hat, endet also nun. Auch die dem JOSM Plugin zugrunde liegenden BEV Daten sind längst nicht mehr aktuell, werden also offensichtlich nicht mehr aktualisiert.

Aktuell verweise ich auf die in meiner Signatur erreichbaren älteren Aufbereitungen. Ich finde es macht Sinn Österreich mit diesen Daten in Adressabdeckung zu vervollständigen. Ein anschließend hoffentlich eintretender Wiki Effekt, sollte das importieren weiterer BEV Daten künftig überflüssig machen.

Stichtagsdaten vom 1.10.2018 sind online

Vollständig: https://my.sofortcloud.com/index.php/s/1mVREyBx0dCZZ4q

Verschiedene reduzierte Datensätze, wie ohne identischen Einträgen vom letzten Stichtag, nur Adressen mit neuen IDs, oder nur neue Straßen: https://my.sofortcloud.com/index.php/s/vR5Yq9ojJGfvLW5

Liste mit geänderten Straßennamen: https://my.sofortcloud.com/index.php/s/EDLQNOCw7Fe9ef3

Bei den neuen Adressen/Straßen muss das nicht in jedem einzelnen Fall zwingend stimmen. Ich schaue da nur, ob die ID im letzten Datensatz noch nicht vorgekommen ist und tlw. tauchen da aus irgendeinem Grund auch alte Einträge mit neuer ID auf.

Scripts zur Auswertung gibts tlw. hier: https://github.com/Luzandro/osm-toolbox

Interessant wäre nun Deine Einschätzung, wie viele Frau oder Mannstunden Du zum abarbeiten Deiner nun je Straßenzug aufgegliederten BEV Adressdaten ansetzt.
Bitte das in Relation dazu setzten wie viele Mapper sich aktuell tatsächlich mit der Adresserfassung in Österreich beschäftigen, und wie viele Stunden Mappingzeit uns daher aktuell für solche Arbeiten tatsächlich zur Verfügung stehen.

Die Anzahl der Adressen hat sich um nichts geändert. Und hast du dich das bei deinem Glühwürmchen Mapping noch nicht gefragt?

Meine Antwort findet sich in meiner Signatur.
Deine noch anwendbare Aufbereitungen
at_bev:addr_date=2018-04-02

Es sind in der von mir archivierten Fassung zwar geringe Anpassungen notwendig. Zum Beispiel, Ortsteile welche in dieser als Gemeinde eingetragen sind, von addr:city nach addr:suburb umwandeln, und anschließend ein neues addr:city der Hauptgemeinde setzen.
Ansonsten passen die meisten Daten. Manchmal muss man aber wenn einzelne Ortsteile wie in der Gemeinde Zams fehlen, auf einen noch älteren Satz (nach PLZ) zurückgreifen.

Der mächtige Zauberer Luzandero des Königs Buff, soll also nun das lästige Glühwürmchen im Honigtopf ertränken,
Glühwürmchen Flieg!

Das Glühwürmchen arbeitet an einer neuen Methode der Adressvervollständigung von Gemeinden, bei der es nicht mehr notwendig ist, bereits bestehende Adresselemente vom Gebäudepolygon in einen Node zu verlagern. Bereits gemappte Informationen bleiben hierbei erhalten. Differenzen werden mit dieser Methode gut sichtbar gemacht, deren Auflösung erfolgt nach guter Mapper Manier jeweils von Hand. Der Arbeitsaufwand bleibt -da Übereinstimmungen im Gegensatz zu Luzandros Methode ausgefiltert werden- überschaubar.

Folgende Vorgangsweise:
Editor JOSM, Adresselemente eines Gemeindegebietes unter Anwendung folgender Overpass- Turbo Abfrage vollständig in den Editor laden.

[out:xml][timeout:25][bbox:{{bbox}}];
{{geocodeArea:Beispielgemeinde,Austria}}->.searchArea;
(
 node
  ["addr:housenumber"](area.searchArea)({{bbox}});
  way
  ["addr:housenumber"](area.searchArea)({{bbox}});
  relation
  ["addr:housenumber"](area.searchArea)({{bbox}});
);
(._;>;);
out meta;

Nun BEV Daten einer Gemeinde https://drive.google.com/open?id=1G8F4TWd6OXFFym-N9u4oTQ91WKKUAKtp vollständig in einem eigenen Layer sammeln, eventuelle Luzandro Orte in Suburb umwandeln, addr:city Gemeinde wieder vervollständigen.
Die nun vollständigen BEV Adressdaten -die sich nun in Datenebene 2 befinden- kopieren, und in die Datenebene 1 per strg+alt+v einkopieren.
Daten hochladen, hierbei sämtliche Fehlermeldungen ignorieren.

Änderungssatz ID eruieren, und vorläufig notieren. Einige Minuten warten.

Editor JOSM,
Folgende Overpass Turbo Abfrage anwenden,
dazu ein JOSM Auswahlfenster über das geamte Gemeindegebiet aufziehen, und Prüfung durchführen.


[bbox:{{bbox}}];
nwr["addr:city"]["addr:housenumber"];
for(t["addr:city"] + " " + t["addr:street"] + " " + t["addr:unit"] + " " + t["addr:flats"] + " " + t["addr:place"]+ " " + t["shop"] + " " + t["addr:housenumber"] + " " + t["name"]+ " " + t["amenity"]+ " " + t["shop"]+ " " + t["note"])
{
  if (count(nodes) + count(ways) + count(relations) > 1)
  {
   (._;>;); out meta;
  }
};

nun: strg+F Suchen nach changeset:1234567letzte ID

Nun sämtliche Elemente der Auswahl entfernen, anschließend “leere” Nodes zum Vermeiden von Konflikten aber vorläufig bestehen lassen.
Änderungssatz daher samt “leere” Nodes hochladen. Fehlermeldungen beim hochladen ignorieren.

Mehrere Minuten warten,
Nun JOSM erneut starten und folgende Abfrage nach leere Nodes laufen lassen:

[out:xml][timeout:25][bbox:{{bbox}}];
rel; > -> .r;
way; > -> .w;
(( node(if:count_tags()==0); - node.r; );  - node.w; );
out meta;

Die so gefundenen leeren Nodes, kann man nun allesamt ohne Konfliktgefahr löschen,
Änderungssatz hochladen.

Erneut mehrere Minuten warten,
JOSM neu starten und mit der Bereinigung der verbliebenen Duplikate beginnen:
Duplikate per Geometrie ersetzten auflösen.
Ich verwende hierbei eine Funktion meines in meinem Blog beschriebenen Gampepad Logitech G13, das geht aber ebenso gut per JOSM Tastenkombination.


edit: linkfix + Text

Dank:

Warum lädst du absichtlich Unmengen an Duplikaten hoch, anstatt NICHT alle Warnungen zu ignorieren, sondern per Doppelclick auf die entspr. Warnung alle doppelten Hausnummern zu selektieren und mit Ctrl+F “new” “in Auswahl suchen” alle neuen doppelten zu suchen und löschen, was weitgehend dem entspricht, was du da machst, wenn ich dich richtig verstehe (oder gleich das Script, was ich oben gepostet habe)?
Der Haupt-Unterschied, den ich sehe: addr:city muss bei dir zwingend angegeben werden, aber wenn du sowieso nur die Adressen der Gemeinde lädst, kannst du das auch dort, wo es fehlt, problemlos davor hinzufügen.
Und warum löscht du zuerst nur die Tags und nicht gleich die Nodes?

man müsste es halt auch nutzen, denn natürlich sind die Adressen immer noch irgendwo ohne Straße bzw. bei Straßen mit falschem Namen und werden damit zB von Nominatim schon mal nicht einmal gefunden
https://www.openstreetmap.org/way/634070296
https://www.openstreetmap.org/node/5983716385
https://www.openstreetmap.org/node/5983716363#map=19/48.48774/13.56671
https://www.openstreetmap.org/way/128424581

Das Problem was ich aktuell habe, ist dass ich die Prüfung auf Duplikate per Overpass Filter an Realdaten vornehme.
Hierbei kann es vorkommen dass ein BEV Adresse Node bereits Teil eines Gebäude Polygons geworden ist. Würde ich scheinbar “leere” Nodes löschen, so besteht große Gefahr dass ich hierbei unabsichtlich Gebäudeteile lösche, und es dann massenhaft zu Konflikten kommt.

Kannst Du noch einmal näher auf Dein Script eingehen, und erklären wie Du Dir hierbei den Ablauf gedacht hast. Möglichst mit Video.
Du meinst vermutlich diese Beschreibung: https://forum.openstreetmap.org/viewtopic.php?pid=719103#p719103 das ist für den normalen OSM Mapper nicht anwendbar. Wenn das so einfach wäre würden wir den Editor ID nicht benötigen.

Du bist auf auf der Profi Welle unterwegs. Lass mal das ganze Wasser aus der Badewanne, und füll für uns nur Ein Glas Wasser ein.
Ab besten genau so dass der Boden der Badewanne ein bisschen feucht ist.

Grüße

edit:text

Rom ist nicht an einem Tag erbaut worden.
Ich räume aktuell der Nachbearbeitung wesentlich mehr Zeit ein, alles kann ich aber auch nicht alleine machen.
Wie bereits beschrieben, nur da ich die Adress- Kartoffel ins Feuer geworfen habe, ist OSM noch lange nicht mein alleiniges Projekt.

Dank der von mir beschriebenen neuen Methode https://forum.openstreetmap.org/viewtopic.php?pid=720296#p720296 ist die zu kontrollierende Datenmenge nun drastisch reduziert. Das Mappen macht so endlich wieder Spaß, das bedeutet aber noch lange nicht dass ich plötzlich auch noch für Straßen zuständig wäre. Aber Ja Dein Tool coloured Streets ist hilfreich, und wo es geht bessere ich über dieses Tool gefundene falsch geschriebene Straßennamen auch aus.

Eine effiziente Kontrolle der Namensschreibung von Straßen, sollte aber besser in einem separaten Arbeitsgang erfolgen.
Eine entsprechende Abfrage ist sicher effizienter als jede Handsichtung.
Übrigens bietet regio-osm.de eine solche Auswertung an. Und Ja, Regio OSM ist meine Messlatte, egal was Du gerade an den Straßennamen herumschraubst.

Wenn das Mappen gut von der Hand geht, dann bleiben auch mehr Leute im Projekt.
Machen wir es uns doch nicht unbedingt kompliziert. Daher meine Devise, Adressvervollständigung, je Gemeinde in einem Task.
Bereinigung anschließend in mehreren Schritten, und so dass man diese Tätigkeit auch mal für ein paar Stunden unterbrechen kann.

edit:typo