Fehlende Anzeige der I-Nummer in Ahnenblatt4

[Deleted User 8441]

Ich habe da gerade vermutlich einen Fehler von AB entdeckt. Da ich mit 3.6 arbeite stelle ich das auch nur dort nach.
Man lade 2.ahn, nur eine Person angelegt.
Man füge 1.ahn hinzu nur eine Person angelegt.
Und speichere das Ergebnis als 2.ged ab.

Und siehe da mehrere gleiche RINs!

Gruß

Martin

[Jo301]

Eine andere Frage habe ich mir selbst gerade beantwortet.
Ahnenblatt bildet die RIN in 1:1-Beziehung aus INDI und baut sie beim Export als GEDCOM ein (linke Seite).
Meine Software akzeptiert das danach, obwohl sie RIN weder liefert noch benötigt.
Es gibt aber eine andere Feinheit die bei Re-Import angemeckert wird, aber ignoriert werden kann und hier erstmal keine Rolle spielt.

2024-06-30_203803.png

[Fridolin]

Ich habe da gerade vermutlich einen Fehler von AB entdeckt. Da ich mit 3.6 arbeite stelle ich das auch nur dort nach.

Ich kann das Problem in AB 4.09 nachstellen: Die INDIs sind in Ordnung, die RIN der hinzugefügten Person ist aber nicht um ein X erweitert und darum identisch mit einer der ursprünglichen Personen. Zufällig sind es die beiden Personen, die sowieso auch namentlich identisch sind - aber das ist bei weitem kein Grund, eine identische RIN zu vergeben; die sollte wenigstens eindeutig sein. Das ist nicht gut.

... Ahnenblatt bildet die RIN in 1:1-Beziehung aus INDI ...

Leider beim Sonderfall des Hinzufügens einer zweiten Ahnen-Datei leider nicht. Da ist INDI XI1, RIN aber I1.

[Deleted User 8441]

Ich kann das Problem in AB 4.09 nachstellen: Die INDIs sind in Ordnung, die RIN der hinzugefügten Person ist aber nicht um ein X erweitert und darum identisch mit einer der ursprünglichen Personen. Zufällig sind es die beiden Personen, die sowieso auch namentlich identisch sind - aber das ist bei weitem kein Grund, eine identische RIN zu vergeben; die sollte wenigstens eindeutig sein. Das ist nicht gut.

Ja, gut ist das nicht. Ich möchte gar nicht daran denken, zu welchen Fehlern das bei mir in der Vergangenheit geführt hat. Bin mal gespannt ob Dirk seine Meinung noch ändert und es für die 3.6 noch eine Fehlerbeseitigung und eine Berichtigung gibt?

Die Namen sind übrigen unterschiedlich, aber das spielt hier keine Rolle.

Gruß

Martin

[DirkB]

Ich selbst bevorzuge das "Goto", es ist ein Klick weniger und ergonomischer.

Ob man nun auf das Symbol "Gehe zu" klickt oder auf das Symbol "Kennzeichen" ist beides nur ein Mausklick.
Alternativ die Tastenkombinationen Strg+G und Strg+X.

- Dirk

[Fridolin]

Die Namen sind übrigen unterschiedlich, aber das spielt hier keine Rolle.

Die Namen derer, die dieselbe RIN bekommen, sind bei mir in 4.09 nach deiner Rezept-Vorgabe beide Male "Erste Person".

[DirkB]

Hallo Martin,

...
Und siehe da mehrere gleiche RINs!

Danke für den Fehlerhinweis und die Beispieldateien.
Ich werde mal schauen, dass ich das korrigiert bekomme.

- Dirk

[Jo301]

Alternativ die Tastenkombinationen Strg+G und Strg+X.

Klicken?, ohnehin nur wenn man muss
Danke für den Hinweis auf Strg+X, das macht mich hoch zufrieden ("Berufskrankheit").
Ich hatte bisher nur Strg+F im Fokus. Wobei ein Strg-G alternativ auf Nummer schon gut wäre, man hätte die alphabetische Namensliste und könnte trotzdem direkt RIN/INDI ansteuern.

Nachdem ich hier parallel geschaut / bei Youtube war, sehe ich bestätigt, dass RIN aus INDI übernommen wird und "sonne Nummer" auch als "I1234" angezeigt werden kann, prima. Allerdings verstehe ich die Absicht der parallelen Verwendung von RIN und INDI nicht und es vermischt sich.

Wird in Ahnenblatt nach GEDCOM-Import dann primär mit RIN weitergearbeitet und INDI trotzdem weitergepflegt?

Sollte man eine Zeit mit Ahnenblatt neu erfassen und dann doch die Daten anderweitig nutzen, wird sicher beim GEDCOM-Export INDI aus RIN gebildet.

Worin steckt bitte der konzeptionelle Gedanke dahinter? Wenn man nur ein Primärkennzeichen (z.B. INDI) hätte, könnten doppelte RIN / Inkonsistenzen garnicht vorkommen. Bei RIN ist offenbar eine Herkunftsangabe (AB: wie bei MH: ...) möglich, das ist für verarbeitende Programme nützlich.
Wobei ich noch nicht gesehen habe, dass es wirklich einen Nutzen gehabt hätte.

Ich kenne fremde GEDCOM-Dateien, die über viele Jahre mit mehreren Genealogie-Programmen gepflegt wurden. Das jeweils neue Programm führt die alten RIN oftmals nicht weiter und es entstehen schwer verständliche historische Vermengungen, quasi Schichten von Ausgrabungen.

Ehe ich auf Ahnenblatt wechsle, möchte ich schon gern verstehen, wie meine kostbaren Daten zukünftig behandelt werden.
Es wäre der Super-GAU nach vielen Jahren Arbeit, wenn in meinem OFB irreparable Brüche entständen, z.B. durch Mergen von Teilmengen.

[Deleted User 8441]

Die Namen sind übrigen unterschiedlich, aber das spielt hier keine Rolle.

Die Namen derer, die dieselbe RIN bekommen, sind bei mir in 4.09 nach deiner Rezept-Vorgabe beide Male "Erste Person".

Hallo Fridolin,
in 1.ahn heißt die Person: Erste, Person
in 2.ahn heißt die Person: Zweite, Person.

Gruß
Martin

[ahnenarmin]

Hallo Dirk,
auf Grund des gemeldeten Problems habe ich meine Datei (ca. 19000 Personen) untersucht (über Export als csv-Datei.

"#REFN" ist immer korrekt, hier werden bei Doppelung (eine unterschiedliche Anzahl von) X eingefügt
"RIN": Hier werden nicht immer die X eingefügt, so dass es Doppelungen bzw. mehrfach eine identische RIN (ohne X) gibt.

Dabei habe ich etwas eigenartiges festgestellt:
Bei 1 Person (von ca. 19000) wird #REFN und RIN falsch ausgewiesen.
Es erscheint ein großes O mit einem Accent (anstatt des @) bei 'REFN bzw. als zusätzliches Zeichen bei RIN:
Nachstehend die Zeile aus der csv-Datei:
ÓI4080@ Josef Leitermann Franz Leitermann @I4055@ Magdalena Kohlbeck @I3624@ AB:ÓI4080

Gruß
Armin

PS:
[AB:ÓI4080] erscheint auch im Navigator, wenn aktiviert

in der GEDCOM mit Editor geöffnet:
0 I4080@ INDI
1 RIN AB:ÓI4080

[DirkB]

Allerdings verstehe ich die Absicht der parallelen Verwendung von RIN und INDI nicht und es vermischt sich.

Die INDI-Nummern in einer GEDCOM-Datei sind von der Sache her temporär. Das Zielprogramm merkt sich diese Info in den seltensten Fällen.
Es haben sich aber Anwender gemeldet, die in Ihrer alten Software eine Datensatznummer hatten (aufgrund einer verwendeten Datenbank), die immerhin in Form einer INDI-Nummer mit einem vorangestellten "I" Verwendung findet. Da fing ich an die INDI-Nummern dauerhaft zu merken (vielleicht ist Ahnenblatt sogar das einzige Programm, das das so macht - vorgeschrieben ist das nicht).

Da es nicht wirklich ein "GEDCOM-Datenfeld" ist, habe ich das System vom FamilyTreeBuilder von MyHeritage übernommen und das als RIN mit vorangestelltem "AB:" verwendet. Überraschenderweise kann der FamilyTreeBuilder seit dem keine Ahnenblatt-GEDCOMs importieren (siehe: https://www.ahnenblatt.de/probleme-mit- ... e-builder/).
Man kann sich hinter jedem Personennamen diese RIN oder eine eigene benutzerdefinierte Kennung (= REFN) anzeigen lassen und auch danach suchen.

Wird in Ahnenblatt nach GEDCOM-Import dann primär mit RIN weitergearbeitet und INDI trotzdem weitergepflegt?

Vorrangig intern die INDI - die RIN wird anscheinend nicht weitergepflegt, wie Martin feststellte (wird von mir noch korrigiert).

- Dirk

[Fridolin]

Die Namen sind übrigen unterschiedlich, aber das spielt hier keine Rolle.

Die Namen derer, die dieselbe RIN bekommen, sind bei mir in 4.09 nach deiner Rezept-Vorgabe beide Male "Erste Person".

Hallo Fridolin,
in 1.ahn heißt die Person: Erste, Person
in 2.ahn heißt die Person: Zweite, Person.

Es ist ja nun wirklich ein Nebenschauplatz, aber ich versuche im Zusammenhang mit Fehlermeldungen gern präzise zu sein. Und da stellt sich mir die Sachlage so dar:
Die von dir hochgeladene Datei 2.ahn enthält zwei Personen: Erste Person und Zweite Person (schau dir dazu mal die Inseln an), die gleichzeitig bereitgestellte Datei 1.ahn enthält eine Person: Erste Person. Wenn ich beide Dateien verbinde, habe ich drei Personen, von denen zwei "Erste Person" heißen - und dann überschneiden sich bei mir die RIN der beiden "Erste Person".

[Deleted User 8441]

@ Fridolin hast recht. In der 2.ahn ist auch noch die erste Person.
Gruß
Martin

[Jo301]

Die INDI-Nummern in einer GEDCOM-Datei sind von der Sache her temporär. Das Zielprogramm merkt sich diese Info in den seltensten Fällen.

Dem stimme ich nicht zu. Das mag stimmen, wenn das Zielprogramm eine Konvertierung in ein Datenbankformat vornimmt, wie Ahnenblatt.

Bei den Programmen, die in GEDCOM speichern / es als Primärformat nutzen ist es nicht so.
Ergo müsste INDI die Primärkennung sein und schlussendlich (ohne großartige Änderungen) bleiben. Ahnenblatt macht daraus RIN und speichert INDI dazu.
Mit RIN können aber manche GEDCOM-Applikationen nichts anfangen und lassen sie "anstandshalber" drin.
So ergibt sich in alten GEDCOM-Files mitunter ein Sammelsurium von AB: / MH: ... Tags.
Du schreibst ja selbst, dass MyHeritage FTB die AB: RIN "nicht mag" / nicht importieren kann.

Es haben sich aber Anwender gemeldet, die in Ihrer alten Software eine Datensatznummer hatten (aufgrund einer verwendeten Datenbank), die immerhin in Form einer INDI-Nummer mit einem vorangestellten "I" Verwendung findet. Da fing ich an die INDI-Nummern dauerhaft zu merken (vielleicht ist Ahnenblatt sogar das einzige Programm, das das so macht - vorgeschrieben ist das nicht).

Im Prinzip ist das gut, macht aber den gegenseitigen Austausch nicht einfacher. Weil die Welt eben aus diversen Design-Entscheidungen bei Genealogie-Apps besteht. Das bedeutet, dass man es wahrscheinlich nicht allen recht machen kann und die Angelegenheit komplex ist.
...

Man kann sich hinter jedem Personennamen diese RIN oder eine eigene benutzerdefinierte Kennung (= REFN) anzeigen lassen und auch danach suchen.

Ist ja alles "ganz schön", läuft aber darauf hinaus, dass man dann bei Ahnenblatt bleibt und namhafte GEDCOM-Importer (wie Online-OFB) sehr tolerant sein müssen oder etliches einfach "in den Skat drücken".

Ich kam noch nicht dazu meine Anforderungen an Ahnenblatt aufzulisten und zu bewerten.
So ein Evaluation-Prozess dauert immer seine Zeit.

Wird in Ahnenblatt nach GEDCOM-Import dann primär mit RIN weitergearbeitet und INDI trotzdem weitergepflegt?

Vorrangig intern die INDI - die RIN wird anscheinend nicht weitergepflegt, wie Martin feststellte (wird von mir noch korrigiert).

Also doch INDI, hmmm... das unterstützt dann doch meine Meinung dazu.
Man kommt an GEDCOM mit der File-bezogenen INDI eben nicht vorbei.
Klar, es gibt noch _UID aber das ist zu global gedacht und löst die Probleme auch nicht... lassen wir hier beiseite.

Gruß
Jo301