Ich hole jetzt mal ein wenig aus, warum die BEV-Daten und regio-osm nicht die Reine Wahrheit™ darstellen.
Die braunen Adressen sind hier offensichtlich falsch, wobei es mittlerweile schon deutlich besser geworden ist und der Großteil der restlichen Adressen stimmt, oder zumindest nur mehr um eine Position vertauscht ist. Davon abgesehen verwendet aber auch keiner den Straßennamen “Dürrsee-O”. In OSM ist das jetzt “Dürrsee Ost” und die Straße hat als official_name “Dürrsee-O” - Nominatim findet damit beide Varianten, für regio-osm “fehlen” diese Adressen dagegen. Seen scheinen überhaupt ein Fall zu sein, wo die BEV-Adressen oft falsch oder irgendwo sind, tlw. einfach mitten im See.
Ähnlichen Effekt bzgl. regio-osm gibt es hier:
Die Straßennamen in den BEV-Daten sind abgekürzt, in OSM ist schon alles mit vollem Namen vorhanden. Da setze ich vielleicht “K. R. v. Ghega-Gasse” als official_name, aber “bessere” nicht die vorhandenen aus (bzw. lösch sie nicht einfach und setze neue Nodes)
Gerade bei (v.a. neueren) Reihenhäusern sind die Adressen oft auch erst einmal nur irgendwie durcheinander gewürfelt grob in die Gegend geschmissen. Das kann sehr hilfreich sein, um zu sehen, welche Adressen es prinzipiell einmal geben sollte, aber für die genaue Position ist es wenig hilfreich (und anfällig dafür, dass per AddressHelper irgendein Blödsinn eingetragen wird).
Auch die Gegend, wo du schon beim basemap Abzeichnen daneben gehaut hast, ist immer noch falsch in den BEV-Daten. Die Adressen Ferdinand-Porschestraße 6-12 sind da irgendwo als möglicherweise scheinbare Identadressen, während sie User pebuse schon vor einem Jahr bei einer Begehung den 4 Gebäuden im Norden ohne Adressen zugewiesen hat.
Und das sind offensichtliche Fehler und nicht subtilere, wie um 1 Position verschobene, wie beim angesprochenen See, oder überhaupt Gegenden, die unsystematisch durchnummeriert sind. Was ich damit sagen will: ungeschaut vorhandene Adressen löschen ist völliger Irrsinn, wobei ich generell nichts davon halte, Adressen von Gebäuden zu löschen und an der gleichen Stelle einen Node ohne Informationsgewinn anzulegen.
Die Angaben unter at_bev:addr_date kann man meistens auch nur auf die Attribute beziehen (und da kann man sich nicht 100% sicher sein). Die Position ist (zum Glück) praktisch nie 1:1 die aus den BEV-Daten. Wenn es keinen Grund dazu gibt, greife ich die alten da auch nicht an.
Ich hab jetzt mal geschaut, wieviele Einträge es in der Adress-Tabelle von 10/2017 gibt, deren ID (ADRCD) sich in den Daten von 04/2018 nicht mehr finden lassen, das sind österreichweit anscheiend 1.193 / 2.375.123. Ich hab da bei ein paar Gegenden, die ich kenne, hineingeschaut und so eine richtig komplett falsche ist mir da nicht einmal aufgefallen. Tlw. wurde offenbar genau die gleiche Adresse wieder mit mehr Informationen zu Gebäuden neu angelegt, eine Identadresse aufgelöst, eine Adresslücke aufgelöst, obwohl nicht zu erkennen ist, dass das Grundstück mit einem anderen zusammengelegt worden wäre, oder eben wirklich die Zusammenlegung von benachbarten Grundstücken: https://my.sofortcloud.com/index.php/s/qCejcVUFyigZdus
Andere Änderungen zw. den letzten beiden Stichtagen kannst du hier sehen: https://my.sofortcloud.com/index.php/s/wnmvDwU3sZI6GEG
Das sind irgendwelche Einträge im Output, die im vorigen nicht vorkamen, sprich unterschiedliche Position, Straßennamen, Schreibweise etc. Den obigen Vergleich mit den IDs könnte man prinzipiell auch noch machen und sich nur die neuen IDs anschauen.
Fehlende Adressen zu ergänzen halte ich auf jeden Fall sinnvoller, als in Gegenden, zu denen du keinen Bezug hast, irgendwelche Importe drüber zu bügeln, damit es einen mehr oder weniger definierten Stand gibt und der Vergleich mit den Import-Daten dann überraschenderweise sagt, dass alle Importdaten vorhanden sind.
Wenn du auf kleinerer Ebene systematisch vorgehen willst, kannst du auch einzelne Straßen abarbeiten (Kontextmenü auf addr:street => Schlüssel/Wert suchen):