Verleihungslisten "Datenbank"

[sonki]

Work-In-Progress - Vorankündigung

Worum geht es?
Das Bundesarchiv hat unter der Signatur RH 7 OKH/Heerespersonalamt diverse Verleihungslisten online gestellt.
D.h. von verschiedensten Einheiten gibt es derzeit 667 Listen zum Kriegsverdienstkreuz und 686 Listen zum Eisernen Kreuz. Jede dieser Listen hat einen Umfang von grob 50-6000 (!!!) Seiten, wovon aber viele Seiten keine Namenslisten sind, sondern Administratives, Deckblätter, Leerblätter ect.. Trotzdem erwarten ich Hundertausende von Namen und mit diesen Funden kann man Einheit und Verleihungsdatum, Geburtsdatum erfahren - immerhin.
Die Seiten mit Namenslisten sind in einer Vielzahl von Tabellenformaten, uneinheitlich, schief und krum und da es Originale sind, mit einer Vielzahl von Tipp-Fehlern, Leerzeichen in den Namen, Geburtsdaten, Ortsangaben.
Trotzdem eignen sie sich gut für eine Texterkennung da es relativ klare, kontrastreiche Schreibschinenschrift ist.

Aufgrund technischer Einschränkungen ist in diesem Projekt nur eine Ganzseiten-Texterkennung angedacht. D.h. über jede Seite wird eine Texterkennung laufen gelassen. Der erkannte Text wird dann in eine Datenbank geschrieben (neben Signatur und Seitenzahl) und man kann dann eine Suche nach Texten vornehmen.
Da hier nur über den komplette Text einer Seite gesucht werdne kann und es keine getrennten Einträge prro Person in der Datenbank gibt, muss man hier auf eine exakte OCR-Erkennung hoffen, ansonsten kann es sein, das man hier über die Suche keinen Match erhält.

Technisches - Vorghehensweise, Implementierung

1. Manuelles Herunterladen der insgesamt 14 HTML-Übersichtsseiten Seiten beim Bundesarchiv (Pro Seiten 100 Listenverweise)
2. Python-Script was diese 14 Seiten einlädt und die Signaturen extrahiert, den Downloadlink zusammensetzt & als json abspeichert
3. Python-Script, welches alle 1353 Listen herunterlädt. Dies geschieht in Batches, da wir hier von einer Datenmenge >1TB reden - ganz genau kann ich es nicht sagen - hab das nur grob nach Prüfung von 50 Listen überschlagen, es gibt auch große Unterschiede im Umfang der Listen.
4. Python-Script, welches mittels doctr und dem tilman-rassy/doctr-crnn-vgg16-bn-fascan-v1 Erkennungsmodel (spezialisiert für franz/deutsch) für jede Seite eine Texterkennung erstellt und es in einem Zwischenschritt pro Seite als .txt abspeichert. Mit tesseract hatte ich aus aktuell unklaren Gründen größere Probleme.
5. Python-Script, welches diese .txt Daten dann in eine DB schreibt - dies kann, wie auch Download & OCR inkrementiell geschehen, damit ich jederzeit die Prozesse neu starten kann, ohne bereits fertige Seiten neu zu berechnen.
6. Python-Script, welches nun die DB abfragen kann, inklusive zusätzliche Filter.

Alle 6 Schritte sind bereits in einer ersten Fassung implementiert (Stand 16.02.2025). In der Hoffnung das ich die OCR Erkennung nicht ein zweites Mal ausführen muss (weil ich z.b. grobe Fehler entdecke), sind die nachfolgenden Punkte 5 und 6. jederzeit nachträglich anpassbar und ich kann im Zweifel diesen Teil komplett neu durchlaufen.

Wie auch bei den Vermisstbildlisten ist dieses Projekt mehr just-for-fun und Ausloten der technischen Möglichkeiten. Die Datenbank erhebt keinen Anspruch vollständig zu sein und die OCR-Erkennung wird viele Einträge nicht auffindbar machen. Da die Listen aber nach Einheiten sortiert sind, kann sich jeder im Zweifel selbst auf die Suche machen. Selbst suche ich keine Personen per se - aber falls meine Großväter/-onklel dort auftauchen sollten, nehme ich das natürlich mit.

Suchergebnisse, Abfrage
Anders als bei den Vermisstbildlisten ist eine Suche hier etwas aufwändiger, da man nur über eine komplette Seiten suchen kann und die Daten in den Tabellen oftmal mehrspaltig sind (was Nachnamen und Geburtsorte komplett auseinanderreissen kann). Auch geht hier vorerst keine Fuzzy-Suche (Suche nach ähnlich klingenden Namen). Soll heißen, hier wird die Suche viel mehr manuelles Gegenprüfen in den eigentlichen Unterlagen erfordern, aber mit der Signatur und Seitenzahl geht dies relativ gut, wenn auch viel langsamer als bei den Vermisstbildlisten.

Aktueller Stand
Das Projekt wurde erst heute gestartet (16.02.2025) und ich habe bisher 17 Listen abgearbeitet - was ca. 10K Einzelseiten entspricht. Download und OCR Erkennung werden also noch einige Zeit dauern, da ich dies nicht rund um die Uhr laufen lasse, weil ich möchte nebenbei auch noch an meinem PC arbeiten können und es auch nur bedingt tagsüber während meiner Abwesenheit durchrechnen will.
Updates folgen dann hier in den nächsten Tagen und Wochen.

Updates:
17.02.2025 - 9:00 Uhr: 58/667 (Kriegsverdienstkreuz) | 0/686 (EK) | 34295 Seiten mit OCR
18.02.2025 - 8:00 Uhr: 173/667 (Kriegsverdienstkreuz) | 0/686 (EK) | 84848 Seiten mit OCR (davon 19820 Leerseiten)
19.02.2025 - 8:00 Uhr: 319/667 (Kriegsverdienstkreuz) | 0/686 (EK) | 133367 Seiten mit OCR (davon 33584 Leerseiten)

P.S. Unabhängig vom Rest, ich hab schon wieder so einen Hals, weil das Bundesarchiv mit Invenio das mit Abstand schlechteste Benutzerinterface der Welt erschaffen hat und daran festhält. Es ist und bleibt seit Jahren eine Frechheit was man einem da anbietet - benutzerfeindlich ist noch das nettestes Wort. Wer auch immer dafür verantwortlich ist, sollte sich in Grund und Boden schämen. Meine Fresse, was für ein Pfusch...
[Anmerkung: Angeblich soll es Mitte 2027 ein Update für Invenio geben, wo einige seit Jahren gewünschte Features endlich eingebaut werden. Bin ja mal gespannt wieviel meiner Featurewünsche die ich schon vor Jahren angefragt habe dann schlußendlich kommen. Aber die Entwicklungszeiten bei denen sind ja jenseits von Gut und Böse.]

Also, falls jemand noch einen Wunsch hat (für die Datenbank an sich, Ausgabemöglichkeiten), dann jetzt hier oder für immer schweigen

Hinweise von sonki aus Beitrag Nr. 84:

Download der sqlite Datenbanken (.zip):

Verleihungslisten - KVK: https://drive.google.com/file/d/1XvW...usp=drive_link
Verleihungslisten - EK: https://drive.google.com/file/d/1s38...usp=drive_link

.zip Datei mit Passwort geschützt: verleihungsliste
Die Downloadlinks werden einige Monate so bleiben. Irgendwann sind sie dann aber sicherlich nicht mehr aktiv.

Nutzung:
1. Download und entpacken der zip Dateien (siehe dazu das zip Passwort).
2. Browsen und Suchen in der jeweiligen DB z.b. mit dem kostenlosen Programm DB Browser: https://sqlitebrowser.org/

DB-Struktur ist mehr als einfach - Tabelle "records" mit jeweils 3 Spalten:
sig - TEXT
page - INTEGER
text - TEXT
Primary Key (sig, page)

Nachträgliche Anpassungen - post OCR - in der DB: Soweit möglich alle Datumsangaben normalisiert in das Format: dd.mm.yy (zero-padded). Gibt allerdings noch immer Datumsangaben die davon nicht erfasst wurden bzw. natürlich alle Datumsangaben bei denen OCR Buchstaben/Zahlen falsch erkannt hat.

Support:
Kein Support hier im Forum. Macht mit der DB was ihr wollt, schreibt euch eigene angepasste Suchen, entwickelt eure eigenen SQL-Queries ect. pp.

[Visitor]

Hallo Sonki,

puh, Wahnsinn was Du jetzt da machst und uns da anbietest. Ich weiß, wahrscheinlich bin ich der Übeltäter dieses Projektes, da ich in dem VBL Thema ja mal angefragt hatte, ob dies möglich wäre.

Ausgabemöglichkeit wäre mir persönlich am liebsten, wenn ich das sagen darf, wenn man ganze Orte rausfiltern könnte. Da bräuchte ich auch keine Namensangabe, da würden mir die Signaturen mit den jeweiligen Seitenzahlen reichen. Die entsprechenden Soldaten sollte man dann ja relativ schnell finden.



Vielen vielen Dank

Gruß Dominik

[sonki]

Ausgabemöglichkeit wäre mir persönlich am liebsten, wenn ich das sagen darf, wenn man ganze Orte rausfiltern könnte. Da bräuchte ich auch keine Namensangabe, da würden mir die Signaturen mit den jeweiligen Seitenzahlen reichen. Die entsprechenden Soldaten sollte man dann ja relativ schnell finden.k

Wie gesagt, jede Seite wird komplett mit Texterkennung versehen. Die Suche wird daher eine einfache Textsuche mit zusätzlichen optionalen Filtern sein. D.h. wenn du nach Ort "Beispieldorf" suchst, bekommst du alle Signaturen+Seiten für diesen Ort.
Wichtig zu wissen bei der Ortsuche istt hier aber folgendes. Es gibt viele Seiten wo die entsprechende Person über 2 Zeilen läuft und wo es vorkommen kann das der Ort in Spalte x über 2 Zeilen geht. Da die Texteerkennung aber Zeilenweise vorgeht, könnte man folgendes OCR-Ergebnis für "Beispieldorf" bekommen:

Müller Hans 1.2.03 Beispiel- Einheit abc
dorf

Und schon habe ich keine Chance mehr diesen Eintrag zu finden, außer ich Suche nach "Beispiel" und filter diese Ergebnisse weiter nach "dorf". Das gleiche Problem kann es auch mit langen Namen. gebe - hängt aber stark vomTabellenformat ab und wie der Schreiberling damals Lust und Laune hatte - es scheint absolut kein einheitlich Prinzip zu geben. Das war bei den Vermisstbildlisten komplett anders - dort konnte ich ja zuerst jeden Personenblock exakt bestimmen. Bei diesen Listen hier ist das so ein Kraut und Rüben Durcheinander das eine Erkennung eines Personeneintrags über 1 oder 2 Zeilen nicht mehr möglich ist - jedenfalls habe ich mit Maschine-Learning einiges probiert und es wurden vielleicht 20-30% erkannt, der Rest nicht. Zumal der Ort manchmal in Spalte 2, manchmal in Spalte 3 oder 4 steht - ist vollkommen willkürlich und abhängig von der Einheit oder was grad zufällig für ein Papierstück in die Schreibmaschine eingezogen wurde.

Grundsätzlich können zusätzlich noch Filter in der Suche benutzt werden, also ausgehend von den ersten Ergebnisse über den Hauptsuchbegriff kann man dann weiter verfeinern, analog zu den Vermisstbildlisten. Das ist relevant für die Suche nach Personen, Hauptsuchbegriff ist der Nachname und dann filtert man weiter nach z.B. Vorname oder Ort oder Geburtsdaten.
Eine Namenssuche wird hier vermutlich mehr erfassen, als eine Ortssuche, weil bei Orten die 2-Zeilen Problematik nach Stichproboem größer ist.

Das nur als Hinweis was die Suche in diesen Liste kompliziert macht und wo die Grenzen sind. Ich kann nicht sagen wieviel Prozent der Einträge diese 2-Zeilen-Problematik aufweisen, würde das im eher niedrigen einstelligen Bereich sehen, aber man sollte es im Hinterkopf haben.

[Benjamin04]

Hallo Sonki,

in freudiger Erwartung auf diese Möglichkeit danke ich dir für dein technisches Engagement zur Hilfestellung für unsere Nachforschungen.

Grüße Benjamin

[sonki]

Kann den ersten Beitrag nicht mehr editieren, daher gehts mit Updates hier weiter:

Updates:
17.02.2025 - 9:00 Uhr: 58/667 (Kriegsverdienstkreuz) | 0/686 (EK) | 34295 Seiten mit OCR
18.02.2025 - 8:00 Uhr: 173/667 (Kriegsverdienstkreuz) | 0/686 (EK) | 84848 Seiten mit OCR (davon 19820 Leerseiten)
19.02.2025 - 8:00 Uhr: 319/667 (Kriegsverdienstkreuz) | 0/686 (EK) | 133367 Seiten mit OCR (davon 33584 Leerseiten)
20.02.2025 - 8:00 Uhr: 497/667 (Kriegsverdienstkreuz) | 0/686 (EK) | 180864 Seiten mit OCR (davon 44519 Leerseiten)
21.02.2025 - 8:00 Uhr: 538/667 (Kriegsverdienstkreuz) | 0/686 (EK) | 204948 Seiten mit OCR (davon 51451 Leerseiten)
22.02.2025 - 8:00 Uhr: 581/667 (Kriegsverdienstkreuz) | 0/686 (EK) | 248922 Seiten mit OCR (davon 61270 Leerseiten)
23.02.2025 - 8:00 Uhr:
667/667 (Kriegsverdienstkreuz) - 228711 Seiten mit OCR (Seiten mit Text) - Datenbankgröße 230MB (sqlite3)
0/686 (EK) - 0 Seiten

Wie man sieht ist das alles sehr zäh und langsam. In den bisherigen 180K Seiten (Stand 20.02) sind pi-mal-Daumen vielleicht 1/4 Seiten mit Namen (vermutlich weniger). Aber so grob überschlagen müssten bereits 1 Million Personen enthalten sein. Aber das nur eine ganz grobe Einschätzen - alles +/- ein paar hundertausend. Das Kriegsverdienstkreuz wurde laut wiki ~2.8 Millionen Mal verliehen. Das EK ca. 3 Millionen Mal. Ich habe keine Ahnung wieviel Akten es dazu gibt und wie vollständig die Daten beim Bundesarchiv dazu sein. Aber da kommt schon ne nette DB zusammen, selbst wenn die OCR bei ein paar Hundertausend Einträgen versagen sollte. Leider kann ich nicht die Personen zählen, da wie gesagt nur Ganzseiten-OCR.

Technisches:
Ich teste immer noch mit diversen Machine Learning Methoden bzw. Modellen herum ob es nicht doch irgendwie möglich ist eine Tabellenzeilen-Erkennung hinzubekommen, aber solange das nicht klappt (vielleicht auch nie), dann bleibt es bei der Ganzseiten-OCR.
Hatte es zuerst mit yolov5 und eigenen Trainingsdaten versucht, aber das da wurde maximal 20% erkannt. Ich will vielleicht nochmal mit yolov8 testen, aber vermute das es nicht großartig besser wird. Aktuell richte ich mein Augenmerk auf microsoft/table-transformer-structure-recognition-v1.1-all was out-of-the-box schon erstaunlich gute Ergebnisse zeigte (habs aber auch nur mit 5 Seiten getestet). Werde mir also mal anschauen ob man da mit individuellen Trainingsdaten was brauchbares herausbekommt. Aber das wird eher was zum rumspielen sein, wenn ich einmal durch alles mit OCR durch bin und es nur noich darum geht das Ganze zu verbessern.

Grundsätzlich kann ich jetzt bereits sagen, das die OCR Erkennung einigermaßen ok ist und aufgrund der schieren Menge an Namen habe ich auch schon Einträge von eigenen Vorfahren bzw. Verwandten gefunden.

P.S. Zusätzlich bin ich grad am Testen um die OCR Ergebnisse nachträglich zu verbessern - vorerst nur für Geburtsdaten. Kommas durch Punkte ersetzen, diverse nervige Dinge der Verleihungslisten fixen wie "12. 4.20" (Leerzeichen im Monat), alle Datumsangaben in das Format dd.mm.yy umwandeln, diverse typische OCR-Fehler fixen, l->1, o->0, O->0, Tageswerte wie 71...79 .> 21..29, 50 -> 30.
Im Zuge dessen habe ich Datumsangaben in den Listen gefunden die ich definitiv nicht vernünftig erkennen werden. In machen Listen sind Geburtsdaten so in den Tabellen:
14.
7.
93
Also über 3 Zeilen, Tag, Monat, Jahr stehen untereinander. Das kann keine Texterkennung zu einem Datum zusammenfügen...null Chance...dies also die nächste Schwierigkeit mit den Verleihungslisten. Zum Glück scheinen die meisten Listen aber mit normalen Geburtsdaten, also ganz normal hintereinander, Tag.Monat.Jahr.

[Henry Jones]

Vielen Dank für die Mühe, die du da reinsteckst. Ich denke dass ist wirklich ein tolles und sehr hilfreiches Projekt. Bin schon gespannt auf das Ergebnis und die Qualität. Wäre sicherlich auch für das Bundesarchiv von Interesse und/oder man könnte z. B. ähnlich wie bei den Verlustlisten mit CompGen ein Erfassungsprojekt umsetzen mit den vorerfassten Daten.

Viele Grüße
Alex

[sonki]

Bin schon gespannt auf das Ergebnis und die Qualität.

Nur mal ein Beispiel damit man sich die Suchergebnisse hier besser vorstellen kann und woran man die Probleme gut erkennt - unterscheidet sich nämlich deutlich von der Vermisstbildlisten-Suche:

Beispielsuche nach "Meier" mit zusätzlicher Filterung nach "Hans". Nachstehend 2 Ergebnisse aus der, für diese Suchparameter, laaaaangen Liste:

[RH 7/1690 -> Seite 1313]
n- 21.8.09 A.Pfd.laz. 572 bach 1202 Wagner Alois Gerchsheim 9.3.13 1203 Kissel Willi Brandenbg. 8.5.09 1204 Schwarz Xaver Unterhöh- 29.4.19 berg 1205 MEIER HANS Walledorf 14.8.00 Gefr. 1&@6xx$]ax§8xx063,2 §XJ .r S )ÖXXXI+ Korück 55o 1206 Glasser Friedrich Kandel 21.9.05 It.d.reldg. Standort.kdtr. Ssimfer
--------------------------------------------------------------------------------------------------------------------------
[RH 7/1690 -> Seite 1425]
mann Helmut Chemnitz 5O. 4.16 Hptw. Stabsbttr. II./A.R.6O 880v Baumann Harry Plaue 24. 7.19 Obfkm. 881 Braun HANS Winden 28. 5.21 Obg. 4./A.R. 60 882 MEIER Walter Zwickau 20. 2.17 5./ `i 885 Neumann Fritz Hurkingen 72. 5.13 îî 6./ 884 Müller Richard Glösa 19.11.07 *: Stabsbttr. II./A.R.6O 885 - Löbner Eb

Dazu zur Erlärung wie die Suche intern funktioniert.
Der erste Suchbegriff, nennen wir ihn Hauptbegriff ist "Meier". Damit suche ich mir aus der Datenbank alle Seiten heraus wo dieser Begriff vorkommt.
Nun reduziere ich den jeweiligen Ganzseiten-OCR-Text auf X Zeichen vor und nach dem Hauptbegriff (aktuell teste ich für X mit 150).
Und dann nehme ich diese reduzierten Texte und lasse darauf dann die Filter laufen. Hier im Beispiel "Hans".

Wie man sieht ist das 2. Ergebnis ein false positive, da hier Hans zu einer anderen Person gehört, Ich kann aber für eine Suche nicht nach dem Komplett-Text "Meier Hans" suchen, weil in den Listen es keine genormte Namensgebung gibt, dort ist alles vorhanden von

• "Meier, Hans"
• "Meier Hans"
• "Hans Meier"
• "Meier
  Hans" <-- neue Zeile
• und was weiß ich noch für merkwürdige Kombinationen, zumal es keine Garantie gibt das die OCR Erkennung irgendwelche wilden falschen Zeichen zwischen den Namen "entdeckt" und als OCR dann sowas in der DB steht: "Meier $Hans".

Hier wäre jetzt die Möglichkeit die Ergebnisreduzierung (X = 150 Zeichen) etwas anders zu gestalten. Sucht man beim Hauptbegriff nach einem Namen könnten man statt 150 Zeichen vor und danach es anders machen. Da der Name für gewöhnlich am Anfang einer Zeile steht, könnte man z.b. 30 Zeichen vor dem Namen und 150 Zeichen nach dem Namen inkludieren. Könnte die false positives etwas reduzieren. Sucht man beim Hauptbegriff dagegen nach einem Ort, der meist mittig in einer Zeile steht, bleibe es eher bei der Reduzierung von 150 Zeichen vor/nach dem gefunden Match.

In Ergebnis 1 sieht man übrigens auch das andere Ortproblem von dem ich schrieb, der Xaver Schwarz ist in Unterhöhberg geboren, aber der Ortsname ist in der zeilenweisen OCR auseinandergerissen, weil "berg" in einer anderen Zeile im Dokument steht. Wäre somit sehr schwer bis überhaupt nicht zu finden, wenn man nur eine Ortssuche macht.

Die Suchausgabe werde ich irgendwann erweitern, so das man z.b. optional nur eine Ausgabe der Signatur/Seiten enthält. Sprich, bei einer Suche nach Ort Beispieldorf könnte man die Ausgabe einfach stur so gestalten:
[RH 7/1690 -> Seite 123]
[RH 7/1690 -> Seite 1313]
[RH 7/1710 -> Seite 666]
[RH 7/1829 -> Seite 45]
Denn je nach Suche bekommt man hier ansonsten u.U. hunderte/Tausende von Ergebnisse und eine riesige Textwüste. Da man im beschi... Invenio System vom Bundearchiv aber nicht mal auf einen Dokumentenviewer verlinken, geschweige direkt eine Seite anspringen kann, wird eine Prüfung der Seite schnell sehr mühselig- je nachdem wieviel Suchergebnisse man erhält.

Das nur mal kurz zur Erklärung wie es um die Suchmöglichkeit aktuell geht, wenn es nur eine Ganzseiten-OCR gibt.

[Benjamin16]

Hallo sonki,

wirklich spektakulär was mittlerweile möglich ist und das du da so ein enormes Wissen in der Umsetzung hast!

Habe es jetzt aus deinen Beiträgen nicht rausgelesen, aber dein Schritt 6, die Datenbankabfrage mittels Python Skript, wird öffentlich sein oder analog der Vermisstenbilddatenbank über Einzelanfragen bei dir laufen?

Vielen Dank und LG
Benjamin

[sonki]

Habe es jetzt aus deinen Beiträgen nicht rausgelesen, aber dein Schritt 6, die Datenbankabfrage mittels Python Skript, wird öffentlich sein oder analog der Vermisstenbilddatenbank über Einzelanfragen bei dir laufen?

Es wird leider wieder wie bei den Vermisstbildlisten laufen - allein aus rechtlichen & Datenschutz Gründen setze ich damit keine öffentliche Webanwendung auf (müsste ich auch erst alles basteln). Zumal die Datenbank diesmal mehrere hundert MB groß werden wird, ich dafür extra ein Server anmieten müsste, eine Domain, dann Impressum mit meinem Namen/Anschrift. Hab mir einmal sowas mit einer Art öffentlichen Datenbank gegeben und nie wieder. Mir ist klar das es sicherlich für Anfragende nervig ist und ich halse mir damit ja auch Arbeit auf (wobei ja zum Glück das Interesse an der VBL stark abgeflaut ist), aber wie gesagt. Es ist nur ein fun-Projekt für mich. Vielleicht lade ich irgendwo die sqlite Datenbank hoch, aber das bringt auch nur denjenigen etwas die wissen wie man die dann abfragt...Ottonormalanwender wird damit nichts anfangen können.

Ach ja, ohne jetzt tiefstapeln zu wollen, großartiges Wissen ist für sowas absolut nicht erforderlich. All der Code ist wirklich sehr einfach, ich behaupte das könnte jeder Anfänger in kurzer Zeit zusammenbaseln - ist wirklich kein Hexenwerk. Klingt vielleicht manchmal so, aber glaube mir, die eigentliche Programmierung ging sehr schnell, zeitaufwändig ist hier nur das Downloaden der großen Datenmengen vom BA und die OCR-Erkennung, letzteres ist sehr langsam. All der andere Kram ist pillepalle...könnte man vermutlich chatgpt fragen und das leitet einen da Schritt-für-Schritt durch mit dem gleichen Ergebnis.

[sonki]

So, die Listen für das Kriegsverdienstkreuz sind alle durchgerechnet. Hat 8 Tage gedauert und das nur weil ich mein Rechner fast rund um die Uhr bei 100% CPU Auslastung laufen gelassen habe. Bei den EK-Listen werde ich das etwas ruhiger angehen, sonst schmort mir mein PC noch weg.

Bisschen Statistik: 667 Listen/Akten mit jeweils zwischen 30 und 10.000 Seiten. Insgesamt unter Abzug von leeren Seiten sind nun 228.711 Einzelseiten mit OCR erfasst. Grob 1/2 davon sind Namenslisten mit wiederum jeweils zwischen 1-30 Namen. Die sqlite3 Datenbank hat eine Größe von 230MB.

[Benjamin16]

Hallo sonki,

starke Leistung! Sprich jetzt darf man dich um eine Datenbankabfrage bitten? :-)

zB Franz Beier, *01.12.1912

Vielen Dank und LG,
Benjamin

[sonki]

HSprich jetzt darf man dich um eine Datenbankabfrage bitten? :-)

zB Franz Beier, *01.12.1912n

Also theoretisch ja, auch wenn bisher nur die Kriegsverdienstkreuze in der DB sind. Aber wie gesagt, bei der Suche hier hängt quasi alles davon ab ob der Name oder das Geburtsdatum exakt korrekt durch die OCR Erkennung erfasst wird. Falls nicht, werde ich schnell an die Grenzen kommen bzw. halt nix finden.

Franz Beier mit diesem Geburtsdatum nicht gefunden. Auch nicht mit Kombinationen von nur (Vorn)Name + Teile des Geburtsdatum. Auch würde ich empfehlen bei Suchanfragen den Geburtsort mit anzugeben. So gibt es mehr Möglichkeiten Erfolg zu haben bei der Suche...solange wir hier nicht über Großstädte reden.

Ansonsten bin ich immer noch dabei am Suchscript zu arbeiten um mehr Chancen zu haben etwas zu finden. aber wie gesagt, hier steht und fällt alles mit der exakten OCR-Erkennung. Eine Suche nach ähnlichen Namen wie bei den Vermisstbildlisten (wo ich oft nur so den Eintrag finden konnte, ist hier vorerst nicht möglich).

[Visitor]

Hallo Sonki,

dann würde ich gerne mal von Deinem Angebot gebrauch machen, in der Hoffnung, dass sich was findet.

Wenn es für Dich OK wäre, könntest Du bitte mal nach dem Ort Heckendalheim filtern auch in diesen Schreibweisen in den Listen schon gesehen

Heckendalheim, Heckendahlheim, Heckendal- in neuer Zeile heim, Heckendahl- in neuer Zeile heim

Des weiteren suche ich nach:

Wachs Alfons 19.12.1910 St. Ingbert
Betz Rudolf 26.11.1910 St. Ingbert
Betz Josef 27.03.1912 St. Ingbert
Betz Hans 30.10.1913 St. Ingbert
Cebulla Paul 03.12.1913 Brösen/Danzig
Dietrich Alois 27.09.1911 Bildstock
Schild Ewald 11.11.1907 Bliesmengen-Bolchen
Stauner Ferdinand 10.02.1916 St. Ingbert
Lösch Peter 16.08.1910 St. Ingbert

Vielen vielen Dank schon mal im Voraus.

Gruß
Dominik

[sonki]

Wenn es für Dich OK wäre, könntest Du bitte mal nach dem Ort Heckendalheim filtern auch in diesen Schreibweisen in den Listen schon gesehen

Heckendalheim, Heckendahlheim, Heckendal- in neuer Zeile heim, Heckendahl- in neuer Zeile heim

Erstmal noch kein Treffer für die einzelnen Namen...wie gesagt, hab nur das Kriegsverdienstkreuz in der DB, das EK stewt noch aus.

Hier mal die Treffer für Heckendalheim (in den Kombinationen):

Hinweis - ich muss die Ausgabe erst noch optimieren - kam ich heute noch nicht dazu (gibt ja derzeit Wichtigeres in Dtl. - auch wenn es zum Gruseln ist).
Erstmal hier als raw-results - irgendwann auch schöner, color-kodiert und/oder als .txt...

[RH 7/1212 -> Seite 488]
fr. 552 Bell August Nister 26.7.22 Gefr. 555 Hoffmann Erwin HECKENDALheim 12.1.19 O.Gefr. 554 Ehrlich Werner Aachen 21.1.14 Oberarztst. /S w.Btl.5 555 Brehm Friedr. Stuttgart 5o.6.o7 Irg-le
--------------------------------------------------------------------------------------------------------------------------
[RH 7/1226 -> Seite 380]
ritz Kalkofen 26.12. Obergefr. 9./ 191o 64 Tickigger August HECKENDAL= 24.11. Obergeîr. 12./ heim 1911 65 Selle Paul Rettwitz 5o. 8. Obergeîr- 9./ i925 66 Regenauer Ernst Otterstädt 5ligli
--------------------------------------------------------------------------------------------------------------------------
[RH 7/1277 -> Seite 717]
ITI./G.R.4O6 Konrad Wiliy Spremberg 15.5.11 Fickinger Josef HECKENDALheim -20.5.19 - Io Tschersich Martin Zirlau 50.4.08 f? I7 Schnabel Paul Breslau 16.12.15 72 Bränzel Erich Tradow 15-9.11
--------------------------------------------------------------------------------------------------------------------------
[RH 7/1399 -> Seite 81]
N Heinz Hamburg 18.4.11 Wachtm Stab/t.ß.575 HOFMANV Otto HECKENDAL- 12.7.o9 Geîr. heim 81 ROTTTENSTEINER Ludwig Graienbach 2.8.o9 Gefr. 82 MARGINOWSKI Johann Wien 16.8.13 Uîîz- Stabsbttr
--------------------------------------------------------------------------------------------------------------------------
[RH 7/1473 -> Seite 338]
64 Holmer Alfons Hirlbach 23. 3.13 OFldw.'3./ 65 S+olz O++o HECKENDAL_ 5.3.09 K.v.J.vs+b. heim 66 Wogner Josef Rängschnai+s 2.3.19 OGefr. t 67 Herauf Johenn Landeu 9.8.18 68 - _ Generolmojo
--------------------------------------------------------------------------------------------------------------------------
[RH 7/1483 -> Seite 201]
fr. 271 Grau Emil Eicha 24. 6.18 O-Gefr. 272 Stolz Heinrich HECKENDAL- 21. +.2o O-Gefr° heim 273 Küpper Joseî Vlatten 8.12,22 Gefr. 274 Harms Tritz Westerscheps 14. 6.22 Gefr° /1 275 Buntz
--------------------------------------------------------------------------------------------------------------------------
[RH 7/1588 -> Seite 703]
g 2.11.15 wachtm. 4./Pz-korps- nachr-äbt.424 24 Mieger mgen HECKENDAL- 27.9.17 St.Gefr. heim 25 Jungmann Albert Mannh ieim 18.4.00 V.GeÎr. 26 Stahl Heinrich Kaisers- 15.5.o9 lautern
--------------------------------------------------------------------------------------------------------------------------
[RH 7/1633 -> Seite 89]
Franz Novy~swiat 2o.8.o1 Gefr. Welungen 21o Deutsch Hermann HECKENDAL- 7.3.o6 UÎÎZ. 1./lds.5chtz. heim Bt1.823 211 Rupert Franz Jechnitz 9.11.05 UfÎz. 212 Lauber Anton Chodau 11.9.06 UÎÎZ.
--------------------------------------------------------------------------------------------------------------------------
[RH 7/1715 -> Seite 110]
u.e.hz.(mot)2 KVK 2.kl.m.schw. 30. 1.43 86.) Mohr Willibald HECKENDALheim 10. 9.20 UfÎZ. 3.Pernspr.ïn- KVK 2.K1.m.Schw. standh.kp. 18. 9.41 (mot)/65i Ostmedaille 27. 8.42 87.) Kohlmann Alfo


[RH 7/1277 -> Seite 373]
9./5ich. St.oskerode 1905 Regt.601 Allensteid Fuchs Johann HECKENDAHL- 19.2.äauptfeld- 10./sich. heim 1895 |webel Regt.601 6 Schmitz Albert Hagen 1.5. Stabsfeld- .1905 webel 7 Prangenberg l
--------------------------------------------------------------------------------------------------------------------------
[RH 7/1678 -> Seite 4340]
berbrechen 5. 0*Gefr),kîz,inst. sgor Kp- 188 8 Hartz Gustav HECKENDAHL- 4.10. heim 1919l 9 Röske Walter Holzermühle 8.11.Kriegs~i Kîz.Inste Krs.Bromberg 1909| hilîs- Kp. 197 werkmstre 10 Ste
--------------------------------------------------------------------------------------------------------------------------
[RH 7/1724 -> Seite 470]
. Feldwebel Frontleit= tern 1897 stelle 72 525 Mieger |Otto HECKENDAHL~ 1.5. Unterofîi- Frontleit- heim 1916 zien U stelle 72 524 Kissling Hermann Holzhausen 15.9. Hauptmann 1./Genes. 1891 d

[Stefan86]

Hallo Sonki,

könntest Du für mich bitte einmal nach meinem Urgroßonkel

Fritz Melzer, geboren am 08.08.1906 in Lauta bei Marienberg

schauen?

Er war zuletzt Spieß im Brückenbau-Bataillon 208.
Lieben Dank!

Viele Grüße

Stefan