Seite 1 von 1

GedCom Import benennt Ereignisse um

Verfasst: 16.04.2020, 10:21
von Jowe
Guten Tag.
Die Zusammenarbeit in einem historische Verein zwingt mich, Daten vorwiegend im Programm "Brohers Keeper" zu erfassen. Natürlich ist Ahnenblatt viel übersichtlicher und einfacher zu handeln. Eigentlich kein Problem, Export der Daten vollständig als GedCom und Import in AB.
Aber jetzt findet die Datenplausibilitätsprüfung plötzlich bei dutzenden Personen das Ereignis "Tod" doppelt. Eine Überprüfung erbrachte, dass das Begräbnisdatum in BK in AB als zweites Todesdatum eingelesen wird. Das seltsamerweise aber nicht bei allen betroffenen Personen mit Todes- und Begräbnisdatum.
Konfiguration: BK 7.4, AB 3.09, Win10 64bit. Ich kann nicht mehr sagen, ob es bei frühren 2.x Versionen von AB auch so war.
Ich stehe auf dem Schlauch! Hat jemand eine Idee?
Gruß,
Jörg

Verfasst: 16.04.2020, 12:27
von Fridolin
Melde es an Dirk, den Programmierer! Ich vermute mal, dass Brothers Keeper kein ursprünglich deutschsprachiges Programm ist, so dass es nicht von der Arbeitsgemeinschaft der deutschsprachigen Genealogieprogramm-Macher erfasst ist.

Ein Begräbnis sollte in AB 3.0x definitiv nicht als zweites "Tod"-Ereignis, sondern als "Bestattung" erfasst werden.

Es gibt aktuell mehrere Beschwerden über Effekte, die zu doppelten Ereignissen führen (die grundsätzlich zulässig und kein Fehler sind, aber von der Plausi als Problem benannt werden: in deinem Fall zum GLück). Nur der Vollständigkeit halber nochmal: Die Plausi ist keine Fehlermeldung, sondern enthält genauso gut Warnungen. Aber es werden auch vermutliche und echte Fehler gemeldet.

Ach so: Es wäre interessant zu wissen, wie Brothers Keeper die Begräbnisdaten exportiert - manche Programme sind so kreativ, dass man sich nicht wundern muss, wenn ein "biederes", weitgehend standardgetreues Programm etwas anderes draus macht.

Frido

Verfasst: 16.04.2020, 13:30
von Klaus-DieterR
Hallo Jörg,

in einer mit AB generierten GEDCOM-Datei sehen die Tags Tod und Bestattung wie folgt aus:
1 DEAT
2 DATE 11 APR 2020
2 PLAC Leer, Ostfriesland, Niedersachsen, Deutschland
1 BURI
2 PLAC Leer, Ostfriesland, Niedersachsen, Deutschland
2 DATE 13 APR 2020

Wie sehen diese in deiner mit "Brother's Keeper" erstellten GEDCOM-Datei aus ?
Welcher GEDCOM-Standard wird unterstützt (konnte auf der web-Seite nichts dazu finden) ?

Verfasst: 16.04.2020, 16:30
von Jowe
Klaus-DieterR hat geschrieben:Hallo Jörg,

in einer mit AB generierten GEDCOM-Datei sehen die Tags Tod und Bestattung wie folgt aus:
1 DEAT
2 DATE 11 APR 2020
2 PLAC Leer, Ostfriesland, Niedersachsen, Deutschland
1 BURI
2 PLAC Leer, Ostfriesland, Niedersachsen, Deutschland
2 DATE 13 APR 2020

Wie sehen diese in deiner mit "Brother's Keeper" erstellten GEDCOM-Datei aus ?
Welcher GEDCOM-Standard wird unterstützt (konnte auf der web-Seite nichts dazu finden) ?
Hallo Klaus-Dieter,
ich habe gerade nachgesehen. Genau so. Wenn ich einen Eintrag einer Person, die mit "Doppelt-Tod" in AB angezeigt wird anschaue sieht er soweit ich sehe ebenfalls so aus. Ich verstehe es nicht!
Als Gedcom Version wird in der aktuellen Datei 5.5.1 genannt.
Werde jetzt nochmals die Gedcom Datei mit BK erzeugen und neu in AB importieren. Dann schauen wir mal!

Verfasst: 16.04.2020, 17:09
von jsy_vienna
Hallo Jörg,
Da ich von Brothers Keeper noch nie etwas gehört habe, wurde ich neugierig und habe mir die Version 7.4 installiert und eine GEDCOM Datei meiner Datenbestände aus Ahnenblatt 3.09 importiert.
Beim ersten Hinsehen scheint die Übernehme der meisten Informationen richtig zu erfolgen.
Zu Deinem Problem mir „Tod“ und „Bestattung“ Tag DEAT und BURI:
Beide Informationen werden von BK richtig beim Import erkannt und werden auch korrekt angezeigt.
Nun machte ich, ohne irgendeine Änderung im KB-Bestand durchzuführen, einen GEDCOM-Export aus BK. Das Ergebnis ist eine GEDCOM Datei, die um wesentliches kleiner ist als die ursprüngliche GEDCOM-Datei (nur etwa 35%) aus Ahnenblatt 3.09.
Diese Datei habe ich in Ahnenblatt 3.09 eingelesen.
Die gute Nachricht: Tod und Bestattung stimmt bei allen Datensätzen. Auch in der GEDCOM-Exportdatei passen die Tags DEAT und BURI
Ich kann somit Deine Problematik mit meinem Datenbestand nicht nachstellen, kann aber damit bestätigen, dass der Import bezüglich dieser Tags ok ist.
Nur noch eine Idee ins Blaue geschossen.
Sind die Bestände von BK ok? Da gibt es eine Funktion und Menu „Datei“ „Datensatz neu indexieren“ bzw. „Nützliches“ dann „endlosschleife auffinden“. Ev. Findest Du noch weitere Prüfmöglichkeiten.
Das mal austesten und sehen, ob dadurch eine Besserung entsteht.
Falls Du weitere Fragen hast, kannst Du mich auch über die Mailfunktion des Forums gerne kontaktieren, da die Sache für das Forum eventuell nicht so interessant ist.
Beste Grüße
Johannes

Verfasst: 16.04.2020, 18:28
von Jowe
Ich antworte mir mal selbst, eine Lösung habe ich gefunden.
Wenn ich aus BK die Gedcom wie voreingestellt und bisher immer so gemacht in Ansel exportiere tritt der Fehler auf, beim Export in UTF-8 nicht. Warum - keine Ahnung! Irgendwelche seltsamen Sonderzeichen benutze ich m.E. nicht.

Verfasst: 16.04.2020, 19:06
von Fridolin
Danke für die Nachricht.

Gratuliere!

Weiterhin viel Spaß!

Verfasst: 16.04.2020, 19:11
von bjew
Richtig, Gedcom ist eigentlich auf UTF-8 umgestellt. Du müsstes deine Gedcom-Datei umformen,
das geht z.B. auch mit dem Windwos-Editor, nur müsstest zusätzlich auch im Header die entsprechenden Tags umstellen

alt
1 GEDC
2 VERS 5.5.1
2 FORM LINEAGE-LINKED
1 CHAR ANSI
2 VERS 1252

1 PLAC

auf neu
GEDC
2 VERS 5.5.1
2 FORM LINEAGE-LINKED
1 CHAR UTF-8
1 _NAVM 2

Verfasst: 16.04.2020, 20:47
von Jowe
Bernhard, ich glaube Du hast was missverstanden. Die alte Gedcom war nicht im ANSI-Format, dann hätte ich das darauf zurückgeführt. Sie war im soweit ich weiß durchaus bei Gedcom noch üblichen ANSEL Format. BK kann sogar Gedcom noch in ANSI exportieren, aber das sollte man denke ich unterlassen.Trotzdem muss da bei ANSEL trotz Gedcom 5.5.1 irgend etwas schif laufen beim Import in AB. Bei UTF-8 geht es ja.

Verfasst: 16.04.2020, 23:17
von bjew
HAha, ich wollte nur in den Beispielen nur die relevanten Zeilen Zeilen markieren, egal was im ersten Beispiel steht. Ahnenblatt braucht heute UTF-8. Mir ging es nur um die Umcodierung.


Die Byte-Codierung von Ascii, Ansi, Ansel, etc ist eine völlig andere als bei UTF-8. UTF- ist eine Mehr-Byte-Codierung, da kann es schon sein, dass da etwas fehlinterpretiert wird, wenn die UTF-Codirung nicht erkennbar ist. Zudem gibt es noch unterschiedliche Datei-Formate.
Hilfrich könnte noch sein, wenn du den DateiHeader hier posten würdest, von der 1. Zeile
0 HEAD bist zur nächsten. Zeile mit einer weiteren 0 beginnend, persönliche Daten kannst ja aus-Xen

also z.B.

0 HEAD
1 SOUR AHN
2 VERS 2.99b
2 NAME Ahnenblatt
2 CORP Dirk Boettcher
1 DATE 10 SEP 2018
2 TIME 12:29:44
1 SUBM @SUBM@
1 FILE xxxxxxxxx.ged
1 GEDC
2 VERS 5.5.1
2 FORM LINEAGE-LINKED
1 CHAR UTF-8
1 _NAVM 2
2 _NAVI @I1784@
1 _HOME @I1784@
0 @SUBM@ SUBM

weiters einen Abschnitt, in dem die fehlinterpretierten TAGs vorkommen.

Sonst ist einfach ein rumraten