Adressen abgleichen

[Jasocul]

Danke für die Tipps, jobo.
Die sind mir alle bekannt. Ich könnte das auch sicher selbst alles umsetzen aber dafür fehlt mir einfach die Zeit. Deswegen fragte ich nach fertigen Komponenten / Methoden-Sammlungen.

Eingesetzte DB ist übrigens MS-SQL.

@hanvas:
Danke, ich werde mir das mal ansehen.

[jobo]

Ok, Levensthein und diverse "fertige" phonetische Algorithmen wirst Du sicher in MSSQL finden.
Wenn es noch fertiger sein soll und libpostal helfen würde, dann hilft dir dieser Wrapper vielleicht zur Einbindung direkt in MSSQL:
https://github.com/AeroXuk/LibPostalNet

[stahli]

Wir hatten so etwas hier schon mal: https://www.delphipraxis.net/154811-...rozentual.html

Ich habe noch eine Variante, die Adressen mit "c/o" in die Teile davor und danach zerlegt und diese beide getrennt vergleicht.

Welche Methode zu den eigenen Daten am besten passt musst man immer individuell entscheiden.

[EarlyBird]

vielleicht hilft Dir fuzzydupes-net weiter.
Eventuell kannst Du es direkt in der MS-SQl Datenbank einbinden Stichwort CLI integration.
Ist nicht für Delphi, aber eventuell einen Blick wert

[mensch72]

unabhängig davon ob es ne fertige Fix&Foxi Lösung gibt, wäre es auch da sinnvoll und nötig das Problem zu splitten und zunächst für eine "eineindeutige" Identifizierung/Unterscheidung der täglich gelieferten (nur teils neuen) Daten zu sorgen.

=> 1. grobes Stichwort wäre also ein "Hash" über die "Eingangs-Adressdatensätze", zunächst völlig egal was da drin steht. Es hat sich bewährt, vor dem "CalcHash" zunächst alle WhiteSpaces zu entfernen, dann stören ev. Leerzeichen/Tabulatoren/Zeilenumbrüche welche nur der Formatierung dienen nicht den HashAlgo... wenn Hash erkannt, also Daten 1:1 schonmal erhalten und "ein geprüftes Ergebnis" bekannt, dann stets keine weitere aktive Verarbeitung mehr nötig!

=> 2. grobes Stichwort wäre "grobe" Adresszerlegung, wir "malen" hierzu die Daten einfach der Reihe nach in ein Bitmap, welches quasi einer "Visitenkarte" entspricht... und schau einer guck, da gibt es sehr viele und wirklich gute super Tools, welche bei guten BusinessCardScannern oft gratis dabei sind... wir haben uns da ein Interface "gebastelt", welches einem guten Tool statt Scandaten unser erzeugtes Bitmap unterschiebt und das zerlegte und quasi auch schon normalisierte Resultat "irgendwie" abgreift

=> 3. grobes Stichwort wäre dann "grobe" Adressvalidierung, wir nutzen hierfür Google&Yahoo(ohne Maps???-Api)... einfach die Eingangsdaten ohne Zeilenumbruch ins Suchfeld und dann geschaut was "ähnliches"(!incl. Werbung!) auf der ersten Antwortseite auftaucht... so ist dann zu 97% PLZ & Ort voll validiert&normalisiert... Straße zu 95%, Hausnummer aber nur zu 85%

=> 4. grobes Stichwort wäre bei Bedarf also eine weitere detailierte&automatisiere Adressvalidierung für Straße und Hausnummer... wir nehmen hier eine API für eine bekannte TelefonbuchCD und testen da "vorwärts wie rückwärts Suche", was wir anschließend wenn möglich noch über "DasÖrtliche" gegenprüfen. (man sollte die öffentlichen WebSeiten der "GelbenSeiten" und DasÖrtliche" aber nicht "erkennbar"(zu häufig/zu schnell) für sowas missbrauchen, denn deren Server mögen das nicht und es verstößt klar gegnen deren AGBs!)


Nun hat man im Prinzip Vergleichbares... ABER NUR, wenn man seine eigenen Daten (obwohl eigentlich schon valide) auch nochmal durch den gleichen Ablauf schickt !!!
Abschließend also wieder alle WhiteSpaces heraus und nochmal jeweils einen HashAlgo darüber anwenden. Der jetzt resultuierende Hashvergleich wird nun zu 98+% exakt sein
Den Hash der Eingangsdaten also samt TimeStamp und Hash dieser Ergebnisdaten so speichern, das dies zukünftig Anfangs schnell abprüfbar ist.
Die resultierenden Klartextdaten in einem typisierten internem Standardformat halten und künftig z.B. via JSON,XML,... normiert&standardisiert abfragbar gestalten.


-> interne oder externe Fertiglösungen gibt es stets nur jeweils für Teilbereiche, selbst wenn gute "BusinessCardScanner" quasi den kompletten "logischen" Workflow können, braucht es für den jeweils praktischen Workflow doch stets ein paar Zeilen Programmcode und etwas Hirnschmalz

[jobo]

Na da freu ich mich doch wieder mal, dass ich nicht im "Örtlichen" stehe.

M.E. ging es nicht um Validierung, sondern um Dublettenfindung bzw. Matches.
Dafür ist eine Validierung nicht nötig. Wenn bspw. ständig falsche Daten irgendwo gekauft werden (und importiert und weiterverarbeitet werden), macht es eine zusätzliche Validierung (die gegen unterschiedliche Optimierungsstände läuft) nur bedingt besser, oder?

Der entscheidende Schritt ist ja wohl ein Normalisierungsverfahren, das auf beiden Seiten identisch eingesetzt wird.

Warum man dazu unbedingt den (vorsichtigen) Missbrauch von irgendwelchen öffentlich verfügbaren Schnittstellen empfehlen muss, leuchtet mir nicht wirklich ein.

[p80286]

Zitat von jobo:

M.E. ging es nicht um Validierung, sondern um Dublettenfindung bzw. Matches.

MMMmmm,
was ist eine Doublette?
Manfred Müller, Kaiserplatz 8, Aachen ist wahrscheinlich doppelt, bei
Manfred Müller, Templergraben 55,Aachen wäre ich mir nicht so sicher.
Wenn dann noch abweichende Post- und Hausanschriften ins Spiel kommen kommt man mit dem formalen Ansatz
wenn gültige(Adresse1)=gültige(Adresse2)
nicht sehr weit. So müßten z.B. Anschriften von größeren Organisationen "normalisiert" werden. (abweichende Post und Hausanschrift) und bei Unternehmen die mehre Standorte haben sind diese auch gegen die Zentrale zu vergleichen.(z.B. BASF AG/BASF SE)

Gruß
K-H