Ahnenblattportal

Moin,
ich arbeite schon seit einigen Jahren mit Ahnenblatt. Nun wollte ich einen Gedcom-Export machen, um die Datei dann im Stammbaumdrucker einzulesen. Hat auch funktioniert. In Ahnenblatt habe ich unter Quellen Kirchenbuchtexte eingetragen. Diese wurden leider nicht mit übernommen. Die Eingaben die ich in Anmerkungen eingetragen habe wurden aber mit übernommen.

Was mache ich falsch? Oder können die Einträge aus "Quellen" nicht mit in die Gedcom-Datei übernommen werden?

Ahnenblatt Version 2.99c

Stammbaumdrucker Version 7.3.0.4 (10.04.2017)

Viele Grüße aus Weyhe
Detlef

Hallo Detlef,

ich gehe mal davon aus, dass du die Datei inkl. Anmerkungen und Quellenangaben in AB 2.99c erstellt hast - ohne Umweg über AB 3.0-beta oder ein anderes Programm. Dann gibt es ja zu jeder Person nur ein Quellen-Feld. Und das sollte auch in eine GEDCOM-Datei exportiert werden - habe ich ausprobiert.

Bei mir sieht das z.B. so aus: In der "SOUR"-Zeile ist die Quelle angegeben. Das kann durchaus auch mal mehrzeilig sein.

Ahnenblatt bemüht sich sowieso, alles Vorhandene auch in eine GEDCOM-Datei zu exportieren; es gibt genug Benutzer, die ihre Daten grundsätzlich im GEDCOM-, nicht ihm *.AHN-Format speichern. Es sieht für mich also so aus, als hätte eher der Stammbaumdrucker Probleme mit dem Einlesen der Quellen - aber ich wüsste jetzt auch nicht, warum auf einmal.

Hm, ja, ich meine auch, dass ich schon mal einen Export gemacht hatte, wo auch die Quellen mit übernommen wurden. Hmm, dann bleibt mir wohl nichts anderes übrig, als die Texte in die Anmerkungen zu kopieren :-(

Aber danke für die schnelle Antwort

Hallo DeziHB,

Ahnenblatt exportiert höchstwahrscheinlich die Quellen (kannst du selbst leicht nachprüfen durch Betrachten einer GEDOM-Datei in einem Texteditor). Der Stammbaumdrucker scheint sie nicht zu übernehmen.

Das ist aus meiner Sicht kein Grund, seine gesamte Datei umzubauen in einen Zustand, der zwar in diesem einen Fall funktioniert, aber nicht den Regeln entspricht. Auch der Stammbaumdrucker hat einen Programmierer, und damit solche Probleme nicht immer wieder auftreten, haben viele deutschsprachige Programmierer einen Arbeitskreis und Gesprächsaustausch, um solche Probleme zu beheben. Meine Lösung wäre: Problem an beide Programmierer melden. Die können dann sehen, ob es ein allgemeines Problem ist oder etwas da schief läuft, was sonst nicht passiert.

Hier im Forum kenne ich sonst nur Jürgen_Nordlicht, der beide Programme benutzt. Vielleicht hat der noch was Erhellendes beizutragen.

Frido

hallo
ich arbeite seit einiger Zeit mit Ahnenblatt 3.02. Kann ich jetzt keinen Gedcom-Export mit ANSI Format erstellen ? Eines meiner Programme zur Weiterverarbeitung benötigt dieses Format zur richtigen Zeichendarstellung. Was kann ich tun ?
Muss ich evt. die Datenbank in AB 2.99 einlesen und dort unter ANSI speichern ? Damit klappte es bisher.
heinrich

Hallo Heinrich,

Ahnenblatt ist im Importbereich in der Lage, mit den "Schandtaten" von allerhand Genealogieprogrammen umzugehen. Es können also auch GEDCOM-Dateien eingelesen werden, die nicht standardkonform sind. Das wäre der Fall, wenn der Zeichensatz ANSI in einer GEDCOM-Datei verwendet wird. Eigentlich sind nur ANSEL, ASCII, UTF-8 oder Unicode erlaubt.

Die Arbeitsgemeinschaft deutschsprachiger Genealogieprogramm-Programmierer hat sich darauf verständigt, UTF-8 als Standard zu betrachten: http://wiki-de.genealogy.net/GEDCOM/CHAR-Tag
Ahnenblatt entspricht den Absprachen dieser Arbeitsgemeinschaft, die eine verbesserte Austauschbarkeit anstrebt, dadurch, dass man sich beim Export an die Standards sowie die gemeinsamen Verabredungen hält. Es exportiert GEDCOM m.W. neuerdings immer in UTF-8 (in früheren Versionen auch in ANSEL, fallls keine erweiterten Sonderzeichen enthalten waren) - in diesem Punkt bin ich mir nicht sicher. Klar ist jedenfalls, dass Ahnenblatt nicht in ANSI exportiert - wer diese früher häufig anzutreffende Regelverletzung benötigt, muss sich nach Lösungen außerhalb von Ahnenblatt umschauen, mit denen man GEDCOM-Dateien umwandeln kann. Es ist mir allerdings auch nicht klar, wie man überhaupt bestimmte Sonderzeichen in ANSI darstellen will, denn der dort vorhandene Zeichenvorrat ist doch sehr beschränkt.

Ich würde es für zukunftsträchtig halten, insgesamt auf einen Bearbeitungsprozess umzusteigen, der auf UTF-8 (einer besonders platzsparenden Speichervariante von Unicode-Zeichen) beruht. Statt knapp 200 verschiedenen Zeichen hat man dann einen Buchstabenvorrat von über 130.000 in allen Schriften der Welt.

Leider weiß ich selbst kein Werkzeug für diesen speziellen Bedarf. Da UTF-8 seit der Erfindung erst knapp 20 Jahre alt ist, ist es nachvollziehbar, dass sehr alte Programme trotz der vielen Vorteile damit noch nicht umgehen können.

Was du meinst mit Speichern in ANSI unter Ahnenblatt 2.99, habe ich nicht einordnen können. Prinzipiell kann man sehr wohl eine Ahnenblatt-3.0-Datei in Ahnenblatt 2.99 öffnen und wieder abspeichern - dabei sollten alle Daten erhalten bleiben; aber: Auch in Ahnenblatt 2.99 kann man meines Wissens kein GEDCOM in ANSI speichern (wenn doch: Wie hast du das gemacht?). Und ein Speichern in ein reines Textformat (CSV) ist dann doch mit kleineren oder größeren Verlusten verbunden - je nach Umfang der Daten. In CSV werden keine Daten aus der Ortsverwaltung übernommen; evtl. zentral verwaltete Quellen gehen zwar nicht ganz verloren, verlieren aber evtl. ihre zentrale Verwaltbarkeit (hat das schon jemand geprüft?).

Ahnenblatt 3.0 ist eine mächtige Weiterentwicklung des bisherigen Programms mit viel mehr Möglichkeiten (viele neue Datenfelder, einige zentrale Verwaltungen: Orte, Quellen, Aufgaben). Aber in Einzelfällen kann es tatsächlich dazu führen, dass man sich neue Arbeitsabläufe suchen muss. Das gilt auch für all diejenigen, die bisher in CSV exportiert haben und dann in einer Tabellenkalkulation weitergearbeitet haben. CSV ist nur noch in Sonderfällen das Mittel der Wahl.

Frido

Hallo Frido,
ich musste mich erst mal wieder erinnern - vor längerer Zeit habe ich mit Vers. 2.9 gearbeitet und stand schon mal vor dem Problem. Damals hatte Dirk Böttcher mir den Weg zu einer unter 2.9 noch vorhandenen Tool Ergänzung "Speichern unter ANSI" gesagt. Und mit diesem Menupunkt kann ich in ANSI speichern. Du hast Recht, dass wir die ANSI-Version möglichst wenig nutzen sollten, aber ich habe ein Programm (Ged4Web von Anthony Papineau) auf das ich noch nicht ganz verzichten möchte und das es nicht in UTF 8 gibt). Ansonsten arbeite ich mit dem von AB vorgesehenen Format.
Heinrich

Hallo Heinrich,

ach so. Ja, wenn das so ist...

Wenn das in AB 2.99 ein Plugin ist, dann hast du es mal von Hand installiert. Und wenn es unter dieser Version läuft, stehen die Chancen nicht schlecht, dass du es auch in AB 3.0 einrichten kannst - dann eben im Plugin-Verzeichnis für AB 3.02. Da kommen mehrere in Frage: Das Plugin-Verzeichnis im Programm-Verzeichnis oder ein Plugin-Verzeichnis unter MeinBenutzername\Ahnenblatt\. Am besten Installationshinweise lesen: Plugin: Ausgabe Gedcom-ANSI erzwingen

Vielleicht klappts... Wenn nicht, wird es schwierig, denn der Autor des Plugins ist nicht mehr da.

Frido

Guten Abend Frido,
vielen Dank für Deine Erläuterungen. Ich habe das plugin (gedcom-ansi.abp) in das entsprechende Verzeichnis bei AB 3.0 kopiert und es scheint zu funktionieren. Ohne Fehlermeldungen wird die gedcom-Datei erstellt. Aber im Hinblick auf die eingeschränkte Anwendbarkeit von gedcom-ansi werde ich diese Datei wohl nur für dies eine Proramm (Ged4web) verwenden ansonsten im System von AB 3.0 bleiben.
Heinrich

Freut mich!

Wie gesagt: In ANSI können Sonderzeichen verloren gehen bzw. durch andere, ähnliche Zeichen ersetzt werden. Darum ist deine Entscheidung sicherlich gut.

Hallo,
es gibt noch einen einfachen Weg, die Gedcom-Datei zu konveertieren:
einfach mit einem geeigneten Editor laden und als ANSI speichern. geeignet sind verschiadene Editoren, auch der aus Windows-Zubehör (Auswahl mit "Codierung).

Allerdings können - wie Frido bereis erwähnt hat - Sonderzeichen zerstört oder verloren gehen,

Bernhard,

wenn du das empfiehlst, ergänze noch den zweiten Schritt: Dann bitte in der Zeile mit

n CHAR

(sollte eine der ersten 10 Zeilen sein) die Korrektur der Zeichensatzbeschreibung. Vermutlich sollte da dann ANSI stehen - weiß ich aber nicht, da man das ja nicht in der Spezifikation nachlesen kann (weil es außerhalb der Spezifikation ist).

Frido

mhm. bin ich mir jetzt aber nicht ganz sicher, ob AB das wirklich prüft. kann es ja mal testen.

Anmeckern tuts Ahnenblatt nicht, Formal korrekt wäre der entsprechende Eintrag - insbesondere deshalbt, da es das Zielprogramm missverstehen könnte.

Somit hast du wieder Recht