Über den Stand der Dinge in Richtung Texterkennung. Am Ende gibt es einen Aufruf zur Mithilfe. Also dranbleiben!

Unter den Dokumenten, die Offenes Köln mittels Volltextsuche zugreifbar machen will, befinden sich auch zahlreiche eingescannte Textdokumente. Diese wurden also zunächst ausgedruckt und dann eingescannt, bevor sie als Anlage zu einem Antrag oder einer Vorlage in das Ratsinformationssystem eingestellt wurden (Beispiel).

In den meisten Fällen enthalten diese Dokumente keine für die Suche verwertbaren Textinformationen. Ausnahmen sind die wenigen Fälle (Beispiel), in denen vermutlich vor dem Hochladen das Dokuments mit der Funktion “Paper Catpure” von Adobe Acrobat verarbeitet wurde. Dabei handelt es sich um eine OCR-Software (Optical Character Recognition), also eine Texterkennung.

Gestern ist die Wahrscheinlichkeit, dass gescannte Dokumente bald zumindest zum großen Teil mittels OCR-Software verarbeitet und damit ihre Inhalte für die Suche verwertbar werden können, ziemlich gestiegen. Den Anstoß gab ein Issue-Eintrag von michamilz auf Github. Michael arbeitet daran, den RIS-Scraper für das Schweriner Ratsinformationssystem anzupassen.

Vor mehreren Wochen hatte ich mich schon mal – offenbar eher halbherzig – auf die Suche nach Open Source OCR-Software gemacht. Damals war ich auf ocropus und Tesseract OCR gestoßen. Mein Eindruck war jedoch, dass diese nicht ohne weiteres “Out of the Box” einsetzbar wären, sondern erst mal auf die Erkennung der gewünschten Schriften (z.B. Arial, Times New Roman) und die Sprache der Dokumente trainiert werden müssten. Aber sowohl michamilz als auch weitere Tipp-Geber auf Google Plus brachten Tesseract wieder ins Spiel, also musste ich mich damit mal näher beschäftigen. Denn anders, als ich bei meiner ersten Recherche angenommen hatte, gibt es Tesseract mit Trainingsdaten für die Deutsche Sprache. Damit sollte es also in gewissem Rahmen direkt einsetzbar sein.

Nach vergeblichen Versuchen erst auf Mac OS X, dann auf dem Produktions-Server von offeneskoeln.de (Debian lenny) ist es mir schließlich gelungen, Tesseract zu kompilieren, und zwar auf einem frisch aufgesetzten Ubuntu 11 64bit mittels Virtual Box. Geholfen hat dabei ein ziemlich versteckter Kommentar, auf dieser Seite fast ganz unten. Mit den Quellen aus SVN ließ sich Tesseract dann sogar auf Mac OS X builden.

Das Ergebnis

Die ersten sechs Ergebnisse habe ich in einem Gist auf Github abgelegt. Die Dateinamen, wie z.B. 292011.txt, stehen für die Dateien, von denen die Texte stammen. Hier zwei Beispiele im Vergleich:

• 292011: Original / OCR-Text
• 344624: Original / OCR-Text

Mein Eindruck: Besser als nichts. Aber es gibt definitiv noch Raum für Verbesserungen.

Um herauszufinden, ob man mit anderen OCR-Softwares oder mit anderen Einstellungen bessere Ergebnisse erzielen kann, benötigt man eine Referenz zum Vergleich, also den tatsächlichen Text wie man ihn im Idealfall aus dem Dokument extrahieren möchte. Für zwei Dokumente haben wir einen solchen Referenztext. Ein Dokument habe ich abgetippt, ein anderes hat freundlicherweise Claas Hanken beigesteuert.

So lässt sich nun das “ideale” Referenzdokument mit dem OCR-Resultat vergleichen, zum Beispiel indem man die Levenshtein-Distanz zwischen beiden Texten ermittelt. Das ist die Zahl der Änderungsschritte, die nötig ist, um von dem einen Text zum anderen zu kommen. Mit anderen Worten: Sie gibt die Zahl der Fehler wieder, die die OCR-Software bei der Erfassung macht. Ein Script dafür liegt unter dem Namen differenz.py im Github-Repository. Die Werte für die beiden Texte sehen so aus:

• 292011: 224 von 1108 Zeichen (20,2%)
• 344624: 452 von 1655 Zeichen (27,3%)

Je kleiner der Wert, desto näher ist das OCR-Resultat am idealen Ergebnis. Eine Abweichung von 20 Prozent bedeutet im Umkehrschluss, dass das Dokument zu 80% richtig erfasst wurde.

Dazu muss man anmerken, dass diese Metrik nun die Übereinstimmung auf Zeichenebene, also Buchstabe für Buchstabe, wiedergibt. In der Praxis sind viele der Wörter gar nicht relevant, denn die meisten häufig auftretende Wörter wie “sehr”, “sie”, “haben”, “bitten”, “der”, “die”, “das” sind sogenannte Stoppwörter und werden bei der Suche nicht berücksichtigt. Interessanter wäre daher eine Betrachtung der Übereinstimmung nach Herausfiltern der Stoppwörter.

Nichts desto trotz sieht es so aus, als kämen wir der Suche über gescannte Dokumente einen großen Schritt näher.

Ein Aufruf zur Unterstützung

Ich werde hin und wieder gefragt, ob auch Menschen, die keine Programmierer sind, bei Offenes Köln mithelfen können. Hier ist eine fantastische Gelegenheit. Wir benötigen mehr Referenz-Dokumente, um bei Veränderungen an den Einstellungen der OCR-Software bemessen zu können, ob das Ergebnis dadurch besser oder schlechter wird. Was Ihr konkret tun könnt:

1. Sucht Euch gescannte Anhänge. Ich habe in einem Kommentar bereits eine Handvoll URLs gesammelt. Zwei davon (292011 und 344624) sind ja auch schon transkribiert. Ihr erkennt solche Dokumente auf der Detailseite daran, dass unter den Vorschaubildern kein Text angezeigt wird (Beispiel). Ihr könnt dafür einfach die Suche ohne Suchbegriff benutzen oder alternativ diese Seite.
2. Tippt den Text ab. Am besten genau so, wie es in der Vorlage geschrieben ist. Gestalterische Details wie z.B. die Einrückungen einer Liste oder mehrspaltigen Text solltet Ihr dabei nicht nachahmen. Den Zeilenumbruch mit Silbentrennung jedoch bitte ansonsten so beibehalten wie im Original.
3. Veröffentlicht das Ergebnis hier als Kommentar zu diesem Blog-Post. Falls mehrere Leute helfen, kann so doppelte Arbeit vermieden werden.

Vielen Dank schon mal an alle, die das Projekt in dieser Form unterstützen, und besonders an Claas Hanken, der unaufgefordert das erste Transkript beigesteuert hat!