Das ideale Genealogieprogramm
Vorbemerkung: Dieser Beitrag war ursprünglich für die Mailingliste „Genealogie-Programme“ bestimmt und ist hier um eine genauere Fehlerbeschreibung eines Export-Problems von GFAhnen ergänzt. Eine in anderer Weise ergänzte und für den Druck auch sprachlich überarbeitete Fassung erscheint demnächst in der Zeitschrift „Computer-Genealogie“.
Jeder Familienforscher kennt die Frage nach dem für seine Zwecke am besten geeigneten Genealogieprogramm – eine Frage, auf die es keine letztgültige Antwort gibt, sondern die sich in gewissen Abständen immer wieder neu stellt. Im Februar stellte sich mir aus verschiedenen Gründen diese Frage erneut, so dass ich nach Ratschlägen gesucht habe, welches Programm meinen Vorstellungen wohl möglichst nahe kommt. Neben den Antworten hat jemand angemerkt, ich solle auch bitte am Ende meine Entscheidung mitteilen. Dem komme ich gerne nach.
Zum Hintergrund: Seit über 10 Jahren benutze ich GFAhnen, ein Programm, das viele Stärken hat:
- eine sehr gut strukturierte und klare Benutzeroberfläche
- durch Datenbanken im Hintergrund die Möglichkeit zu differenzierten Statistiken (Berufe, Todesursachen, Namen …)
- eine sehr gute Berechnung von Kekulenummern [und zwar echt gut: klaglos wurde berechnet, dass Karl der Große, gerechnet von meinem Sohn, 10.000 verschiedene Kekulenummern hat]
- alle notwendigen Reports im rtf-Format
- Voreinstellungen, dass etwa Geburtsorte von Geschwistern automatisch bei der Neuanlage von Personen übernommen werden; eine klare Arbeitserleichterung.
In einigen Punkten hat GFAhnen mich aber dauerhaft nicht zufriedengestellt:
- Das betrifft die mangelnde Fähigkeit, fremdsprachige Sonderzeichen darzustellen, was bei Forschung in Böhmen ein Manko ist.
- Daneben bin ich nie glücklich geworden mit der Quellenverwaltung von GFAhnen (hier muss man immer sehr lange Text-Strings erzeugen, in denen die Detailsangaben „codiert“ sind, ohne dass man Leerzeichen verwenden kann [und zwischen „S.“ und die Seitenzahl gehört nun mal ein Leerzeichen]).
- In den Reports eine aus geisteswissenschaftlicher Sicht komische Verwendung von Fußnoten: Wenn etwa Fußnote 127 inhaltsgleich ist mit Fußnote 3, dann folgt auf Fußnote 126 im Text die Fußnotenziffer 3. Völlig absurd. Ich weiß, dass es Nutzer gibt, die sagen dazu: „It’s not a bug, it’s a feature.“ In den Geschichtswissenschaften ist eine solche Fußnotennumerierung wenigstens nicht üblich.
- Die Datenbanken zu Lebensphasen etc. sind einerseits praktisch, aber auch eine erhebliche Einschränkung, sobald man „nicht genormte“ Angaben hat; etwa Todesursachen, wie sie im Kirchenbuch stehen. Da wird dann für jedes lateinische Zitat ein Eintrag in der Lebensphasendatenbank gemacht, und dann kommt dieses dämliche Zitat jedes Mal, wenn man den passenden Anfangsbuchstaben eingibt. Auch gibt es Probleme bei „Kombinationsberufen“ („Bürger und Sattler“), die bei der Eingabe oft Zicken machen.
- Programmabstürze, wenn man viele in Folge Daten eingibt, wenn man eine neue Ehe anlegt. Hinweise dazu schon vor Jahren sind nicht weiter verfolgt worden.
- Probleme bei der Neuanlage von Personen, wo Teile der Daten der zuletzt geöffneten Person übernommen werden, auch dann, wenn voreingestellt ist, dass unverknüpfte Personen ohne jede Übernahme angelegt werden sollen.
- Fehlerkorrekturen sind nur im Jahresrhythmus möglich; zusätzlich bin ich mir arg unsicher, ob es noch allzu viele Updates / neue Versionen geben wird.
- Keine Verwaltung von DNA-Daten (wobei GFAhnen vor vielen Jahren da mal Vorreiter war).
- Zuletzt wurde mir deutlich, dass der Export zumindest von „Lebensphasen“ (gedcom: EVEN) fehlerhaft ist. Eine Abhilfe ist hier vorläufig nicht zu erwarten, da die Version 18 gerade fertiggestellt ist. Eine ausführliche Fehlerbeschreibung folgt am Ende dieses Beitrags.
- Ein weiterer Fehler betrifft den Export von Text in Verbindung mit Quellenangaben: Wenn in einem Textfeld mehrere Textabschnitte mit Quellenangaben erfasst sind, dann wird der zweite Textabschnitt in Gedcom nicht als NOTE codiert, sondern falsch noch der ersten Quellenangabe zugeordnet (als SOUR und CONT). Texte, die einer Person zugeordnet sind, erscheinen daher nach dem Ex- und Import in der Quellenverwaltung.
Dies sind also die Gründe, warum ich nach einer Alternative zu GFAhnen gesucht habe. TNG habe ich sofort in die engere Wahl gezogen, weil ich auf jeden Fall meine Genealogie (auch) online präsentieren möchte, ohne sie bei Familysearch oder den großen Datenkraken einstellen zu müssen. Meine Frage war also konkreter: Was soll das „Hauptprogramm“ sein – entweder direkt TNG oder ein anderes Desktopprogramm, das mit TNG möglichst gut harmoniert.
Letztendlich ist meine Wahl auf TNG als Hauptprogramm und Gen_Pluswin als Nebenprogramm gefallen. Warum TNG als Hauptprogramm und nicht ein Desktopprogramm? An TNG überzeugt mich:
- Die Flexibilität. Über MODs oder individuelle Änderungen in den PHP-Dateien ist das Programm sehr flexibel und anpassbar.
- Es gibt eine nicht perfekte, aber für yDNA und mtDNA doch sehr gute DNA-Verwaltung (atDNA geht auch, hier wären noch Optimierungen drin).
- Unterstützung aller Zeichen.
- Eine gut strukturierte Quellenverwaltung, die viel klarer ist als von GFAhnen (in der Ausgabe ebenfalls über MODs differenziert auszugestalten).
- Über die Oberfläche im Browser eine direkte Einbindung von Links möglich.
- Eine sehr einfache Georeferenzierung und sehr gute Kartendarstellung (Georeferenzierung viel einfacher als in GFAhnen [wo sich jetzt zeigt, dass viele Koordinaten ziemlich ungenau sind!]).
- Eine ausgefeilte Bilderverwaltung.
- Eine tolle Doublettensuche. Ich habe rund 4000 Doubletten aus meiner Datei herausgeworfen in sehr vertretbarer Zeit.
- Eine sehr gute Verwandtschaftsberechnung mit graphischer Darstellung, auch über 10 Generationen hinaus.
- Eine anscheinend sehr saubere Ausgabe nach Gedcom. Das ist der Grund, warum ich eher den Weg TNG – Export – Import in ein anderes Programm wähle statt der Bearbeitung im Desktopprogramm und regelmäßigem Import nach TNG zur Internetdarstellung. Es hat mich doch viel Zeit gekostet, die GFAhnen-Exportdatei so umzustricken, dass ich sie halbwegs nach TNG bekommen habe. Das will man nicht zu oft machen und auf jeden Fall nicht regelmäßig.
Natürlich hat TNG auch Nachteile:
- keine vernünftigen Reports für den Druck (außer pdf-Dateien der Internetansicht; nun ja); keine rtf-Dateien zur Weiterverarbeitung.
- Für den offline-Betrieb muss man erstmal einen Server installieren, was vielleicht nicht jedermanns Sache ist.
Für die Datenausgabe habe ich mir intensiver den „Stammbaumdrucker“ und Gen_Pluswin angeschaut. Ich habe den Eindruck, dass man mit dem „Stammbaumdrucker“ extrem flexibel jedweden Report nach eigenen Bedürfnissen durch die eingebaute Seriendruckfunktion erstellen kann. Allein, es ist mir auch unter Verwendung der Vorlagen nicht gelungen, eine Datenausgabe zu erzeugen, und auch das Studium das Handbuchs hat mich nicht erfahren lassen, wo und wie ich das Einmischen der Daten starte.
Letztlich habe ich mich für Gen_Pluswin entschieden. Die Export-Dateien von TNG lassen sich mit dem wesentlichen Inhalt [DNA ist nicht GEDCOM-gemäß exportierbar; Bilder habe ich nicht ausprobiert, ob das geht oder nicht] problemlos nach Gen_Pluswin importieren. An Gen_Pluswin überzeugt mich die Datenausgabe, die man differenziert gestalten kann [gut, nicht so individuell wie theoretisch im Stammbaumdrucker; aber ich bin sehr von den Auswahlmöglichkeiten angetan] und die gute Dateien für die Weiterarbeit in Word liefert.
Ein bisschen überraschend ist es, dass Fußnoten nicht mit der Fußnotenfunktion realisiert sind, sondern sie stehen formatiert als Normaltext jeweils unter einer Familie. Diese Lösung fand ich erst etwas gewöhnungsbedürftig, aber scheint mir je länger, je mehr sehr sinnvoll. So kann man auch problemlos einen Abschnitt aus einer Datei heraus- und woanders hineinkopieren, ohne dass das Formatierungsprobleme gibt. Die Ausgabe kann in der Textverarbeitung dann problemlos weiter formatiert und bearbeitet werden. Diverse Register (Namen, Orte) sind möglich und natürlich ein gutes Quellenverzeichnis. Ein Register der Berufe oder Todesursachen ist wohl eine GFAhnen-Spezialität und setzt die GFAhnen-spezifischen Datenbanken voraus, aber sind ja auch nicht unbedingt erforderlich (Kategorie „nice to have“, aber eben nicht „ohne geht es nicht“). Für die Datenausgaben also ein sehr großes Lob an Gisbert Berwe und Gen_Pluswin! (Weitere Funktionen habe ich nicht im Detail getestet, daher kein Kommentar – was keine Negativaussage sein soll)
GRAMPS habe ich auch in die nähere Auswahl gezogen als Hauptprogramm; aber da war der Export-IMport noch fehlerträchtiger, dass ich davon Abstand genommen haben – und mit meinen Testdaten habe ich keinen guten Report hingekriegt (was an mir liegen kann, nicht an Gramps liegen muss).
Ich meine, dass ich mit der Kombination TNG – Gen_Pluswin eine gute Entscheidung getroffen habe. Ich habe die Hoffnung, auch das OFB-Modul nutzen zu können, indem ich mit anderen Forschern online von verschiedenen Orten aus in TNG arbeite, die Daten am Ende nach Gen_Pluswin bringe und dort lokal endbearbeite. Mal sehen.
Das Export-Problem von GFAhnen
In Gedcom werden benutzerdefinierte Ereignisse, für die es keinen eigenen Gedcom-Tag gibt, mit dem Tag EVEN beschrieben, der durch den Zusatz TYPE näher spezifiziert wird. Hat man beispielsweise den Ereignistyp „Militärdienst“ definiert, dem dann verschiedene Tätigkeiten zugeordnet werden (Dragoner, Militärarzt, Musketier), so muss dies in Gedcom folgendermaßen erscheinen:
1 EVEN Militärarzt [oder eben: Musketier, Dragoner …]
2 TYPE Militärdienst
2 DATE from 1864 to 1866
2 PLAC Hannover
GFAhnen hingegen schreibt die Angabe zur Tätigkeit (Militärarzt, Musketier, Dragoner) ins Feld TYPE und lässt das Feld EVEN frei. Bei Import nach TNG (oder ein beliebiges anderes Programm) werden folglich sämtliche Tätigkeiten zu eigenen Ereignistypen, denen dann keine weitere inhaltlichen Angaben mehr zugeordnet sind.
Hierzu ist zwar eingewandt worden, der GEDCOM-Standard erlaube es bei Personendaten nicht, das Feld EVEN zu füllen; GFAhnen exportiere also richtig, TNG importiere falsch. Allerdings führt der Export von GFAhnen mit der GFAhnen-spezifischen Verwendung von EVEN und TYPE nicht nur in TNG, sondern in mehreren Programmen beim Import zum gleichen Problem (TNG, Genplus_Win, Gramps und – ich meine – bei Legacy). Alle diese genannten Programme schreiben die inhaltliche Füllung (Militärarzt, Musketier, Dragoner) in das Feld TYPE, so dass dann als Lebensphasen-Typen im importierenden Programm auf einer Ebene nebeneinanderstehen: Beruf (OCCU), Wohnort (RESI), Assistenzarzt-Stellvertreter (EVEN) – eine offensichtlich widersinnige Reihung.
Es erscheint mir ein wenig verwegen zu behaupten, dass allein GFAhnen den Export richtig mache und TNG, Genplus-Win, Gramps etc. allesamt falsch importierten. Den Angaben im Gen-Wiki zufolge soll ein Widerspruch in den Gedcom-Definitionen an sich enthalten sein (unten auf der Seite erläutert). Allerdings richten sich alle genannten Programme nach dem Beispiel, das genau den Erläuterungen im Gen-Wiki entnommen ist:
1 EVEN Ernennung zum Vorsitzenden des Bebauungsplankomitees
2 TYPE Städtische Ernennungen
2 DATE FROM JAN 1952 TO JAN 1956
2 PLAC Cove, Cache, Utah
2 AGNC Cove CITY Stadtentwicklungsbehörde
So erwarten TNG, Genplus_Win und andere die Daten. Allein GFAhnen würde in diesem Beispiel Städtische Ernennungen als TYPE ignorieren und stattdessen dort Ernennung zum Vorsitzenden des Bebauungsplankomitees schreiben. Alle getesteten Programme verstehen dann aber beim Import Ernennung zum Vorsitzenden des Bebauungsplankomitees als TYPE und lassen das Feld für den Inhalt frei. Auch umgekehrt exportiert TNG genau im Sinne dieses Beispiels – und komischerweise funktioniert dann umgekehrt der Import nach GFAhnen dann durchaus.