synOCR synOCR - Aufbau einer YAML Datei - Verwendung Regulärer Ausdrücke

[Struppix]

Liebes Forum und Freunde von synOCR,

in diesem Thread möchten wir Euch die Möglichkeit bieten, den Aufbau der YAML Datei und die Verwendung Regulärer Ausdrücke zu diskutieren.

Da wir selbst keine Experten in Regulären Ausdrücken sind, würden wir uns freuen, wenn Ihr Euch rege an der Diskussion beteiligt.

Leider findet man auf der Suche nach Regulären Ausdrücken kaum Praxis relevante Beispiele. Diese sind meist abstrakt und bieten keine wirkliche Hilfestellung.

Deshalb haben wir hierzu unser

synOCR - wiki - Aufbau einer YAML Datei - Verwendung Regulärer Ausdrücke

in den letzten Tagen kräftig überarbeitet.

Hier findet ihr einige konkrete Beispiele zur Verwendung, die ich selbst erstellt habe und in meiner eigenen YAML Datei verwende. Da ich mich selbst erst seit etwa sechs Wochen mit Regulären Ausdrücken beschäftige, würde ich mich über Kritiken, Verbesserungsvorschläge, Korrekturen und natürlich Eure Ideen und Regeln freuen.

Gruß Karsten

 

[geimist]

Vielen Dank an Karsten alias @Struppix, der sich die Mühe gemacht hat, so viele Beispiele exemplarisch zu beschreiben.

Es gibt ja immer wieder mal Fragen von Usern, wie die eigenen Bedürfnisse in Regeln auszudrücken sind - dieser Thread soll auch dafür die passende Plattform bieten.

 

[adallmo]

Hallo,

wie gewünscht meine Frage nochmal in diesem Pfad:

ich brauche nochmal Eure Hilfe:

Die ärztlichen Befunde von meiner Frau und mir sollen getrennt in einen Ordner "Gesundheit" abgelegt werden. Der Name muss also immer als searchstring enthalten sein, verschiedene andere Begriffe wie "Befund", "Labor" oder "Vorsorge" sollen nur jeweils in Kombination mit dem Namen die Zuordnung auslösen. Dieser Fall ist mit condition all, any, oder none nicht abzubilden.

Muss für jeden Begriff eine eigene Regel erstellt werden oder git es eine YAML-Regel, die diese Bedingungen erfüllt? Ein searchstring aus Begriff (Befund, Labor,..) und Name funktioniert leider nicht, vermutlich weil Begriff und Name nicht in einer Zeile stehen.

Sorry, ich habe einen Knoten im Hirn.

Danke, schöne Grüße

Ansgar

 

[Struppix]

Eigene Unterordner für jeden Ehepartner machen das gesamte Archiv meiner Meinung nach übersichtlicher, das gilt nicht nur für ärztliche Befunde.
Außerdem kann ich mir nicht vorstellen, dass sowas nicht möglich ist. Nachdem die Archivierung dank der Hilfe aus dem Forum grundsätzlich schon gut funktioniert, möchte ich noch weiteres finetuning machen.

Hi adallmo,

macht Sinn. Aber es gibt mehrere Möglichkeiten. Leider kenne ich das Layout nicht, da es meistens immer unterschiedlich ist.

rule_600:
    tagname: Vorname Nachname
    targetfolder: /volume1/Gesundheit/.../Frau
    condition: all
    subrules:
    - searchstring: Vorname Nachname
      searchtyp: is
    - searchstring: (?i)(Befund|Labor|Vorsorge)
      searchtyp: contains
      isRegEx: true
    - searchstring: Herr Nachname
      searchtyp: is not
rule_601:
    tagname: Vorname Nachname
    targetfolder: /volume1/Gesundheit/.../Mann
    condition: all
    subrules:
    - searchstring: Vorname Nachname
      searchtyp: is
    - searchstring: (?i)(Befund|Labor|Vorsorge)
      searchtyp: contains
      isRegEx: true
    - searchstring: Frau Nachname
      searchtyp: is not
rule_602:
    tagname: Befund
    condition: all
    subrules:
    - searchstring: (?i)(Vorname Nachname|Vorname Nachname)
      searchtyp: is
      isRegEx: true
    - searchstring: Befund
      searchtyp: contains
rule_604:
    tagname: Labor
    condition: all
    subrules:
    - searchstring: (?i)(Vorname Nachname|Vorname Nachname)
      searchtyp: is
      isRegEx: true
    - searchstring: Labor
      searchtyp: contains
rule_604:
    tagname: Vorsorge
    condition: all
    subrules:
    - searchstring: (?i)(Vorname Nachname|Vorname Nachname)
      searchtyp: is
      isRegEx: true
    - searchstring: Vorsorge
      searchtyp: contains

Schau mal ob es so passt.

Gruß Karsten

 

[Yippie]

Bei Rule 600 und 601 ist der dritte Searchstring möglicherweise vertauscht, wenn man daas jeweilige Ziel Verzeichnis betrachtet, oder?
Bspw 600, Ziel-Vz Frau aber Searchstring Herr Nachname

Wollte es zur Sicherheit erwähnt haben...

 

[Struppix]

Hi Yippie,
das war gewollt von mir. Also wirklich zb. Herr oder Frau Ludwig rein schreiben. Dies dient dazu, das wenn auf dem Dokument mal der Vorname fehlt, es trotzdem richtig zugeordnet werden kann. Eigentlich müsste es mit dem Namen und dem searchtyp is schon eindeutig sein. Aber sicher ist sicher.

Gruß Karsten

 

[Yippie]

Aha, ja, sorry die Bedingung steht auf is not, hab ich leider überlesen.

 

[adallmo]

Hallo Struppix,

vielen Dank für deine Arbeit und den Code! Probiere ich nachher aus...

Zum Verständnis:

- rule 600/6001 machen die Ablage in den jeweiligen Namensordner und setzen einen tag mit dem "Vornamen Namen", sobald eines der Begriffe "Befund", "Labor" und "Vorsorge" gefunden wird?
- rule 602/603/604 setzen nur noch einen zusätzlichen tag mit dem jeweiligen Begriff?

Schöne Grüße

Ansgar

 

[Struppix]

Richtig, die Benennung sollte in der Reihenfolge erfolgen, je nach Vorkommen.

 

[Yippie]

Aber Achtung, jede Rule wird geprüft und ggf. jeweils angewendet!

Also von Regel 600 bis 604, egal ob bereits bei 600 ein Treffer vorlag. Dies bedeutet im schlechtesten Fall, dass bspw. auch die Rule 604 zusätzlich Anwendung findet, wenn dort alle Bedingungen, insbesondere der Text "Vorsorge" vorkommt.

Dieser Umstand ist leider aktuell gegeben und man kann in einer Regel bisher noch keinen Abbruch bei Treffer definieren. Ja, ich weiß ich wiederhole mich mit dieser Forderung, aber vielleicht erfüllt sich mein Wunsch ja doch noch irgendwann, gell

 

[Struppix]

Das stimmt leider. Nun ich dachte es war sein Ziel, wenn mehrere der Suchbegriffe gefunden werden, dass die in Benennung einfließen sollen.

Man Könnte rule 602-604 auf eine reduzieren, indem man das für 602 nimmt.

rule_602:    
    tagname: §tagname_RegEx
    tagname_RegEx: (?:\b(befund|labor|vorsorge)\b)
    condition: all
    subrules:
    - searchstring: (?i)(Vorname Nachname|Vorname Nachname)
      searchtyp: is
      isRegEx: true

Dann wird nur ein Begriff in Namen übernommen.
Wichtig: Durch die Wort Begrenzung werden nur exakte Übereinstimmungen gefunden, also nicht Laborbefund.
Ausserdem greift immer NUR der erste Match, auch wenn 2 gesuchte Wörter vorkommen.

- rule 602/603/604 setzen nur noch einen zusätzlichen tag mit dem jeweiligen Begriff?

Ansgar, ich sehe gerade, ich habe aus versehen die Nummer 604 2x drin !!!

Gruß Karsten[/CODE]

 

[adallmo]

Und wenn ich den Code so lasse, wie er zuerst gepostet wurde, dann kommt es schlechtestenfalls zu überlangen Dateinamen, falls mehrere Begriffe gefunden werden? Wird dann auch der Befund in Röntgenbefund gefunden?

 

[Struppix]

Wird dann auch der Befund in Röntgenbefund gefunden?

Richtig. Und ja sollten die Worte auch in zusammengesetzten Wörtern gefunden werden. Möchtest Du das nicht, dann diese Bedingungen mittels searchtyp von contains in is ändern.
Einfach mal testen. Das kommt ein wenig auf die Dokumente an.

Gruß Karsten

 

[adallmo]

Hallo Karsten,

der code macht, was er soll

Klasse, vielen Dank!

Beste Grüße

Ansgar

 

[Struppix]

Das freut mich.

Gruß Karsten

 

[Struppix]

Hallo erd,

Ziel ist es, über RegEx den gesamten Betreff (als Tag) des Dokuments zu ermitteln.

Dies sehr allgemein zu definieren, ist sicher kaum möglich (also für alle Art Anschreiben).

um das besser einzugrenzen, benötige ich ein paar Beispiele, wenn das Folgende ...

Aber für bestimmte Dokumente kann ich bestimmte Muster erkennen, z.B. dass auf der vorherigen Zeile die Kundennummer (eine ganz konkrete) genannt ist und nach dem Betreff der Brief mit "Sehr geehrter Herr ..." beginnt.

Viele Grüße, erd

nicht ausreichend sein sollte.

Man kann eine Suche zB.:

1. in der Suchzeile selbst mittels bekanntem Suchwort
2. vor einem Suchwort
3. hinter einem Suchwort
4. oder zwischen Suchwörtern realisieren

Das ganze hat nun Vor- und Nachteile:

• Das Layout des Suchstrings ist entscheidend. Geht es zB. über mehrere Zeilen
• benötigen wir multilineregex, welches es derzeit nur in der Beta von synOCR gibt
• und die Ausgabe von grep (wird zur Suche in synOCR verwendet), doch oft unterschiedlich zu den bekannten RegEx Testern ist.
• synoOCR gibt derzeit immer nur die erste Zeile eines Treffers aus !!! Das bedeutet jedoch nicht, dass bei mehreren Treffern nur ein match ausgegeben wird.

Hier das Beispiel Deiner Vorlage etwas modifiziert:

Bei Kontakt bitte nennen
Versichertennr.: X123 456 789
Der Betreff dieses Briefes
ist dieses Anliegen
Sehr geehrter Herr

Zu 1)
Hier wäre zb. das Wort "betreff" ein gutes Schlüsselwort zur Suche.
Nachteil: nur einzeilige Suche bei unbekanntem Layout
Vorteil: Hier reicht die Stable von synOCR

Die Regel:

rule_999:
    tagname: §tagname_RegEx
    tagname_RegEx: (?i)(.*betreff(\s+\S+)*)
    condition: all
    subrules:
    - searchstring: (.*betreff(\s+\S+)*)
      searchtyp: is
      isRegEx: true
      source: content
      casesensitive: false

Ausgabe: Der Betreff dieses Briefes

Zu 2,3)
Da das Layout unbekannt würde ich dies nicht empfehlen, es sei denn Du kannst sicher gehen, dass wir nur in in einer fest definierten Anzahl von Zeilen suchen.
Nachteil: Beta erforderlich, nicht wirklich ein Nachteil // eine mehrzeilige Ausgabe eines matches ist derzeit unter synOCR nicht möglich
Vorteil: bekanntes Suchwort im Suchstring nicht erforderlich

Ein Beispiel für nur einer Zeile wäre:

rule_999:
    tagname: §tagname_RegEx
    tagname_RegEx: (?i)(?<=(Versichertennr\.[\:] X123 456 789)\n)(?:.+betreff(\s\S+)*)
    multilineregex: true
    condition: all
    subrules:
    - searchstring: (?<=(Versichertennr\.[\:] X123 456 789)\n)(?:.+betreff(\s\S+)*)
      searchtyp: is
      isRegEx: true
      multilineregex: true
      source: content
      casesensitive: false

Ausgabe: Der Betreff dieses Briefes

Zu 4)
Dies ist sicherlich die eleganteste Variante, da das Suchmuster bzw. Layout unerheblich ist..
Nachteil: Beta erforderlich, nicht wirklich ein Nachteil // eine mehrzeilige Ausgabe eines matches ist derzeit unter synOCR nicht möglich
Vorteil: bekanntes Suchwort im Suchstring nicht erforderlich, Suche komplett zwischen zwei Suchwörtern/-strings

Beispiel:

rule_999:
    tagname: §tagname_RegEx
    tagname_RegEx: (?i)(?<=(Versichertennr\.[\:] X123 456 789)\n)(?:\r\n|\r|\n|.)*(?=\n(Sehr geehrter Herr))
    multilineregex: true
    condition: all
    subrules:
    - searchstring: (?<=(Versichertennr\.[\:] X123 456 789)\n)(?:\r\n|\r|\n|.)*(?=\n(Sehr geehrter Herr))
      searchtyp: is
      isRegEx: true
      multilineregex: true
      source: content
      casesensitive: false

Ausgabe: Der Betreff dieses Briefes

Hinweis: Die Ausgabe des matches wäre eigentlich:

Der Betreff dieses Briefes
ist dieses Anliegen

Ich hoffe das hilft ein wenig weiter.

Gruß Karsten

 

[erd]

Hi Karsten, überragend !! Danke dir für die schnelle und umfangreiche Rückmeldung!

Ich habe es gerade mal getestet für den Fall / das Beispiel (4):
Als Dateinamen kommt bei mir gerade folgendes heraus: 2022-12-23 - §tagname_RegEx.pdf

Offenbar hat er etwas passendes im Dokument gefunden. Jedoch wird der Tag falsch benannt.
Das habe ich in der Regeldatei eingetragen:


Hast du eventuell eine Idee für das Verhalten?

PS: Wie du schon geschrieben hattest, ist für den Weg (4) die Beta notwendig. Ich habe derzeit eine Beta installiert (1.3.99.9). Aber wie ich hier lese, ist für multilineregex die Version 1.4.0 notwendig. Gibt es die Beta 1.4.0.

 

[geimist]

Die Version 1.3.99.9 gehört zur Beta, die fertig in der Version 1.4.0 mündet.

 

[Struppix]

Hast du eventuell eine Idee für das Verhalten?

Hallo erd,
ja das das ist schon nervig. Diese Ausgabe kommt öfter als gewollt

Die Ursache kann vielfältig sein. In Deinem Fall vermute ich mal, dass Dein ursprüngliches Beispiel nicht korrekt war, und die Schreibweise dann doch vielleicht so vorkommt.

Bei Kontakt bitte nennen
Versichertennr.: X123 456 789

Der Betreff dieses Briefes
ist dieses Anliegen

Sehr geehrter Herr

Wenn dem nicht so ist dann schicke ich Dir einen Upload-link. Da müsste ich mal genauer schauen...

Ist dem so dann versuche mal das:

rule_999:
    tagname: §tagname_RegEx
    tagname_RegEx: (?i)((?<=(Versichertennr\.[\:] X123 456 789))\r\n|.*)(?:\R.+)(?=\n*(Sehr geehrter Herr))
    multilineregex: true
    condition: all
    subrules:
    - searchstring: ((?<=(Versichertennr\.[\:] X123 456 789))\r\n|.*)(?:\R.+)(?=\n*(Sehr geehrter Herr))
      searchtyp: is
      isRegEx: true
      multilineregex: true
      source: content
      casesensitive: false

Zur Erklärung: Der Fehler entsteht bei meiner Annahme durch den vorangehenden "Zeilenvorschub" im Match.

Gruß Karsten

 

[erd]

Hi Karsten,

Ich habs mit deinem neuen Code-Beispiel versucht und diesmal wird kein Tag zurückgegeben. Jedenfalls wird diesmal die Datei nicht so komisch benannt.

Wenn ich in dem PDF (mit OCR) alles markiere und in ein Notepad kopiere, erhalte ich folgenden plain Text (also nur ein Ausschnitt):

...
12. Dezember 2022
Bei Kontakt bitte nennen
Versichertennr.: X123 456 789
Ihr Beitrag zur Kranken- und Pflegeversicherung
Guten Tag, Herr Mustermann,
vielen Dank für Ihr Vertrauen. ...

Ich würde gern selbst etwas mit RegEx hin und her probieren (bin kein Experte).

• Aber immer das komplette Dokument verarbeiten zu lassen für eine kleine Änderung dauert immer etwas lange.
• https://regex101.com/ funktioniert ja mit deinen beiden Vorschlägen oben, repräsentiert jedoch nicht das wirkliche Verhalten von synOCR.
• Gibt es noch eine andere Möglichkeit, wo ich schnell und repräsentativ die RegEx testen kann?

Grüße, erd