Seite 2 von 3

Verfasst: 08.05.2019, 19:12
von Jürgen T.
Es könnte daran liegen, dass der Ort "Wuppertal ???" bei Dir in der Zeile "Resi" gespeichert wird/ist, er aber in einer zusätzlichen Zeile "PLAC" stehen müsste.

Verfasst: 08.05.2019, 19:16
von Jürgen T.
Hast Du noch die beiden Ursprungs-GEDCOM-Dateien?
Ob Ahnenblatt das seinerzeit falsch eingelesen hatte, oder ob die Ursprungsdateien schon diesen Unterschied aufwiesen wäre wichtig zu wissen.

Verfasst: 08.05.2019, 20:24
von Gast
Hallo Jürgen,

Ich melde mich morgen wieder. Was du da schreibst, könnte Sinn machen.
Ja, die original Ahn Data Gedcom Datei habe ich.

Gruß,
Horstvwa2

Verfasst: 08.05.2019, 20:26
von Fridolin
Beispiel aus der GEDCOM-5.5.1-Spezifikation: (siehe unten!)

Code: Alles auswählen

1 RESI
 2 ADDR 73 North Ashley 
  3 CONT Spencer, Utah UT84991 
 2 DATE from 1900 to 1905
Wie Jürgen T. schon gesagt hat, entspricht das dem Standard.

Ahnenblatt 3.0 beta macht das insgesamt so (ein bisschen strukturierter):

Code: Alles auswählen

1 RESI
2 PLAC München (Ort als Teil des Fakts)
2 DATE 20 OCT 2008
2 ADDR Hirschgasse
3 CITY München (Ort als Teil der Adresse)
3 POST 8000
Schwarz sehen muss man deswegen nicht. Kann man notfalls auch von Hand korrigieren, indem man eine GEDCOM erzeugt und von Hand die RESI-Einträge mit einem Editor durchschaut. Nur dann bitte die Ziffern alle am Zeilenanfang schreiben, nicht eingerückt, wie im Beispiel oben! Ist doch einen Versuch wert!

Wenn das in der ursprünglichen Datei falsch war, wäre das für Dirk die Möglichkeit, AB für die Zukunft fehlertoleranter zu machen - wäre doch prima!

Mit "Datum" hatte ich übrigens einfach die Einzahl von "Daten" gemeint - keinen Termin. Aber ich gebe zu, dass das missverständlich war, weil der Begriff selten so benutzt wird. (https://de.wikipedia.org/wiki/Daten)

Aber auch wenn wir jetzt dem Problem auf der Spur sind: In AB 2.99 wirst du das auch korrigiert nicht bearbeiten können - nur in AB 3.0 (beta).

Frido

Verfasst: 08.05.2019, 21:01
von Fridolin
Entschuldigung, ein Fehler von mir:

Das erste Beispiel oben mit der persönlichen Wohnanschrift aus Utah ist _nicht_ Teil der Spezifikation! Jörb Daub hat es in seine Übersetzung des Standards zusätzlich mit aufgenommen - aber ohne Quellenangabe. Es erhebt also keinen Anspruch auf irgend eine Autorität!

Frido

Verfasst: 09.05.2019, 10:20
von HoWo
Jürgen T. hat geschrieben:Es könnte daran liegen, dass der Ort "Wuppertal ???" bei Dir in der Zeile "Resi" gespeichert wird/ist, er aber in einer zusätzlichen Zeile "PLAC" stehen müsste.
Hallo Jürgen,

ich habe die Original AHN DATA Gedcom Datei mal in AB eingelesen und wieder ein Personenblatt erstellt (es wurde hierbei noch nichts mit AB verändert!)
Diese Original Datei habe ich auch wieder mit dem Editor geöffnet und den Kopf der Gedcom Datei und den betreffenden Ausschnitt zum Vergleich abgebildet.

Im schon vorher, in diesem Post abgebildeten Ausschnitt, wurden in AB schon Korrekturen/Änderungen vorgenommen.

Nochmal:
Jürgen T. hat geschrieben:Es könnte daran liegen, dass der Ort "Wuppertal ???" bei Dir in der Zeile "Resi" gespeichert wird/ist, er aber in einer zusätzlichen Zeile "PLAC" stehen müsste.
Das stellt sich für mich so dar, daß in der Original AHN DATA Gedcom Datei bei PLAC jeweils der Geburts- und dann Taufort eingefügt ist. Und in RESI eben der Wohnort.


Gruß,
Horst

Verfasst: 09.05.2019, 10:52
von HoWo
Fridolin hat geschrieben:Beispiel aus der GEDCOM-5.5.1-Spezifikation: (siehe unten!)

Code: Alles auswählen

1 RESI
 2 ADDR 73 North Ashley 
  3 CONT Spencer, Utah UT84991 
 2 DATE from 1900 to 1905
Wie Jürgen T. schon gesagt hat, entspricht das dem Standard.

Ahnenblatt 3.0 beta macht das insgesamt so (ein bisschen strukturierter):

Code: Alles auswählen

1 RESI
2 PLAC München (Ort als Teil des Fakts)
2 DATE 20 OCT 2008
2 ADDR Hirschgasse
3 CITY München (Ort als Teil der Adresse)
3 POST 8000
Schwarz sehen muss man deswegen nicht. Kann man notfalls auch von Hand korrigieren, indem man eine GEDCOM erzeugt und von Hand die RESI-Einträge mit einem Editor durchschaut. Nur dann bitte die Ziffern alle am Zeilenanfang schreiben, nicht eingerückt, wie im Beispiel oben! Ist doch einen Versuch wert!

Wenn das in der ursprünglichen Datei falsch war, wäre das für Dirk die Möglichkeit, AB für die Zukunft fehlertoleranter zu machen - wäre doch prima!

Mit "Datum" hatte ich übrigens einfach die Einzahl von "Daten" gemeint - keinen Termin. Aber ich gebe zu, dass das missverständlich war, weil der Begriff selten so benutzt wird. (https://de.wikipedia.org/wiki/Daten)

Aber auch wenn wir jetzt dem Problem auf der Spur sind: In AB 2.99 wirst du das auch korrigiert nicht bearbeiten können - nur in AB 3.0 (beta).

Frido
Hallo Frido,

danke für Deine Ausführungen.

Ich befürchte halt, daß, wenn ich das alles händisch korrigiere, sich womöglich irgendwo dabei ein Fehler einschleicht der evtl. übersehen wird und mir meine lange Arbeit verfälscht. Mit einer Kopie würde ich allerdings sowieso arbeiten.

Meinst Du, Dirk schaut sich diesen Post an, oder wie meinst Du das?

Gruß,
Horst

Verfasst: 09.05.2019, 12:35
von Fridolin
Dirk schaut immer mal wieder in unser Forum. Was er aber alles mitbekommt und ob er in jeden Gesprächsteil schaut, weiß ich nicht. Es mag nicht schaden, ihm eine kurze eMail zu schreiben mit dem Verweis auf dieses Gespräch.

Die Adresse deines Startbeitrags: http://www.ahnenblattportal.de/viewtopi ... 7314#57314. Findet man immer mit einem Rechtsklick auf das kleine Dokumentensymbol vor dem "Verfasst am:"-Text. Die eMail-Adresse von Dirk ist in der Info des Programms versteckt: ? > Info.

Dass dir das händische Reparieren heikel vorkommt, kann ich nachvollziehen. Ich hätte keine Sorgen mit einem gescheiten Editor wie notepad++, mit dem man auch Kontrolle über den Zeichensatz und den Zeilenumbruch hat.

Frido

Verfasst: 09.05.2019, 15:50
von HoWo
Ja, danke, Frido. Habe Dirk mal angemailt.

Verfasst: 09.05.2019, 17:05
von HoWo
Ich "spiele" gerade etwas mit AB 3.0 Beta herum - ist schon toll, was da alles möglich ist :up: :up:

Dabei ein mir (noch?) unerklärlicher Effekt:

Wenn ich z.B. die von mir bisher als Beispiel für mein "Wohnort Problem" genutze Person aufrufe, dann steht unter DATEN bei WOHNORT nichts im Eingabefeld hierfür. Aber wenn ich von dieser Person ein PERSONENBLATT erstelle, ist der WOHNORT mit den störenden, so nicht gewünschten Einträgen, gefüllt.

Gebe ich aber jetzt bei dieser Person den von mir gewünschten Wohnort-Eintrag ein, so taucht beim neuen Personenblatt-Ausdruck ab sofort der geänderte, richtige Eintrag auf. Hat jemand eine Erklärung für dieses Verhalten ??

@ Frido und Alle
Findet Ihr, daß man AB 3.0 Beta inzwischen als vollwertig und stabil nutzen könnte?

Die Familiendatei *.ahn bleibt ja auch bei der zukünftigen, fertigen Version uneingeschränkt nutzbar.

Verfasst: 10.05.2019, 00:02
von Fridolin
HoWo hat geschrieben:@ Frido und Alle
Findet Ihr, daß man AB 3.0 Beta inzwischen als vollwertig und stabil nutzen könnte?
Ja, das Format der *.ahn-Datei ist bei der 2.99 und der 3.0-beta gleich. Man kann mit den Daten wechseln zwischen beiden Versionen.

Aber die obige Frage stellst du am falschen Tag! Bis gestern hätte ich sie uneingeschränkt bejaht: Seit über einem Jahr im Praxistest, ständig nachgebessert und korrigiert, sicherlich tauglich für die praktische Arbeit, solange man sich daran hält, regelmäßige Backups aufzubewahren (meiner Meinung nach mindestens 1 Backup pro Update-Version - und zwar alle dauerhaft aufbewahren, nicht nur die letzte!).

Aber ein Bericht von gestern macht mich vorsichtiger: Da werden gerade Vornamen vertauscht beim Editieren. Wohl dem, der das sofort merkt! Holzauge, sei wachsam!

Ich bleibe trotzdem dabei - aber die 3.0-beta21 werde ich vermutlich überspringen. Ich war noch nicht dazu gekommen, sie zu installieren.

Frido

Verfasst: 10.05.2019, 13:40
von HoWo
Danke, Frido,

merke mir das.

Verfasst: 10.05.2019, 19:04
von DirkB
Hallo Horst,

Hier im Forum steht schon viel Richtiges.

Das GEDCOM-Konstrukt ...

1 RESI Wohnort

... ist so (laut GEDCOM-Standard) nicht zulässig und müsste ...

1 RESI
2 PLAC Wohnort

... heißen.

Nun ist aber Ahnenblatt ziemlich tolerant und verwirft kein "falsches" GEDCOM (könnte ja sein, dass das wieder in AhnData eingelesen werden soll). Wie Ahnenblatt dann programmintern mit solchen falschen Konstrukten umgeht, kann man natürlich nicht vorhersehen (auch ich nicht). Es ist auch müßig für alle denkbar falschen GEDCOM-Konstrukte programmtechnisch ein in allen Belangen korrektes Verhalten reinzuprogrammieren.

Hier also der Fall, dass der Wohnort im Personenblatt erscheint, sich aber nicht editieren lässt. Es kommt auch noch hinzu, dass beim Versuch den Wohnort zu editieren, dieser dann komplett verschwindet, danach also auch nicht mehr im Personenblatt erscheint.

Ich werde daher mal eine Logik ranprogrammieren, die den Wohnort korrigiert. Bei allen (anderen) Ereignissen werde ich das aber nicht vorsehen.

Für alle Mitleser:
Die Daten stammen aus diesem alten "Schätzchen" der Programmierkunst:
http://genwiki.genealogy.net/AHN-DATA

Gruß, Dirk

Verfasst: 11.05.2019, 10:27
von HoWo
Hallo Dirk,

erst mal herzlichen Dank für Deine Hilfsbereitschaft !

Mal abgesehen von Deiner vorgesehenen Änderung in AB, meine oben
HoWo hat geschrieben:... ein mir (noch?) unerklärlicher Effekt:

Wenn ich z.B. die von mir bisher als Beispiel für mein "Wohnort Problem" genutze Person aufrufe, dann steht unter DATEN bei WOHNORT nichts im Eingabefeld hierfür. Aber wenn ich von dieser Person ein PERSONENBLATT erstelle, ist der WOHNORT mit den störenden, so nicht gewünschten Einträgen, gefüllt.

Gebe ich aber jetzt bei dieser Person den von mir gewünschten Wohnort-Eintrag ein, so taucht beim neuen Personenblatt-Ausdruck ab sofort der geänderte, richtige Eintrag auf. Hat jemand eine Erklärung für dieses Verhalten ?? ...

geschilderte Beschreibung, kann doch das Problem, zumindest vorerst, überbrücken, oder ?