Ahnenblattportal

Hallo zusammen.

Seit geraumer Zeit setzte ich Ahnenblatt ein und bin damit wirklich sehr zufrieden. Besten Dank an dieser Stelle für die TOLLE Software!!

Da ich jetzt selber wieder mit dem Implemntieren angefangen habe, hier folgende Frage:

Gibt es eine API?
Am besten natürlich sowohl für die PlugIns als auch für die eigentliche Software.

Über reichhaltige Infos würde ich mich sehr freuen.
Falls es nicht für jedermanns Augen ist, halt einfach per pn melden.

Tolles WE noch.

Gruß Markus

Eine API im klassischen Sinne gibt es nicht. Man kann jedoch Plugins für Ahnenblatt als eigentständige Programme entwickeln, die auf (automatisch exportierte) Daten zugreifen.
In unserer Knowledge Base haben wir ein paar Artikel mit Informationen rund um die Plugins zusammengestellt: Nutzung von Plugins

Ansonsten ist natürlich ein Blick in die entsprechenden Threads zu den Plugins und ein ausprobieren dergleichen hilfreich, um die Möglichkeiten zu erahnen, die sich dadurch ergeben.
Marcus

Was mich interessieren würde: Gibt es für Java eine Möglichkit GEDCOM Files zu importieren (oder irgendwas was Ahnenblatt exportieren kann).

Ich wollte gern die Verteilten Tafeln als Plugin realisieren. Aber allein das einlesen der Personendaten ist - dank des ziemlich umständlichen GEDCOM Formates eine ziemlich undankbare Aufgabe.

Wieso kann man nicht ein einfacheres XML Basiertes Format erstellen. Selbst das GEDCOM-XML Format sieht ziemlich kompliziert aus.

Eigentlich brauch man doch nur 3 Typen: PERSON, ORT und EREIGNISS wobei letzteres einfach dazu dient Personen mit Personen bzw. Orten zu verbinden.
Aus Genealogen-Sicht muss es noch den Typ QUELLE geben. Der wird an das Ereignis gehängt um dieses zu bestätigen. Dann könnte man noch KOMENTARE als Typ definieren, den man dann an die 4 vorherigen Typen anhängen kann.
Das wars.

Flash hat geschrieben:
Wieso kann man nicht ein einfacheres XML Basiertes Format erstellen. Selbst das GEDCOM-XML Format sieht ziemlich kompliziert aus.

Weil's niemand braucht Um Daten auszutauschen helfen nun mal nur Formate weiter, die auch genutzt werden. Daher stammte wohl dann auch die Idee des Gedcom-XML-Kompromisses. So ganz unähnlich sind sich XML und Gedcom ja auch nicht.*
Ansosnten sind Exportformate umgesetzt, mit denen man weiterarbeiten kann (wie csv).

*Einer unser Pluginprogrammierer hat auch bewusst Gedcom-Dateien zum Einlesen genutzt. Da gibt es eine kleine Diskussion mit Jürgen (soweit ich mich erinnere). Ob das allerdings auch in Java umgesetzt wurde und weitergegeben wird, weiß ich nicht.

Ich hatte am Wochenede aber auch schon einmal überlegt die reinen Importfunktionen (und das Ablegen der Daten in einer sinnvollen Daten-Struktur) umzusetzen und bereit zu stellen. Aber ehrlich gesagt, glaube ich nicht, dass mir in nächster Zeit so langweilig wird, dass mich die Frickelarbeit reizen könnte
Falls doch melde ich mich - hoffe aber Dein Leidensdruck ist größer
Marcus

In welcher Sprache programmierst du?
Eventuell kann man ein SVN aufsetzen und die schmutzige Arbeit gemeinsam machen.

Da bin ich relativ offen. Ich will ein wenig mehr sinnvolles mal in Java machen - ergo bin da kein Profi, aber für Import-Routinen und Anlegen einer Datenstruktur sollte es schon reichen
Eigentlich wäre mir aber C näher ... Denkbar wäre auch Visual Basic, wobei ich aber bisher nur VBA (zur Office-Programmierung) nutze.
Marcus

Ich könnte eine Delphi-Unit anbieten, die eine Unicode-CSV in ein Ahnendaten-Objekt (statt einem mehrdimensionalen Array) einließt und wieder abspeichert.
Sie ist zwar nicht ganz perfekt abgerundet, aber richtig angewendet funktioniert sie ganz gut.

Hallo,

Marcus hat geschrieben: *Einer unser Pluginprogrammierer hat auch bewusst Gedcom-Dateien zum Einlesen genutzt. Da gibt es eine kleine Diskussion mit Jürgen (soweit ich mich erinnere). Ob das allerdings auch in Java umgesetzt wurde und weitergegeben wird, weiß ich nicht.

ja, ich hatte anfangs die GEDCOM-Ausgabe benutzt, kam dann allerdings schnell auf die (wie ich finde) praktischere CSV-Ausgabe.
Ich lese die Daten in ein zweidimensionales Array mit Visual Basic 2008 (vb.net) ein. Java kann ich nicht.
Ich bin natürlich gerne bereit, die Einleseroutine weiter zu geben, aber ich denke, das Einlesen der Daten ist für Flash bestimmt kein Problem.

Jürgen T. hat geschrieben:
ja, ich hatte anfangs die GEDCOM-Ausgabe benutzt, kam dann allerdings schnell auf die (wie ich finde) praktischere CSV-Ausgabe.

Irgend jemand nutzt immer noch die Gedcom-Datei und Du hattest da nachgefragt wieso - soweit kann ich mich noch erinnern Ich muss das doch noch mal raussuchen.
Marcus

Hallo Marcus,

Marcus hat geschrieben:Irgend jemand nutzt immer noch die Gedcom-Datei und Du hattest da nachgefragt wieso - soweit kann ich mich noch erinnern Ich muss das doch noch mal raussuchen.
Marcus

kann es sein, dass Du stb meinst?

In dieser Diskussion schreibt er, dass er die Dateiausgabe GEDCOM(XML) verwendet.
http://www.ahnenblattportal.de/viewtopi ... l&start=14

Wer sich mit Datenbanken auskennt, könnte mal in die Richtung SQLite denken. Hierbei handelt es sich um eine Standalone Datenbank die verblüffen performant und einfach zu handhaben ist. Abfragen erfolgen über die standardisierte SQL Sprache.

Ein Objektmodell für die Daten zu verwenden halte ich für keinen guten Ansatz da der Overhead bei 25000 Personen wohl extrem wird. Arrays sind schnell, bei sehr vielen Daten wird aber auch dies länger dauern.

Leider komme ich zur Zeit überhaupt nicht zum programmieren, aber vielleicht bringen meine Gedanken jemanden weiter .

Gruss
Roger

Hmmm... Danke für die Diskussion... CSV ist denke ich tatsächlich das einfachste.
Jetzt ist die Frage, ob man daraus irgendwie die Familienzusammenhänge rekonstruieren kann.

Hallo Flash,

Flash hat geschrieben:Jetzt ist die Frage, ob man daraus irgendwie die Familienzusammenhänge rekonstruieren kann.

das ist sehr einfach.
Die csv-Datei hat immer den gleichen Aufbau:
Wichtig für Dich sind im wesentlichen die Spalten
Nr. 1: REFN = laufende Nummerierung der in der csv-Datei enthaltenen Personen.
Nr. 6: FATH.REFN = Nummer des Vaters der entsprechenden Person
Nr. 8: MOTH.REFN = Nummer der Mutter der entsprechenden Person

Über diese Angaben kann man sich die einzelnen Familien zusammenstellen.
So sind z.B. alle Personen, die in der Spalte 5 die gleiche Nummer stehen haben, Kinder des Mannes, der die REFN hat, die in Spalte 5 steht.
Die csv-Datei enthält nur Eltern<->Kind Beziehungen und keine Geschwisterverweise.
Auf die fehlenden Geschwisterverweise - insbesondere bei den Spitzenahnen - wurde schon in vielen Diskussionen hingewiesen. Es zeigt sich also, dass es für die Spitzenahnen wichtig ist, zumindest einen Pseudo-Vater in Ahnenblatt zu erfassen, um über die Vater<->Kind Beziehung die Familien zusammentellen zu können.

Danke für den Hinweis auf die Spitzenahnen. Da ich hier nicht all zu regelmäßig mitlese wäre ich da bestimmt auch hängen geblieben.

Was mich interessiert sind die Infos zu den Mehrfachehen. Wie viele solche Ehen sind im CSV File zulässig? Ich habe hier 3 und zufälligerweise auch genau einen Datensatz der die 3 voll ausschöpft.
Mich beschleicht die dumpfe Vermutung, dass es eventuell eine variable Spaltenanzahl gibt...

...ja...hab das gerade getestet...Hmmm...mal schaun...