Gedcom-Datei parsen

[Jumpy]

Aus der verlinkten Spezi:

Zitat:

Eine GEDCOM Übertragung beinhaltet eine Datenbank in Form eines sequenziellen Datenstromes aus
mit einander verbundenenDatensätzen. Ein Datensatz wird durch eine Abfolge von gekennzeichneten
Zeilen variabler Länge repräsentiert, die in einer Hierarchie angeordnet sind. Eine Zeile besteht immer aus der Nummer einer Hierarchieebene, einem Kennzeichen (Tag) und optional einem Wert. Eine Zeile kann außerdem eine Querverweis-ID oder Querverweiszeiger beinhalten.
[...]
Eine Reihe von einer oder mehr Zeilen erzeugt einen Datensatz. Der Anfang eines neuen
Datensatzes wird durch eine Zeile gekennzeichnet, die mit der Ebenennummer 0 (Null) beginnt.

Nur weil es um Stammbäume geht und der Inhalt der Datei aussieht wie eine Baumstruktur, erhöht es mMn nur die Komplexität, das beim einlesen unbedingt in eine Baumstruktur zu schaufeln, da in dem Baum dann Äpfel, Birnen und Nüsse hängen (Familien, Personen, Beziehungen, Sourcen, ...) die anschließend extra wieder gepflückt und auf ihre Körbe verteilt werden müssen. Da kann ich die doch direkt so wie die von der Palette/der gemischten Kiste (der Datei) kommen auf die Körbe verteilen.

Es werden doch einfach nur Datensätze(!) geschickt die u.U. miteinander verknüpft sind (über die Querverweis ID) und deren Inhalte/Daten hierarchisch angeordnet sind. Sprich, wenn dann haben die einzelenen Datensätze eine Baumstruktur aber nicht unbedingt die Datei (Hat der LKW eine Baumstruktur?).

Irgendwann müssen doch die konkreten Objekte für die Geschäftslogik erzeugt werden, was ist da der Vorteil der Baumstruktur bzw. das ich mir vorher die Mühe mache "abstrakte" (im Sinne von unkonkrete) Objekte in Baumstruktur zu erzeugen? Das der Zugriff einfacher ist?

[Sir Rufo]

@Jumpy

Der Inhalt der Datei ist wie ein Baum aufgebaut. Ich überführe nur den Inhalt 1:1 in eine entsprechend auswertebare Struktur.
Mehr mache ich nicht.

Ausserdem muss man im Zweifelsfall erst die gesamte Datei ausgelesen haben, um auf die Referenzen auch zugreifen zu können.

Hier ein Auszug aus https://code.google.com/p/geddiff/so...ples/royal.ged und zeigt einen kompletten Einzel-Satz (Zeile 41)

Code:

0 @I1@ INDI
1 NAME Victoria  /Hanover/
1 TITL Queen of England
1 SEX F
1 BIRT
2 DATE 24 MAY 1819
2 PLAC Kensington,Palace,London,England
1 DEAT
2 DATE 22 JAN 1901
2 PLAC Osborne House,Isle of Wight,England
1 BURI
2 PLAC Royal Mausoleum,Frogmore,Berkshire,England
1 REFN 1
1 FAMS @F1@
1 FAMC @F42@

Wie bitteschön, soll denn jetzt die Referenz zu @F1@ und @F42@ behandelt werden? Die kommen in der Datei erst ein paar Zeilen später ...

Ab Zeile 23285 kommt

Code:

0 @F1@ FAM
1 HUSB @I2@
1 WIFE @I1@
1 CHIL @I3@
1 CHIL @I4@
1 CHIL @I5@
1 CHIL @I6@
1 CHIL @I7@
1 CHIL @I8@
1 CHIL @I9@
1 CHIL @I10@
1 CHIL @I11@
1 DIV N
1 MARR
2 DATE 10 FEB 1840
2 PLAC Chapel Royal,St. James Palace,England

[Jumpy]

Ich verstehe glaub ich wie du das meinst. Aber wenn du jetzt anfängst die Objekte der Geschäftslogik zu erstellen (also der nächste Schritt) machst du das ja dann in dem du dem Baum Schritt für Schritt abgehst. Hast du dann nicht das selbe Problem, wenn du an die Stelle kommst, dass die "konkreten" Objekte auf die verweisen wird noch nicht existieren weil die "abstrakte" Objekte mit der Info darüber im Baum noch ein paar Zweige tiefer hängen?

OK, du wirst sie leichter finden und nach Bedarf erzeugen können.


Wobei ich gerade überlege (ich hab allerdings keine Ahnung von Genealogie-Programmen) dass es eh nicht möglich(?)/einfach ist diese Objekte OOP-mäßig miteinander zu verknüpfen (assoziieren?). Hätte jetzt gedacht, dass die Objekte sortenrein in entsprechenden Collections liegen und in anderen Objekten gerade mal die Referenz-ID auf diese gespeichert wird und man dann die Collection fragen muss: Gib mir mal die Familie mir der ID F12, oder so. (Zumindest die Objekte auf Ebene 0).
Objekte auf höheren Ebenen würden wahrscheinlich mit dem übergeordneten Objekt erzeugt und im übergeordneten Objekt "verwaltet". Referenziert würden die glaub ich ala @I12!P2@ oder so, hab da aber bisher kein konkretes Beispiel für gesehen nur die Spezi so verstanden, das es das geben könnte.

[Sir Rufo]

@Jumpy

Nein habe ich nicht, denn dafür wird bei einem Referenz-Verweis auch ein TRefNode erstellt mit direktem Zugriff auf die referenzierte Node (müsste noch leicht verfeinert werden).

Auf jeden Fall kann man gleich prüfen, ob man diese Referenz schon gespeichert hat, wenn nicht speichert man die.

[Sir Rufo]

Ich glaube ich habe bei der Beschreibung des Zeilenaufbaus einen kleinen Fehler gemacht.

So ist die korrekte Logik für die Zeile

Code:

<LEVEL> -- <SEP> -+- <TYPE> -- <SEP> -+- <DATA> ---+- <EOL>
                  |                   +- <REFTO> --+
                  +- <REF> -- <SEP> -- <TYPE> ------- <EOL>

Wenn die Zeile also eine Referenz ist

Code:

0 @foo@ INDI

dann folgen keine Daten mehr.

Wenn die Zeile auf eine Referenz verweist, dann beinhalten die Daten die Referenz

Code:

0 INDI @foo@

Das müsste also alles falsch sein

Code:

0 @foo@ INDI @foo@
0 @foo@ INDI Some data
0 INDI @foo@ and some data

[Jumpy]

Zitat von Sir Rufo:

@Jumpy
Nein habe ich nicht, denn dafür wird bei einem Referenz-Verweis auch ein TRefNode erstellt mit direktem Zugriff auf die referenzierte Node (müsste noch leicht verfeinert werden).

Auf jeden Fall kann man gleich prüfen, ob man diese Referenz schon gespeichert hat, wenn nicht speichert man die.

Na gut, das Problem ist schon da, aber du löst es bereits bevor es zum Problem wird.

Das kommt ja letztlich daher, dass die Datensätze in beliebiger Reihenfolge in der Datei stehen können und daher dass zirkuläre Referenzen erlaubt sind, d.h. es wäre gar nicht möglich die Daten so zu speichern, dass man daraus die Objekte in einer Reihenfolge erzeugt die bewirkt, das Referenzierte Objekte bereits zuvor erstellt werden.

----------

Kann das sein das

Code:

0 INDI @foo@

auch falsch ist?

Code:

1 INDI @foo@

aber OK?

Muss der Eintrag auf Ebene 0 nicht eine Ref sein, entspricht doch quasi einem Primary Key, den jeder Datensatz braucht?

[Sir Rufo]

Code:

0 INDI @foo@

Ist nicht falsch, aber in dem Kontext unsinnig.

Code:

0 NOTE @foo@

macht schon mehr Sinn

[hansklok]

Zitat von Sir Rufo:

Ausserdem muss man im Zweifelsfall erst die gesamte Datei ausgelesen haben, um auf die Referenzen auch zugreifen zu können.

Da hat Sir Rufo recht!

Zitat von Jumpy:

Wobei ich gerade überlege (ich hab allerdings keine Ahnung von Genealogie-Programmen) dass es eh nicht möglich(?)/einfach ist diese Objekte OOP-mäßig miteinander zu verknüpfen (assoziieren?). Hätte jetzt gedacht, dass die Objekte sortenrein in entsprechenden Collections liegen und in anderen Objekten gerade mal die Referenz-ID auf diese gespeichert wird und man dann die Collection fragen muss: Gib mir mal die Familie mir der ID F12, oder so. (Zumindest die Objekte auf Ebene 0).
Objekte auf höheren Ebenen würden wahrscheinlich mit dem übergeordneten Objekt erzeugt und im übergeordneten Objekt "verwaltet". Referenziert würden die glaub ich ala @I12!P2@ oder so, hab da aber bisher kein konkretes Beispiel für gesehen nur die Spezi so verstanden, das es das geben könnte.

Genauso ist es. Es werden nur die Verweiszeiger, also die ReferenceIDs gespeichert. Alle Hauptobjekte werden in Collections verwaltet (INDI, FAM, SOUR, OBJ, NOTE).

Zitat von Sir Rufo:

Code:

0 INDI @foo@

Ist nicht falsch, aber in dem Kontext unsinnig.

Code:

0 NOTE @foo@

macht schon mehr Sinn

Sir Rufo, da hast Du wiederum recht, allerdings schreibt der Standard explizit folgende Notation für Hauptobjekte außer HEAD und TRLR vor:

0 @I123@ INDI
0 @F123@ FAM
0 @N123@ NOTE
0 @S123@ SOUR
0 @O123@ OBJ

Header und Trailer (kommen einmalig pro Datei vor!):
0 HEAD
0 TRLR

Ich hänge mal den übersetzten Xojo-Code (Basic) ran. Allerdings kommt es zu Exceptions (habe das kommentiert). Auch, was nicht geht. Vielleicht findet Ihr den Fehler.
Achso: Xoxo kennt keine StringBuilder-Klasse. ich habe jetzt einfach einen String definiert und ihm immer wieder die neuen Teile angehängt. Das ist doch dasselbe, oder? Siehe OutputNode().

Danke für diesen angeregten, spannenden Thread.