Registrieren | Hilfe | Chat | Benutzerliste | Team | Kalender | Suchen | Heutige Beiträge | Alle Foren als gelesen markieren |
#1
|
|||
|
|||
![]()
Hallo Spezialisten,
ich möchte eine GEDCOM aus FTM 2019 exportieren und anschließend in GEDBAS hochladen. Der GEDCOM Export aus FTM 2019 arbeitet wohl nicht ganz fehlerfrei. Siehe Beispiel im Anhang den Fact 1817 "Employment". Im Gedcom File wird daraus: 1 _EMPLOY gewesener Schulze zu Chorinchen 2 DATE 1817 2 PLAC Chorinchen, Kreis Angermünde, Brandenburg, Deutschland Das ist kein richtiger GEDCOM Tag und wird beim Import GEDBAS ignoriert. Ich habe daraufhin das __EMPLOY in OCCU geändet (siehe auch GEDCOM Tags: http://wiki-de.genealogy.net/GEDCOM-Tags) Anschließend habe ich das GEDCOM File erneut in GEDBAS importiert. Das wurde leider nicht übernommen. Siehe: https://gedbas.genealogy.net/person/show/1299937334 Die fehlerhafte GEDCOM Datei habe ich hier abgelegt: https://drive.google.com/file/d/1xMU...ew?usp=sharing Die von mir korrigierte Datei ist hier: https://drive.google.com/file/d/1UnJ...ew?usp=sharing Gibt es dafür eine Lösung ? Schöne Grüße Heiko Update: Nach der Korrektur wurde das von GEDBAS sehr wohl übernommen, das habe ich nicht richtig gesehen. Bleibt das Problem des nicht richtig funktionierenden Exportes von FTM Geändert von Kühling (28.12.2021 um 16:12 Uhr) |
#2
|
||||
|
||||
![]() Hallo Heiko,
da fallen mir spontan mehrere Möglichkeiten ein:
|
#3
|
|||
|
|||
![]() Hallo Xtine,
ich habe nun ein wenig experimentiert. Einige Felder i der deutschen Version von Ancestry werden zwar mit FTM 2019 syncronisiert, jedoch beim Export von FTM in das GEDCOM - Format mit einnem Underscrore ausgegeben Beispiel: Wenn man Online auf www.ancestry.de einen Fakt "BERUF" auswählt und dann mit FTM synchronisiert, so wird daraus in der GED-Ausgabe von FTM ein "_EMPLOY", das in GEDBAS nicht eingelesen werden kann. Wenn man jedoch das Feld "Beschäftigung" auswählt, erfolgt die Ausgabe korrekt mit dem GEDCOM Tag "OCCU" und wird erfolgreich in GEDBAS eingelesen. Dasselbe passiert wenn man Online auf Ancestry das Ereignis "Beerdigung" hinzufügt. FTM 2019 macht daraus den GEDCOM Tag "_FUN". Wählt man Online auf Ancestry jedoch das Ereignis "Bestattung" wird das von FTM richtig interpretiert und macht daraus das GEDCOM - Feld "BURI" (für Burial). Diese Hilfe auf GEDBAS hat mir ein wenig geholfen, welche Tags auf GEDBAS überhaupt importiert und dargestellt werden. http://wiki-de.genealogy.net/GEDBAS/GEDCOM-Import Als Lösung kann man die Felder in FTM 2019 unter: EDIT --> Manage FACTS umeseln, d.h. man muß beispielsweise den Fakt "BERUF" auswählen und mittels Data Options in "Occupation" umwandeln. Der Upload Sync Richtung Ancestry geht problemlos. Die Umwandlung in das GEDCOM File und anschließende Hochladen in GEDBAS funtktioniert dann ebenso und wird auch korrekt dargestellt. Als Summary: Verwende auf Ancestry.de die Felder "Beschäftigung" anstelle BERUF und "Bestattung" anstelle BEERDIGUNG. Schöne Grüße Heiko Geändert von Kühling (28.12.2021 um 19:43 Uhr) |
#4
|
||||
|
||||
![]() Also eindeutig Übersetzungsfehler
![]() |
#5
|
|||
|
|||
![]() Ich möchte da etwas Grundsätzliches zu los werden. Die Grundaussasge war schon falsch. Denn _EMPLOY IST in korrektes GEDCOM-Tag. GEDCOM erlaubt die Anlage von nutzerdefinierten Tags. Die müssen aber zwingend mit einem Unterstrich beginnen. Was hier ja durchaus passiert. Also ist alles OK. Die Aussage der Export sei nicht ganz fehlerfrei ist so also falsch.
Das Problem mit solchen nutzerdefinierten Kennzeichen ist aber natürlich, das nicht jedes andere Programm die versteht. Und das manche Programme die nutzen obwohl es dafür auch in offizielles Kennzeichen gäbe. Gerade amerikanische Programme sind da sehr schnell mit, etwas vorhandenes neu zu erfinden. Oder statt mal nachzushauen welches nutzerdefinierte Kennzeichen andere Programme da schon verwenden einfach noch mal was neues zu erfinden. Es gibt eine Aufstellung diverser Kennzeichen, die die Entwickler der GEDCOM-L unter https://wiki-de.genealogy.net/GEDCOM/_Nutzerdef-Tag zusammen gestellt haben, um eben das Rad nicht immer neu erfinden zu müssn. Und um den Import auf nutzerdefinierte Kennzeichen zu erweitern und damit den Import vollständiger zu machen. Hier liegt es also nicht daran, das ein falsches oder gar ungültiges Kennzeichen verwendet wrid. Sondern daran das der FTM anscheinend mit sehr fein abgestuften Feldern arbeitet deren Unterschied dem Nutzer nicht sofort klar wird. Die beim GEDCOM-Export aber ebenfalls unterschiedlichen Kennzeichen zugewiesen werden. Stellenweise halt nicht allgemein verständlichen nutzerdefinierten Kennzeichen. |
![]() |
Lesezeichen |
Themen-Optionen | Thema durchsuchen |
Ansicht | |
|
|