Office: (Office 2013) RegEx fehlende Hausnummer in Straße

Moin Moin,

vor ein paar Tagen hab eich mich erstmals mit RegEx auseinander gesetzt und siehe da, soooooo schlimm isses gar nicht.

Die Kundendaten in meiner DB kommen über einen Import aus einer Drittanwendung und da steht bei den Adressen, vornehmlich unter Straße zuweilen übles Zeugs drin. Selbst habe ich keinen Einfluss auf die Drittanwendung, das üble Zeugs muss aber raus und somit vorher gefunden werden. Mit den Standard-Textfunktionen von VBA ist das aber kaum lösbar, daher RegEx.

Bei dem üblen Zeugs unterscheide ich Ungültig und Unklar.

Ungültig ist zB., wenn ein Slash, Klammern oder Fragezeichen im Text vorkommen.

Unklar ist zB, wenn die Hausnummer fehlt, dass soll es ja tatsächlich gelegentlich geben.

Einige Patterns habe ich nach Net-Recherche super hinbekommen.

Diese habe ich in einer Funktion, die in einer Abfrage läuft und bei finden eines Mangels True zurück gibt.

Was ich nicht hinkriege ist das Aufspüren von Straßen ohne Hausnummer.

Pattern "[0-9]" spürt Straßen auf, die Zahlen enthalten. Für die Treffer gibt die Funktion WAHR zurück, die für die Straßen ohne Hausnummer FALSCH.

Nun dachte ich, so: "[^0-9]" könne ich das Ergebnis umkehren aber weit gefehlt. Es werden dann alle Straßen mit WAHR gekennzeichnet.

Kann mir jemand auf die Sprünge helfen?

Hier noch die Funktion
Code:

:)

 

Zuerst einmal: Bei Straßen und Hausnummern gibt es derart kreative Kombinationen, dass wohl einstufig eine 100-prozentige Überprüfung nicht gelingen wird mit einigermaßen beschränktem Aufwand.

Für ein Pattern, das eine hohe Trefferquote aufweisen soll, müsste man sich vorher erst einmal die zu prüfende Datenbasis sowie objektiv richtige Adressen, die vorkommen können, anschauen. Dabei interessieren dann die Ausreißer, Grenzfälle, Ausnahmen besonders.
Die (standardisierte) Masse ist ja leicht zu beherrschen.

Str. des 3. Oktober 19b
Hier sieht man,
- dass Ziffern durchaus auch schon im Straßennamen vorkommen können,
- dass auch andere Zeichen als Ziffern in der Hausnummer vorkommen können,
- dass neben Ziffern und Buchstaben (Umlaute/ß beachten) auch Leerzeichen, Punkte und Bindestriche auftreten könnten,
- dass Straße abgekürzt oder in voller Länge auftreten kann u.a.

Von Sonderformen wie die Mannheimer Adressen oder Hinterhof-/Seitenhausadressen jetzt mal zu schweigen.

 

Hallo Eberhard,

mir ist völlig klar, dass es das Ultimative Pattern für gültige Adressen vermutlich nicht gibt oder nur schwer erreichbar ist und ich habe auch nicht die Absicht, diesen zu kreieren.

Was ich beabsichtige, ist eine Überwachung der Adressen. In erste Linie soll das System dem Anwender sagen: "Guck Dir mal diese Adressen an, die kommen die komisch vor!"

In manchem Fällen, ich glaube Klammern und Fragezeichen haben in Straßenangaben nichts zu suchen, soll das System die Verwendung von Adressen (z.B. beim GoogleRouting) aber auch verhindern.

Letztlich muss ich mich an die ganze Sache herantasten. Wenn Du mir jetzt sagst, das Klammern durchaus in Straßenangaben vorkommen können, muss ich das entsprechend ändern.

Für den Moment möchte ich jedoch nur wissen:

Wie muss ein Pattern aussehen, dass mir in einer Gruppe von Strings diejenigen meldet, die keine einzige Zahl enthalten.

Gruß Uwe

 

Nicht-Ziffer: \D
Ziffer: \d

Das habe ich nun nicht gesagt.

 

Damit wollte ich sagen, wenn sich Voraussetzungen, von denen ich ausgehe, als falsch erweisen, muss ich entsprechend reagieren. So hatte ich die STr. d. 3. Oktobers auch nicht auf dem Schirm, was eines meiner Pattern hinfällig macht.

Das entspräche IMHO: \D = [^0-9] und \d = [0-9]

Irgendwie funzt das nicht so wie ich es möchte:

Fürs Verständnis: Meine Logik soll sein:
Mit dem Pattern beschriebe ich, was als "verdächtig" gemeldet werden soll. In der Abfrage, in die die Funktion integriert ist, soll Wahr erscheinen, wenn etwas verdächtig ist, Falsch, wenn dem nicht so ist.

Ich erhalte folgende (auszugsweise) Ergebnisse:

-------------------------------\d ----------\D ----
Triebseeser Str. --------Falsch-------Wahr
Ringstraße 10 ----------Wahr---------Wahr

\d arbeitet also wie gewünscht , \D aber nicht.

Nur weiss ich nicht, warum das so ist. Eine Vermutung wäre, dass Regex vorhandene Zeichen, die keine Ziffern sind, dann als Nicht-Ziffer zurück gibt.

 

Richtig. Hier werden Zeichen beurteilt, und zwar alle Zeichen eines gegebenen Strings, also z.B. auch Steuerzeichen.

Mit "\D" prüft man also, ob ein Zeichen, das keine Ziffer ist, im String vorkommt. Das ist ein kleines Beispiel dafür, dass man die gewünschte Logik präzise formulieren muss, um ein passendes Suchmuster erstellen zu können.
Dabei gilt auch: Es wird alles gemacht, was nicht ausgeschlossen wird.

 

Ich finde im NETZ, das [0-9] alles matcht, was Ziffern enthält. Dan such eich nach Möglichkeiten der Negierung, wo ich dann zunächst mal finde: [^0-9]. Auf den ersten Blick würde ich umgekehrtes Ergebnis erwarten.

Momentanes Fazit:
Regex meldet mir, dass alle Zeichen in 'Triebseeser Str' keine Ziffern sind. Nur das will ich ja nicht wissen.

Ergo müsste man alle Zeichen, die nicht Ziffer sind, von der Prüfung ausschließen.
Oder man entfernt vor dem Prüfen alle Zeichen, die nicht Ziffer sind aber das kann es doch auch nicht sein?
Geht das irgendwie oder bleibt mir am Ende doch nur die Negation der Funktionsrückgabe?

 

Hallo Storch!

Seit neuestem A2013?

Ich verstehe etwas nicht:
Wenn Regex zB. nach einer Leerstelle und daran anschließend
max. drei aufeinanderfolgende Ziffern findet,
dann enthält die Adresse mit hoher Wahrscheinlichkeit eine Hausnummer.
Findet Regex keine Übereinstimmung dann fehlt eine Hausnummer
oder vor der Hausnummer fehlt eine Leerstelle, dann ist sie zumindest verdächtig.
Also: Wenn die eine Bedingung zutrifft, so ist eine Hausnummer vorhanden.
Alles andere ist prüfenswert. Wahrscheinlich!

Nach nicht numerisch zu suchen ist nicht sinnvoll, da die meisten Adressen Buchstaben enthalten.
Außer in winzigen Orten, dort kann die Zahl 19 schon eine Adresse sein.
Das Vorhandensein von aufeinanderfolgenden Ziffern ohne Buchstaben davor oder danach ist wahrscheinlich auch eine Hausnummer.

Ist es das wonach Du suchst?

Es geht ja nicht um Gewißheiten sondern um Wahrscheinlichkeiten.

Noch etwas: Das (Die) von Regex gefundene(n) Ergebnis(se) kannst Du
auswerten und mit dem zu untersuchenden String abgleichen.
Die Anfangspositionen der gefundenen Ergebnisse sind sehr aussagefähig:
Ab welcher Stelle in welcher Länge wurde(n) Übereinstimmung(en) mit dem Pattern gefunden?

Bitte jetzt keine Diskussion über Adressen an sich entfesseln.
Was es da alles so gibt hat schon Eberhard mit "kreative Kombinationen" umschrieben.

Wolfgang

 

Hallo Wolfgang,

A2013 schon länger. Mein letzter Fred(UTF-8) war auch so gekennzeichnet.

Ich war erstmal drauf geeicht, das RegEx doch Strings aufspüren könne müssten, die alles mögliche enthalten, jedoch keine Zahlen. Mir deucht unterdessen, das das so auch gar nicht geht, habe im Netz jedenfalls nix finden können, was darauf hindeutet. Man könnte auch sagen, was nicht da ist, kann man nicht finden.

Numerischen Zeichen mit einem Leerzeichen davor kann man durchaus als Hausnummer interpretieren. Habe ich in einem Pattern auch schon so angewendet. Gesucht habe ich erstmal nicht danach aber es ist eine alternative Lösungsvariante.

Für mein Problem mit den Zahlen kommt auch eine Negation der Funktionsrückgabe in Betracht.
Das Pattern [0-9] kennzeichnet alle Straßen mit Wahr, die eine Zahl im String haben. Die beiden, die keine Zahl haben mit FALSCH. Durch die Negation wäre es, wie ich es möchte, nur ich habe auch mindestens ein Pattern in der "Prüfgruppe" 'Unklar' (siehe #1) dessen Ergebnis ich nicht negieren kann. Somit müsste ich zwei Prüfungen ausführen, von denen eine negiert wird. Sollten es mehr Prüfungen in der Gruppe werden, erhöht sich der Codeaufwand weiter.

Für zwei Prüfungen hab ich folgende Lösung:
Code:

 

!!
Wahrheiten können so einfach sein.

Dein Suchen nach Ziffern wirkt noch ein wenig diffus, zumal wir schon festgestellt hatten, dass Ziffern auch im Straßennamen auftauchen können. Daher sollte man doch das Ganze für eine Position im String (Ende / Beinaheende des Strings) definieren.

Was hältst Du davon:
Code:

Dazu IgnoreCase auf True, damit man sich nicht in Groß- und Kleinschreibungen verheddert.

 

\@Eberhard!

Hmm!

Auf etlichen Online Testseiten (ua. regexe - Reguläre Ausdrücke online testen) findet man mit Deinem Pattern zumeist als Ergebnis den gesamten String.
Mit dem RegEx Version 5.5 ergibt der Pattern einen Fehler.

Wolfgang

 

Ich bekomme mit meinen Standardfunktionen (siehe Code-Archiv) keinen Fehler.
Code:

Natürlich, ich teste ja auch den ganzen String. Wird am Ende des Strings eine bis mehrere Ziffern, nachfolgend kein oder ein Leerzeichen sowie nachfolgend kein oder ein Buchstabe gefunden, kann man dies als Hausnummer interpretieren und ein True geben.

=> Ein Hausnummerngebilde ohne Straße wäre nun aber auch keine als gültig anzunehmende Adresse.

=> Wenn man die Hausnummer (nach genanntem Schema) isolieren will, kann man ein Subpattern setzen und dieses dann über die Execute-Methode auswerten:
Code:

 

Servus ebs17,
wer hat denn diese geniale "RegEx" Methode erfunden und wo bekommt man
Schulungen, Bücher usw. dazu?

 

Siehe auch eine kleine Stoffsammlung: "Intelligente" Textanalyse

Wer es erfunden hat, weiß ich nicht. Mich beeindruckt immer wieder die Mächtigkeit. In einer Anweisung (dem Suchmuster) kann man eine extreme Logikverdichtung herbeiführen und sowieso Dinge lösen, die mit VBA-Einzelbefehlen eher nicht lösbar sind.
Die meisten arbeiten ja schon (unbewusst) mit RegEx. Die LIKE-Gestaltungen (wie ein Muster) in SQL oder VBA sind doch nichts anderes, wie auch die erweiterten Suchen- und Ersetzen-Optionen in Word oder anderen Textverarbeitungen.

Schulungen für die Anwendung in VBA braucht man eher keine, die möglichen Methoden sind sehr begrenzt und übersichtlich, und die Suchmuster recherchiert man sich im Internet oder denkt sie sich selber aus. Testen ist da ganz wichtig, eben dann besonders bei den Grenzfällen und Ausreißern in den Daten.
Etwas Üben muss man dann wie überall.

Standardwerk zum Lesen wäre "Reguläre Ausdrücke" von Jeffrey E. F. Friedl aus dem Hause O'REILLY.

 

Problem:

Lösung:
Code:

*Smilie