Keine Anzeige der Religion in AB 4.19

[Jo301]

Hallo,

in Version 4.19 wird jedwede Religion aus einer eingelesenen GEDCOM-Datei nicht mehr angezeigt (hier: 1 RELI ev.).

2024-12-19_091313.png

In Version 4.17 funktionierte es noch. Gruß Jo301

[HoWo]

Kann ich nicht bestätigen !
Habe es eben auch mal probiert - die Religionen sind da !

[Jo301]

Wahrscheinlich wurde das in der V4.18 veroptimiert, siehe:
"OPTIMIERT: GEDCOM-Import: optimiert für Ages!"

Nach Deiner Angabe "AB 4.17 + (AB 3.60)" könntest Du es garnicht bestätigen oder ausschließen.

[HoWo]

Wahrscheinlich wurde das in der V4.18 veroptimiert, siehe:
"OPTIMIERT: GEDCOM-Import: optimiert für Ages!"

Nach Deiner Angabe "AB 4.17 + (AB 3.60)" könntest Du es garnicht bestätigen oder ausschließen.

KANN ich, da ich das, leider, nur noch nicht aktualisiert habe - sorry ! Das mache ich sofort.

[DirkB]

Hallo Jo301,

danke für den Hinweis - werde ich korrigieren.

- Dirk

[Jo301]

Hallo Dirk,

die fehlende Religion wird in der V4.20 aus Ages! korrekt übernommen, danke.
Ich habe meine GEDCOM-Datei jetzt nochmal mit der V4.19 übernommen und verglichen,
links mein Original und rechts die von der V4.19 exportierte GEDCOM:

2025-01-11_115839.png

Dabei fällt noch auf, dass in der V4.19 alle AGE Tags (bei INDI und HUSB/WIFE in FAM) in Kommentare gewandelt werden.
Damit würden sie für mein Online-OFB verloren gehen.

Ist das in der V4.20 immer noch so?

Weiter werden Tags AGNC (zuständiges Amt) irreversibel in Kommentare gewandelt:

2025-01-11_121812.png

Ich hätte das alles natürlich gern getestet, wenn Du nicht die Speicherung / Export (ohne Lizenz) zur V4.20 eingeschränkt hättest. Daher bitte ich um Prüfung, wie sich die Sachverhalte nach Speichern als *.ahn und Reexport in GEDCOM verhalten.

Gruß
Joachim

[DirkB]

Hallo Joachim,

Dabei fällt noch auf, dass in der V4.19 alle AGE Tags (bei INDI und HUSB/WIFE in FAM) in Kommentare gewandelt werden.
Damit würden sie für mein Online-OFB verloren gehen.
Ist das in der V4.20 immer noch so?
Weiter werden Tags AGNC (zuständiges Amt) irreversibel in Kommentare gewandelt:

Ja, das ist weiterhin so. Diese Informationen sind dann damit im Eingabedialog von Ahnenblatt sichtbar, da es keine Eingabefelder für "Alter" und "zuständiges Amt" gibt (in anderen Programmen auch eher selten anzutreffen).

Wieso gibt es Probleme mit dem Online-OFB?
Kann dieses nicht mit Kommentaren umgehen oder gehen diese verloren?
Dann bräuchte ich nähere Infos zu "deinem Online-OFB" (Wo und welche Software?).

Ich hätte das alles natürlich gern getestet, wenn Du nicht die Speicherung / Export (ohne Lizenz) zur V4.20 eingeschränkt hättest. Daher bitte ich um Prüfung, wie sich die Sachverhalte nach Speichern als *.ahn und Reexport in GEDCOM verhalten.

In die optimierten GEDCOM-Importe ist viel Gehirnschmalz reingeflossen, daher soll die kostenlose Demo-Version nicht als "Reparatur-Tool" verwendet werden können. Die Speicherung ist weiterhin mit kleinerer Personenzahl (<= 50 Personen) möglich. Dann einfach mal eine kleinere Datei öffnen.

Ahnenblatt repariert darüber hinaus (bezogen auf Ages!) auch Wohnorte, kirchliche Heiraten und übernimmt Aufgaben.

Generelle Frage: Wieso überhaupt den Umweg der Ages! GEDCOM über Ahnenblatt?

- Dirk

[Jo301]

Hallo Dirk,

...

...
Weiter werden Tags AGNC (zuständiges Amt) irreversibel in Kommentare gewandelt:

Ja, das ist weiterhin so,

Edit: In der V4.17 bleiben alle AGE / AGNC trotz Konvertierung einfach erhalten, das war lange Zeit auch die gute Eigenschaft von Ahnenblatt!

Diese Informationen sind dann damit im Eingabedialog von Ahnenblatt sichtbar, da es keine Eingabefelder für "Alter" und "zuständiges Amt" gibt (in anderen Programmen auch eher selten anzutreffen).

Ich habe diese GEDCOM-konformen Möglichkeiten aber bisher und nutze sie konsequent, wie auch andere Nutzer von Ages.
Die Altersangaben aus KB oder Personenstandsregistern sind einzutragen, solange sie nicht (automatisch) genau berechnet werden können!

Und eben diese Angaben (AGE und AGNC) werden bei https://ofb.genealogy.net/ auch richtig dargestellt.

Die in Kommentare gewandelten GEDCOM-Standard-Tags würden zwar als Kommentare dort dargestellt, wären aber für andere Genealogie-Apps verloren. Warum tust Du das? Es ist eine konzeptionelle Sackgasse ("2 AGE 1y 2m 3d" zu "denglisch" "2 NOTE Alter: 1y 2m 3d".

Weiter habe ich ein eigenes Tool, dass mir alle Altersangaben prüft und ggf. neu berechnet (es gibt Konstellationen, wo es Ages nicht automatisch tut).

...
Kann dieses nicht mit Kommentaren umgehen oder gehen diese verloren?

Grundsätzlich versuche ich aus Erfahrung Kommentare wann immer möglich zu vermeiden, sofern es GEDCOM-konforme Möglichkeiten gibt. GEDCOM ist immer noch das Austauschformat, bei allen bekannten kleineren Macken bei der Unterstützung durch Tools oder der Interpretation der Autoren.

In die optimierten GEDCOM-Importe ist viel Gehirnschmalz reingeflossen, daher soll die kostenlose Demo-Version nicht als "Reparatur-Tool" verwendet werden können.

Mal ehrlich: Im Moment ist es in den genannten Punkten das Gegenteil eines Reparatur-Tools.
Deine Arbeit in Ehren, aber warum bügelst Du Dinge heraus, die GEDCOM-standardkonform sind und auch in GEDCOM7 konvertiert werden könnten?

Ahnenblatt repariert darüber hinaus (bezogen auf Ages!) auch Wohnorte, kirchliche Heiraten und übernimmt Aufgaben.

Gibt es bitte eine Übersicht was alles bei den jeweiligen Tools repariert wird?

Aufgaben sind nett, aber ich nutze sie nicht mehr bzw. entferne die temporär erstellten (und bei Ages trotzdem fortbestehenden)
vor der Übergabe ins Online-OFB. Ages hat da eine bekannte Schwäche.

Generelle Frage: Wieso überhaupt den Umweg der Ages! GEDCOM über Ahnenblatt?

Das ist eine Berufskrankheit, Dinge inkrementell anzugehen, sie relativ bald zu testen, anstelle die volle Ladung Widersprüche zum Abgabetermin zu haben. Ergo: geht jede "Tagesportion" (Version) den Weg über den GEDCOM-Validator, ein professionelles Diff-Tool und zwei unabhängige Genealogie-Apps.
Dazu gibt es die Hesmer-Tools (Validierung/Duplikate). Sorry ich komme von CI/CD irgendwie nicht los.

Natürlich löse ich mich auch noch von Ages, sehe aber momentan dafür weder Grund noch Richtung, hmmm...
Eingedenk der Erfahrung mit Hr. Daub möchte ich mit den Daten (ohne Bügeleisen) portabel bleiben!

Gruß
Joachim

[DirkB]

Hallo Joachim,

Ich habe diese GEDCOM-konformen Möglichkeiten aber bisher und nutze sie konsequent, wie auch andere Nutzer von Ages.
Die Altersangaben aus KB oder Personenstandsregistern sind einzutragen, solange sie nicht (automatisch) genau berechnet werden können!

Das ist ja soweit in Ordnung. Wenn ein Anwender zu Ahnenblatt wechselt, dann soll er diese Informationen auch weiterhin sehen und findet sie jetzt in den Notizen (bislang nur unsichtbar im Hintergrund).

Und eben diese Angaben (AGE und AGNC) werden bei https://ofb.genealogy.net/ auch richtig dargestellt.

Habe ich auf die Schnelle nicht finden können. Hast du mal Link(s) zu Personen, bei denen beides dargestellt wird?

Die in Kommentare gewandelten GEDCOM-Standard-Tags würden zwar als Kommentare dort dargestellt, wären aber für andere Genealogie-Apps verloren. Warum tust Du das?

Gerade nicht verloren, weil viele Programme diese Felder nicht haben und die Daten womöglich beim Import ignorieren.

Es ist eine konzeptionelle Sackgasse ("2 AGE 1y 2m 3d" zu "denglisch" "2 NOTE Alter: 1y 2m 3d".

Ok, an der Darstellung werde ich noch ein wenig feilen, die ist wirklich nicht optimal.

Mal ehrlich: Im Moment ist es in den genannten Punkten das Gegenteil eines Reparatur-Tools.
Deine Arbeit in Ehren, aber warum bügelst Du Dinge heraus, die GEDCOM-standardkonform sind und auch in GEDCOM7 konvertiert werden könnten?

Damit sie in Ahnenblatt editierbar sind.

Ahnenblatt repariert darüber hinaus (bezogen auf Ages!) auch Wohnorte, kirchliche Heiraten und übernimmt Aufgaben.

Gibt es bitte eine Übersicht was alles bei den jeweiligen Tools repariert wird?

Das ist zusammen mit Alter und zuständiges Amt schon alles.

Das ist eine Berufskrankheit, Dinge inkrementell anzugehen, sie relativ bald zu testen, anstelle die volle Ladung Widersprüche zum Abgabetermin zu haben. Ergo: geht jede "Tagesportion" (Version) den Weg über den GEDCOM-Validator, ein professionelles Diff-Tool und zwei unabhängige Genealogie-Apps.
Dazu gibt es die Hesmer-Tools (Validierung/Duplikate). Sorry ich komme von CI/CD irgendwie nicht los.

Irgendwie verstehe ich das Verfahren nicht.
Die Ages! GEDCOM wird durch zwei weitere Genealogieprogramme geschickt, also Import und wieder Export?
Dadurch gibt es doch höchstwahrscheinlich Änderungen. Entweder willst du diese absichtlich, weil die Ages! GEDCOM damit "verbessert" bzw. "repariert" wird oder du hoffst, dass keine Änderungen durchgeführt werden - dann könntest du auch gleich die Original Ages! GEDCOM zu CompGen hochladen.

- Dirk

[Jo301]

Hallo Dirk,

...
Das ist ja soweit in Ordnung. Wenn ein Anwender zu Ahnenblatt wechselt, dann soll er diese Informationen auch weiterhin sehen und findet sie jetzt in den Notizen (bislang nur unsichtbar im Hintergrund).

das ist nicht in Ordnung, weil:
- die GEDCOM-standardkonformen AGE-Tags nicht wieder als AGE-Tag exportiert werden (was AB intern damit macht, ist völlig egal)
- AB scheinbar keine Möglichkeit hat ein Alter einzutragen, oder doch? (man findet oft Sterbeeinträge mit groben Altersangaben)

Und eben diese Angaben (AGE und AGNC) werden bei https://ofb.genealogy.net/ auch richtig dargestellt.

Habe ich auf die Schnelle nicht finden können. Hast du mal Link(s) zu Personen, bei denen beides dargestellt wird?

Hier ein Link, nicht von mir, aber ich war dran beteiligt:
https://ofb.genealogy.net/famreport.php ... 37&lang=de

Der GEDCOM-Auszug liegt im Anhang.

Die in Kommentare gewandelten GEDCOM-Standard-Tags würden zwar als Kommentare dort dargestellt, wären aber für andere Genealogie-Apps verloren. Warum tust Du das?

Gerade nicht verloren, weil viele Programme diese Felder nicht haben und die Daten womöglich beim Import ignorieren.

Das mit den vielen Programmen ist eine möglicherweise steile These, die ich nicht sehe.
Ich habe noch ein weiteres Programm im Einsatz, das sowohl AGE als auch AGNC sauber importiert, weil es eben GEDCOM-Standard ist.

Es ist eine konzeptionelle Sackgasse ("2 AGE 1y 2m 3d" zu "denglisch" "2 NOTE Alter: 1y 2m 3d".

Ok, an der Darstellung werde ich noch ein wenig feilen, die ist wirklich nicht optimal.

Daran ist nichts zu feilen, weil es GEDCOM-konform in jede beliebige Sprache übersetzbar ist, z.B. per PHP auf Webseiten.
Das wird bei Compgen so gemacht. Die AB-User mit OFB werden sich "bedanken".

Hier beisst die Maus keinen Faden ab:
Exportiere es wie bisher und implementiere Eingabefelder für das Alter (falls ich sie übersehen habe).
Die jahrelang praktizierte gute Politik, dass AB alles einliest, speichert und so wieder ausgibt wird damit aufgekündigt!
Was sollen denn die anderen Programm-Autoren damit anstellen?

Mal ehrlich: Im Moment ist es in den genannten Punkten das Gegenteil eines Reparatur-Tools.
Deine Arbeit in Ehren, aber warum bügelst Du Dinge heraus, die GEDCOM-standardkonform sind und auch in GEDCOM7 konvertiert werden könnten?

Damit sie in Ahnenblatt editierbar sind.

Ja hmmm, das muss konzeptionell auch anders gehen.
Man sollte deswegen nicht korrekte GEDCOM's in verbogene wandeln.

Ahnenblatt repariert darüber hinaus (bezogen auf Ages!) auch Wohnorte, kirchliche Heiraten und übernimmt Aufgaben.

Gibt es bitte eine Übersicht was alles bei den jeweiligen Tools repariert wird?

Das ist zusammen mit Alter und zuständiges Amt schon alles.

Anpassungen an Wohnorten habe ich in meinen Daten nicht bemerkt.
Ich weiss aber nicht, was andere User mit Wohnorten ggf. "anstellen".

...
Dazu gibt es die Hesmer-Tools (Validierung/Duplikate). Sorry ich komme von CI/CD irgendwie nicht los.

Irgendwie verstehe ich das Verfahren nicht.
Die Ages! GEDCOM wird durch zwei weitere Genealogieprogramme geschickt, also Import und wieder Export?

NEIN, es wird in zwei Genealogieprogramme importiert, die beide ihre Stärken bei der Erkennung von Diskrepanzen haben, exportiert wird es bewusst nicht. Im oben zitierten OFB-Projekt wurde diese begleitende Qualitätssicherung leider zu spät angefangen, das ist meine Lehre daraus.
In Ages! kann man sich in den langen Auswahllisten schnell mal verklicken, da kommen "ulkige" Sachen dabei heraus. Wenn man das nicht bald merkt hat man später schwer zu kämpfen (was war denn hier ursprünglich gemeint...).

Dadurch gibt es doch höchstwahrscheinlich Änderungen. ...

Nein, eben nicht, Compgen bekommt das Ages!-GEDCOM-File.

Das ganze ist meine Strategie, eine Qualitätssicherung kleinteiliger durchzuführen. Und bei GEDCOM als textuelles Format kann man auf der Linux-Kommandozeile noch viel herausfinden (grep [...] | sort -u) und andere Möglichkeiten.

Gruß Joachim

[DirkB]

Hier ein Link, nicht von mir, aber ich war dran beteiligt:
https://ofb.genealogy.net/famreport.php ... 37&lang=de

Danke für den Link.

Das mit den vielen Programmen ist eine möglicherweise steile These, die ich nicht sehe.
Ich habe noch ein weiteres Programm im Einsatz, das sowohl AGE als auch AGNC sauber importiert, weil es eben GEDCOM-Standard ist.

Mal auf die Schnelle ein paar Programme ausprobiert:
GES-2022, Family Tree Maker, Stammbaumdrucker und RootsMagic (jeweils aktuellste Versionen) haben weder Alter noch zuständiges Amt als Eingabefelder bei den Ereignissen.
Heredis übernimmt das zuständige Amt mit dem vorangestellten Begriff "Organisation" in den Ereignisnotizen und hat für ein Freitextfeld für das Alter, in das ich einen beliebigen Text eingeben kann (z.B. "abc") ohne das das Programm meckert.
Ich will nicht ausschließen, dass es auch Programme gibt, die diese Eingabefelder haben - aus meiner Sicht aber eher eine Minderheit (vor allem "zuständiges Amt").

Anpassungen an Wohnorten habe ich in meinen Daten nicht bemerkt.
Ich weiss aber nicht, was andere User mit Wohnorten ggf. "anstellen".

Ages! bietet beim Wohnort ein Eingabefeld ohne weitere Beschriftung, in dem der Anwender z.B. "Postdamer Platz, Berlin" eingeben kann.
Das wird dann als von Ages! als ...

Code: Alles auswählen

1 RESI Postdamer Platz, Berlin

... exportiert. RESI erlaubt aber keinen direkten Wert - wird dann von Ahnenblatt in ein ADDR-Feld verschoben.

Dadurch gibt es doch höchstwahrscheinlich Änderungen. ...

Nein, eben nicht, Compgen bekommt das Ages!-GEDCOM-File.

Dann kann dir doch eigentlich egal sein, was Ahnenblatt aus dem Import macht ...

- Dirk

[Jo301]

Hallo Dirk,

...
Ich will nicht ausschließen, dass es auch Programme gibt, die diese Eingabefelder haben - aus meiner Sicht aber eher eine Minderheit (vor allem "zuständiges Amt").

soviele habe ich nicht im Einsatz, ich treffe ein Vorauswahl unter Programmen die konzeptionell einigermaßen aktuell und in Pflege sind.
Eins davon ist Ancestris, dass AGE und AGNC im Aries-Editor darstellt und die Eingabe gestattet ("Alter / Verantwortliches Amt").

Ages! bietet beim Wohnort ein Eingabefeld ohne weitere Beschriftung, in dem der Anwender z.B. "Postdamer Platz, Berlin" eingeben kann.
Das wird dann als von Ages! als ...

Code: Alles auswählen

1 RESI Postdamer Platz, Berlin

... exportiert. RESI erlaubt aber keinen direkten Wert - wird dann von Ahnenblatt in ein ADDR-Feld verschoben.

Deine Beobachtung und Behandlung ist richtig, kann ich nur bestätigen und kenne das schon länger.
Das Eingabefeld bei Ages! darf für viele "Events" nicht benutzt werden, da ungültige GEDCOM-Sequenzen dabei herauskommen. Es muss aber benutzt werden, wenn man "Facts" (Anzahl der Kinder oder Anzahl der Heiraten) eintragen möchte (NCHI, NMR).

2025-01-15_073045.png

Ursache dafür ist, dass in Ages! nicht nach "Events" und "Facts" differenziert bzw. in der Eingabemaske beides vermischt wird.

"1 RESI Stadt, Straße" ist nicht erlaubt, stattdessen leitet RESI nur eine beschreibende Sequenz ein, in der "2 PLAC Stadt" und "2 ADDR Straße" benutzt werden müssen.

Ich setze mich seit etlichen Jahren mit dem Thema GEDCOM-Validierung und den Standards auseinander, daher kommt der ungültige Konstrukt bei mir nicht vor. Derlei Dinge meldet der bekannte GEDCOM-Validator, ich kann nur empfehlen, dass sich Anwender (die GEDCOM importieren oder weitergeben wollen) damit rechtzeitig auseinander setzen.

Kommen wir nochmal zu "AGNC" (Agency), zuständiges Amt, Behörde oder whatever. Beispiele bei mir:

1 MARR
2 DATE 18 JUL 1897
2 PLAC Gleiwitz O.S. (Gliwice)
2 AGNC Kirche Allerheiligen

oder:
1 DEAT
2 DATE 18 FEB 1945
2 PLAC Samland, Ostpreussen
2 AGNC Feldlazarett 1/572

AGNC hat je nach Kontext unterschiedliche Bedeutungen, kann mitunter mit "ADDR" ersetzt werden, was aber dann nicht unbedingt passt.
Ob man "AGNC" im Klartext nun mit "Agentur", "Zuständige Behörde", "...Amt" oder "Kirche" ausschreibt, führt je nach Kontext immer wieder zu eigenartigen Sprachkonstrukten.

Bei Ausbildung / Abschluss benutzt:
"2 AGNC Universität Hamburg".

Oder Taufe:
1 CHR
2 DATE 2 APR 1938
2 PLAC Hamburg Eimsbüttel
2 AGNC Christuskirche

Selbst habe ich "AGNC" daher stark reduziert, es gibt (außer Kommentaren) keine andere Möglichkeit es in GEDCOM anders auszudrücken.

Dann kann dir doch eigentlich egal sein, was Ahnenblatt aus dem Import macht ...

Das hatte ich bereits ausgedrückt. Aber hier gilt, dass (im späteren GEDCOM-Export) erhalten werden muss, was ein Anwender, mit welcher Software auch immer ausdrücken wollte oder konnte. Bei Compgen wird mit der Zeit vieles davon unterstützt.
Ein Wechsel zu Ahnenblatt müsste ich mir deswegen schon sehr überlegen.

Gruß Joachim

[Krause]

@Joachim,

Ich glaube deine Erwartungen an Ahnenblatt sind zu hoch. Dirk hat im Forum bereits mehrfach bekundet, dass Ahnenblatt nicht den vollständigen Gedcom Standard unterstützt und auch den aktuellen neuen Gedcom Standard in absehbarer Zeit nicht unterstützen wird. Als Einmann Programmierer kann und will er das offensichtlich nicht.

[Jo301]

@Krause,

Ich glaube deine Erwartungen an Ahnenblatt sind zu hoch. Dirk hat im Forum bereits mehrfach bekundet, dass Ahnenblatt nicht den vollständigen Gedcom Standard unterstützt...

bisher war es so, dass alle GEDCOM-Infos (Tags) in die Ahn-DB eingelesen wurden (Import), auch wenn sie nicht verarbeitet wurden oder editierbar waren. Sie wurden aber 1:1 wieder in GEDCOM reproduziert (Export). Das klappt nun nicht mehr, durch eine "Optimierung".
Meine Erwartung ist eigentlich nur, dass das bisherige Verhalten beibehalten wird. Die Welt außerhalb verarbeitet eben GEDCOM.

... und auch den aktuellen neuen Gedcom Standard in absehbarer Zeit nicht unterstützen wird.

Das ist auch nicht notwendig, solange sich GEDCOM v7 nicht ausreichend etabliert hat bzw. die v5.5.1 noch allgemein akzeptiert wird.

... Als Einmann Programmierer kann und will er das offensichtlich nicht.

Das verstehe ich aus eigener Berufserfahrung sehr gut. Bei Ages! war es ebenso eine Einmannfirma und der Autor hat den Support vor Jahren sang- und klanglos eingestellt oder hat es müssen. Beim Programmieren muss man schon mit seinen Ressourcen haushalten, aber es gelingt oft nicht.

Gerade für solche Fälle ist ein GEDCOM-Export mit möglichst wenigen applikationsspezifischen _Tags und keine unnötige Wandlung in Kommentare essentiell. Ich möchte mit GEDCOM kommen als auch wieder gehen können, falls es denn notwendig wird. Das ist der einzigste Grund, warum ich mir einen Wechsel gerade sehr überlegen muss (obwohl ich mich von Ages! gern lösen möchte).

Ansonsten wünsche ich allen Beteiligten alles Gute und Gesundheit!