Dezentrale Forschung, zentrale Datenhaltung - wie?

Hallo zusammen,
meine Ahnenforschung begrenzt sich schwerpunktm��ig auf ein bestimmtes Gebiet,
in dem die Familien im Laufe der Zeit �fters untereinander geheiratet haben.
So sind, �ber l�ngere Zeitr�ume betrachtet, viele miteinander verwandt.
Nun ist folgende Situation entstanden:
1) Ich selbst habe, basierend auf fr�heren Vorarbeiten anderer, Daten auf
meiner Homepage in Form handgestrickter HTML-Seiten publiziert
(www.ahnendaten.de); diese Seiten finde ich zwar optisch nach wie
vor recht ansprechend, aber sie haben schon vor einiger Zeit die Grenze der
Erweiterbarkeit �berschritten und ich habe vor, die Daten in ein
Ahnenprogramm einzugeben. (Ich habe einiges Material mehr, was �berhaupt noch
nicht erfa�t ist, bzw. weitere Details zu erfa�ten Personen.)
2) Ein anderer Forscher, mit dem wohl eine weitl�ufige Verwandtschaft besteht,
forscht im selben Bereich, wir haben eine gro�e Schnittmenge (m��te im
einzelnen noch verglichen werden), aber es geht nat�rlich in unterschiedliche
Richtungen.
3) Dieser Tage hat sich nun zuf�llig herausgestellt, da� ein entfernter
Verwandter einen alten Stand meiner Daten, den ich vor etlichen Jahren in der
Verwandtschaft in Papierform zirkulieren habe lassen, in seinen PC eingegeben
hat - seinerseits wieder erweitert um Daten, die nur er hat!

Es hat aus meiner Sicht absolut keinen Sinn, wenn mehrere Leute mit
unterschiedlichen St�nden mehr oder weniger am Gleichen arbeiten. Es m��te
also etwas geschehen, um diese unterschiedlichen St�nde zusammenzuf�hren -
aber was?
Es ist klar, da� der Weg Gedcom-Export -> Gedcom-Import nicht funktioniert;
wenn jeder der Beteiligten etwas �ndert, kriegt man nur mit unendlicher
Kleinarbeit alle auf den gleichen Stand. Und es soll aber auch jeder
Beteiligte weiter an seinem Gebiet weiterarbeiten k�nnen. Stichwort
"verteilte Datenbanken".

Zun�chst einmal suche ich eine EDV-L�sung, mit der die Ahnendaten in einem
zentralen Datentopf (sprich: auf einem Webserver) gehalten, aber jeder der
Beteiligten dezentral an den Daten weiterarbeiten kann.
Wenn diese EDV-L�sung gefunden ist, m�ssen die Daten konsolidiert werden; das
ist nat�rlich mit viel Kleinarbeit verbunden.

Die einzige EDV-L�sung, die ich - seit einem Beitrag auf der Mailingliste
Homepages-L - kenne, ist PhpGedView Neuigkeiten
Die Daten werden auf einem Internetserver gehalten, verschiedene Personen
k�nnen differenzierte Lese-/Schreibrechte haben. Liest sich alles ganz
vern�nftig. F�r spezielle Auswertungen, die das Programm nicht bietet, kann
man die Gedcom-Datei wohl herunterladen und im eigenen Programm lokal
weiterverarbeiten.

Meine Fragen:
1) Hat jemand einen grunds�tzlichen Rat, wie mit der beschriebenen
Ausgangssituation umzugehen ist?

2) Wer hat konkrete Erfahrungen mit PhpGedView im allgemeinen und mit dem
verteilten Arbeiten (mehrere Forscher) im Speziellen?
Wie kommt das Programm klar mit "Spezialit�ten", z.B.
- Darstellung/Hervorhebung Rufnamen, Spitznamen
- unscharfe Datumsangaben
- Verheiratete ohne gemeinsamen Ehenamen
- Ahnenschwund
- variierende Nachnamensschreibenweisen
- etc.
Bitte um Erfahrungsberichte.
Ich habe mir etliche der Homepages angeschaut, die auf
http://phpgedview.sourceforge.net/de/registry.php aufgef�hrt sind; demnach
haben die Leute anscheinend meist nur lokal erstellte Gedcom-Dateien
hochgeladen. Wer arbeitet mit PhpGedView plus dem Java-GDBI-Client?
Erfahrungen?

3) Gibt es noch weitere (auch kommerzielle) Programme, die verteiltes Arbeiten
bei zentraler Datenhaltung unterst�tzen?
(Aus EDV-technischer Sicht m��te man in einem Programm, das SQL-basiert
arbeitet und eine saubere Schichtenarchitektur hat, die "Speicherschicht"
austauschen, soda� - Beispiel GF-Ahnen - das Programm nicht mit
Paradox/Borland Database Engine - arbeitet, sondern stattdessen �ber die
ODBC-Schnittstelle mit geeigneten SQL-Datenbanken. Vielleicht k�nnten die
hier mitlesenden Programmierer dazu was sagen.)

F�r die etwas l�ngliche geratene Mail m�chte ich mich entschuldigen...
Ulrich Kretschmer

PS: Die Anfrage pa�t m�glicherweise auch auf die Liste "Homepages-L"?!

Meine Fragen:

Ich habe Leider keine Antwort für Dich. Aber ein paar Gedanken sind mir gekommen, die ich Dir nicht vorenthalten möchte.

In einigen Programmen gibt es die UID (userdfinierte Identnummer). Sie wird beim Anlegen einer neuen Person erzeugt und ist zufällig genug, dass keine je doppelt erzeugt werden wird. Wenn alle Personen eine UID haben, und einmal abgeglichen wurde, ist ein späterer Abgleich anhand der UID einfacher. Lediglich bei hinzugekommenen Personen muss man neu abgleichen. Einige Progtamme bieten dafür spezielle Funktionen zum "verschmelzen".

MfG, Metti.

2) Ein anderer Forscher, mit dem wohl eine weitlᅵufige Verwandtschaft
besteht, forscht im selben Bereich, wir haben eine groᅵe Schnittmenge
(mᅵᅵte im einzelnen noch verglichen werden), aber es geht natᅵrlich in
unterschiedliche Richtungen.
[...]
Es hat aus meiner Sicht absolut keinen Sinn, wenn mehrere Leute mit
unterschiedlichen Stᅵnden mehr oder weniger am Gleichen arbeiten. Es mᅵᅵte
also etwas geschehen, um diese unterschiedlichen Stᅵnde zusammenzufᅵhren -
aber was?

[...] es soll aber auch jeder
Beteiligte weiter an seinem Gebiet weiterarbeiten kᅵnnen. Stichwort
"verteilte Datenbanken".

Die Lᅵsung dieses Problems ist meine Vision bei der Entwicklung von GedBas.

Wenn man sich das Thema genauer betrachtet, tauchen immer neue Schwierigkeiten
auf:
* Versionskontrolle (extrem wichtig, sonst entsteht sehr schnell Chaos)
* Transaktionssicherheit (die ᅵbertragung funktioniert "ganz oder gar nicht",
sonst kᅵnnten z.B. Quellenangaben verlorengehen)
* Hinzufᅵgen von neuen Daten und Verknᅵpfen mit den vorhandenen
* Zugriffsrechte
* bei weitgehenden Zugriffsrechten (groᅵe Chance der Zusammenarbeit) - welchen
Daten vertraue ich
* Auswahl der zu ᅵbertragenden Daten ins lokale System (im Idealfall sind
nᅵmlich *alle* Informationen im zentralen Datenspeicher miteinander
verknᅵpft)

Diese Liste lᅵᅵt sich noch umfangreich ergᅵnzen...

Die einzige EDV-Lᅵsung, die ich - seit einem Beitrag auf der Mailingliste
Homepages-L - kenne, ist PhpGedView Neuigkeiten
Die Daten werden auf einem Internetserver gehalten, verschiedene Personen
kᅵnnen differenzierte Lese-/Schreibrechte haben.

Das funktioniert aber nur fᅵr relativ kleine Datenbestᅵnde. Interessant wird
die gemeinsame Arbeit IMHO erst dann, wenn wirklich viele Leute mitarbeiten
kᅵnnen.

Gruᅵ
Jesper

- --
Jesper Zedlitz eMail : jesper@zedlitz.de
                  Homepage : http://www.zedlitz.de
                  ICQ# : 23890711

Hallo Ulrich,

technisch gesehen g�be es eine M�glichkeit, vorausgesetzt die Daten werden in einer Datenbank abgespeichert, die Replikation unterst�tzt. So weit ich das �berblicke, gibt es derzeit nur ein Programm das eines dieser Backends unterst�tzt. Es ist ein relativ neues Programm, das auch hier mal zum Test angeboten wurde. Ich wei� allerdings nur, dass es als Datenbank Access verwendet. Vielleicht liest der Author mit oder jemand anderem f�llt der Name nochmal ein.

Zur Replikation (am Beispiel Access.mdb): Zuerst wird eine normale Access.mdb umgewandelt in einen sogenannten Designmaster. Von diesem ausgehend erstellt man dann die Arbeitsreplikate. Diese k�nnen unabh�ngig voneinander existieren und bearbeitet werden. Die Replikationsfunktionalit�t der MS JET-Engine merkt sich alle gel�schten Datens�tze und macht sich einen Vermerk bei jedem ge�nderten Datensatz. Jeder neue Datensatz erhalt eine weltweit eindeutige Nummer (GUID = Globally unique identifier, hexadezimal). Der Datenabgleich (= die Replikation) sollte lt. Microsoft 60 Tage nicht �berschreiten, je nach dem wie man repliziert, l��t sich danach nicht mehr replizieren. Um die Konsistenz der Daten zu gew�hrleisten und um die Dauer des Datenabgleichs m�glichste gering zu halten, sollte man ohnehin k�rze Abst�nde w�hlen. Der Abgleich erfolgt bei der direkten Replikation z.B. durch Direkteinwahl �ber das DF�-Netzwerk von einer ISDN-Karte zur anderen ISDN-Karte oder alternativ als PC-Direktverbindung (also beide PCs/Laptops mit einem Kabel verbinden). Die Dauer des Abgleiches kann je nach Datenmenge �ber ISDN schon mal eine Stunde dauern, �ber Netzwerk selten mehr als ein paar Minuten. Ein Datenabgleich �ber Internet (mittels VPN) ist nicht zu empfehlen, weil die Stand-Sicherheit der Verbindung nicht garantiert ist. Internet/VPN l��t sich nur sicher mit einer "echten" Datenbank (MS SQL, Oracle, MySQL) verwenden.

Theoretisch k�nnen mittels der Replikation beliebig viele Menschen an einer Datenbank arbeiten. Sicherlich w�re es sinnvoll innerhalb des Programmes eine Rechtevergabe zu haben, um z.B. Seitenzweige generell f�r andere Benutzer schreibzusch�tzen.

Bei Interesse zum Thema Replikation kann ich gerne noch weitere Fragen beantworten.

Viele Gr��e

Holger Nick

Ulrich Kretschmer schrieb:

Mehrere Forscher, �berlappende Forschungen. Das ist ein immer wiederkehrendes Problem in der Ahnenforschung, und leider eines, dass auch auf l�ngere Sicht ohne befriedigende L�sung bleiben wird. Ich m�chte deswegen auf die Vorschl�ge in dieser Liste n�her eingehen:

Variante A) Replikation mittels MS-Access.

Es ist sicher keine gute Idee, einem nicht daf�r vorgesehenen Programm quasi durch die Hintert�r Replikation beibringen zu wollen. Wer das tut schreit f�rmlich nach �rger.

Hintergrund: Replikation in MS-Access produziert neben einer ganzen Reihe anderer Details unter anderem zwei auffallender �nderungen in der Datenbank:
   - eine zus�tzliche Spalte in jeder Tabelle
   - ein anderes Verhalten von Z�hlerspalten
Jede dieser �nderungen wird sogar sehr wahrscheinlich zu Fehlern, wenn nicht sogar Abst�rzen oder Datenverlust im Programm f�hren!

Sollte sich ein Access-Programmierer dazu durchringen, Replikation in seiner Software zu unterst�tzen f�hrt das unweigerlich zu den strukturbedingten Problemen siehe P.S. unten.

Variante B) Nutzen eines Webservers (z.B. GeneWeb, phpGedView)

Dieser Ansatz ist nat�rlich nicht wirklich dezentral, da die Datenbank nur an einem Ort vorgehalten wird, n�mlich auf dem Webserver. Wenn sich alle Beteiligten auf eine solche L�sung einigen k�nnen, ist das praktikabel. F�r Diagramme, Listen und Auswertungen kann dabei eine GEDCOM vom Webserver produziert werden, und ein normales Programm genutzt werden.

Vorteile:
   - keine Replikation n�tig.

Nachteile:
   - Alle Forscher m�ssen online gehen, um Daten �ndern zu k�nnen.
   - Alle Forscher m�ssen sich bei der Datenpflege einig sein.
   - Auf dem Webserver liegen auch solche Daten, die die anderen Forscher
     gar nicht interessieren, weil hier keine �berlappung besteht.

Variante C) Nutzen der UID-F�higkeit von Offline-Programmen

Eine ganze Reihe von Ahnenforschungsprogrammen k�nnen mit dem von PAF eingef�hrten "_UID"-Tag umgehen. UIDs kennzeichnen Personen in GEDCOM-Dateien, und erf�llen den gleichen Zweck wie GUIDs in MS-Access.
Diese Programme k�nnen ver�nderte Personen "wiedererkennen", und Unterst�tzung beim Verschmelzen bieten. Die Art der Unterst�tzung ist von Programm zu Programm unterschiedlich.

Vorteile:
   - Einsatz von Standardsoftware, ggf. sogar verschiedener Programme
   - Nur f�r den Datenaustausch ist eine Online-verbindung n�tig (email)
   - Daten, die f�r andere nicht von Interesse sind, m�ssen nicht
      ausgetauscht werden. (Teilbaum-export)

Nachteile:

   - UIDs kennzeichnen nur Personen, nicht aber einzelne Details. Eine
     Replikation ist damit nur begrenzt m�glich.
   - Alle beteiligten Programme m�ssen UIDs zumindest "mitschleppen"
     k�nnen, und nicht etwa Notizen aus ihnen generieren.

Die Begrenzte Replikation mittels UIDs sieht in der Praxis so aus:

1) Das L�schen von Personen wird nicht an andere Forscher weitergegeben, dadurch k�nnen beim mehrfachen Datenaustausch l�ngst gel�schte Personen wieder auftauchen.

2) Beim Verschmelzen muss in vielen Programmen entschieden werden, welche von zwei sich widersprechenden Informationen behalten werden soll. Das ist oft nicht einfach -> "Ist er nun am 1. Januar oder 2. Januar geboren?"

3) Programme die widerspr�chliche Informationen einfach beibehalten und nebeneinander stehen lassen k�nnen, erhalten durch mehrfachen Datenaustausch l�ngst korrigierte Informationen wieder zur�ck.

Programme, die UIDs verstehen sind daran zu erkennen, dass dessen GEDCOM-Dateien Zeilen enthalten, die mit "1 _UID " beginnen, die von einer f�rchterlich langen Zahl gefolgt wird.

Beispiel:

0 @I1@ INDI
1 _UID E0DE4A472756D511BD0100D05C1F061D0000
1 NAME Vorname /Nachname/

Gr��e

J�rn Daub

P.S. F�r die Informatiker unter den Mitlesenden

... sei hier ein kleiner Hinweis angebracht, warum das Problem Replikation f�r die Ahnenforschung schwieriger ist, als f�r "normale" Unternehmensdatenbanken:

Die Gesamtheit der Ahnenforscher und ihrer Daten ist ein hochverteiltes System asynchroner Datenbanken ohne geregelten Replikationsmechanismus, ohne Hierarchie, und ohne verbindliche Instanz der Kollisionsbearbeitung.

Eine Unternehmensdatenbank ist klassischer Weise ein hierarchisch organisiertes System weitgehend synchroner Datenbanken, mit systematisch geregelter Replikaktion und strukturell vorgegebenen Punkten der verbindlichen Kollisionsbearbeitung.

Klassische Datenbanken ben�tigen sowohl zur Replikation als auch Kollisionsaufl�sung hierarchische Strukturen - mit gutem Grund. Bei flachen Hierarchien ist es ohne Weiteres m�glich, dass ein und die selbe Kollision immer wiederkehrt. Zwei "st�rrische" Beteiligte, die jeweils auf der Richtigkeit ihrer Daten bestehen, und die Kollisionen jeweils durch Verwerfen der anderen l�sen, k�nnen dadurch auch Dritte in Mitleidenschaft ziehen, die mittelbar wechselseitig Daten zum Abgleich erhalten.

Bedenkt man nun noch, dass sowohl die Replikation als auch die Kollisionsaufl�sung durch unterschiedliche Programme mit ebenso unterschiedlichen Datenfeldern und Algorithmen vollzogen wird, d�rfte klar sein, warum es wohl noch ein paar Jahrzehnte der Informatik bedarf, bis so etwas sauber l�uft - wenn �berhaupt.

Dass der heutige UID-Ansatz nur ein Teil der Replikationsmechanismen erlaubt, die in Datenbanken heute verf�gbar sind, macht angesichts dieser Grundproblematik kaum noch etwas aus.

Nachteile:
- Alle Forscher müssen online gehen, um Daten ändern zu können.
- Alle Forscher müssen sich bei der Datenpflege einig sein.
- Auf dem Webserver liegen auch solche Daten, die die anderen Forscher
gar nicht interessieren, weil hier keine Überlappung besteht.

Gar nicht beachtet wurde der Punkt Datenschutz. (trifft allerdings überwiegend auf nebende Personen zu)

MfG, Metti.

> Die einzige EDV-L�sung, die ich - seit einem Beitrag auf der Mailingliste
> Homepages-L - kenne, ist PhpGedView Neuigkeiten
> Die Daten werden auf einem Internetserver gehalten, verschiedene Personen
> k�nnen differenzierte Lese-/Schreibrechte haben.

Das funktioniert aber nur f�r relativ kleine Datenbest�nde.

Die Datenbest�nde k�nnen durchaus gro� sein (was das System halt packt), nur
der Kreis der Personen mit Schreibrechten mu� klein und �berschaubar sein.
Der Koordinationsaufwand steigt erheblich mit der Anzahl der
Schreibberechtigten.

Hallo Ulrich,

technisch gesehen g�be es eine M�glichkeit, vorausgesetzt die Daten
werden in einer Datenbank abgespeichert, die Replikation unterst�tzt.

(...)

Zur Replikation (am Beispiel Access.mdb): Zuerst wird eine normale
Access.mdb umgewandelt in einen sogenannten Designmaster. Von diesem
ausgehend erstellt man dann die Arbeitsreplikate. Diese k�nnen
unabh�ngig voneinander existieren und bearbeitet werden. Die
Replikationsfunktionalit�t der MS JET-Engine merkt sich alle gel�schten
Datens�tze und macht sich einen Vermerk bei jedem ge�nderten Datensatz.

Hallo,
zum Thema Access: Ich habe die Erfahrung gemacht, da� Access gut ist f�r
Formulare (Bildschirmmasken), das Zusammenklicken von Abfragen sowie f�r
Berichte. F�r die Datenhaltung als solche ist Access nicht der Weisheit
letzter Schlu�, speziell im Mehrbenutzerbetrieb. (Das ist jetzt eine
"weichgesp�lte" Formulierung...) So bin ich vor einiger Zeit dazu gekommen,
mich mit mySQL zu befassen.

Auch mySQL kann Replikation. (Habe selbst aber keine Erfahrungen damit.)
Allerdings "nur" nach dem Master-Slave-Konzept. D.h. auf einer einzigen
Master-Datenbank finden die Schreibzugriffe statt, die �nderungen werden dann
auf die Slave-Datenbanken weiterverteilt. Eine echte "verteilte Datenbank",
wo �berall Schreibzugriffe stattfinden k�nnen und die �nderungen dann an alle
weiterverteilt werden, ist das nicht. (Das w�re alles andere als trivial,
siehe das "Informatiker-PS" in der Mail von Herrn Daub.)

Aber vergessen wir mal die Replikation - wir sind wieder bei meinem Gedanken
aus der urspr�nglichen Mail angelangt:

Aus EDV-technischer Sicht m��te man in einem Programm, das SQL-basiert
arbeitet und eine saubere Schichtenarchitektur hat, die "Speicherschicht"
austauschen, soda� - Beispiel GF-Ahnen - das Programm nicht mit
Paradox/Borland Database Engine - arbeitet, sondern stattdessen �ber die
ODBC-Schnittstelle mit geeigneten SQL-Datenbanken. Vielleicht k�nnten die
hier mitlesenden Programmierer dazu was sagen.

Leider hat sich dazu von den Programmierern niemand ge�u�ert. Mich w�rde
wirklich eine fundierte Aussage sehr interessieren, ob eines der eingef�hrten
Ahnenprogramme Datenhaltung �ber ODBC -> mySQL unterst�tzten k�nnte.
Ob diese mySQL-Datenbank dann lokal auf dem eigenen PC l�uft oder auf einem
entfernten Webserver, ist aus Sicht des Ahnenprogramms belanglos. Das ist es,
was diese L�sung so elegant machen w�rde: es kann jeder mit dem lokalen
PC-Programm arbeiten (nat�rlich m��te es bei allen Teilnehmern das gleiche
Programm sein), nur die Daten sind zentral/gemeinsam abgelegt.

Ansonsten, aus der bisherigen Diskussion habe ich mitgenommen: Einige gute
Ideen, beschr�nkte L�sungen f�r Teilaspekte, aber die alleinseligmachende
eierlegende Wollmilchsau-Probleml�sung gibt es derzeit nicht und sie ist auch
in �berschaubarer Zeit nicht zu erwarten.

So werde ich es wohl mal mit PhpGedView probieren; vorausgesetzt, meine
Mitstreiter k�nnen sich daf�r erw�rmen und ein noch durchzuf�hrender Test
ergibt, da� die Performance auch bei gro�en Datenmengen noch brauchbar ist.
Um Forschungsergebnisse insbesondere einem erweiterten Familienkreis
interaktiv zur Verf�gung stellen zu k�nnen, ist PhpGedView jedenfalls recht
sch�n. Und auch an den Datenschutz ist gedacht (siehe die andere Mail).

Ulrich

Habe mich zwischenzeitlich mit PhpGedView n�her befa�t. Es gibt da recht
ausgekl�gelte Datenschutzfunktionen:
- Lebende Personen kann man f�r nichtregistrierte Benutzer generell
ausblenden, es erscheint dann nur noch "privat".
- F�r registrierte, angemeldete Benutzer kann man es vom (einstellbaren) Grad
der Verwandtschaft abh�ngig machen, f�r welchen (lebenden) Personenkreis
n�here Daten sichtbar sind.
- Bestimmte Gedcom-Datenfelder (z.B. Ehescheidung, Todesursachen) k�nnen nur
f�r bestimmte Benutzerkreise (z.B. nur Administratoren) sichtbar gemacht
werden.
- und f�r auszuw�hlende Einzelpersonen sind nochmal abweichende Einstellungen
m�glich.
Ulrich

Es gibt da recht ausgeklügelte Datenschutzfunktionen:

Cool!
Das hört sich wirklich brauchbar an.

MfG, Metti.

Leider hat sich dazu von den Programmierern niemand geäußert.

Damit Du wenigstens einen vorweisen kannst ...
Ich kenne mich mit Datenbankprogrammierung nicht aus.

MfG, Metti.

Die einzige EDV-L�sung, die ich - seit einem Beitrag auf der Mailingliste
Homepages-L - kenne, ist PhpGedView Neuigkeiten

(...)

3) Gibt es noch weitere (auch kommerzielle) Programme, die verteiltes
Arbeiten bei zentraler Datenhaltung unterst�tzen?

Hallo,
Nachtr�ge - beim St�bern in den Diskussionsforen von PhpMyGedview fand ich
noch folgende Hinweise:
1) http://www.phpmyfamily.net/ (kann offenbar weniger als PhpMyGedview)
2) "TNG": The Next Generation of Genealogy Sitebuilding (TNG)
Ein PHP-Programm, kommerziell (aber 25 US$ ist wohl eher als symbolischer
Preis zu werten).
Einige Eindr�cke:
- Online-Stammb�ume �hnlich PhpMyGedview; keine Tortendiagramme, keine
PDF-Reports wie in PhpMyGedview, im �brigen sind die Funktionalit�ten aber
recht �hnlich, das Webdesign ist etwas weniger bunt, aber das ist ja eh alles
Geschmackssache
- integrierte Bilddatenbank (dazu noch eine extra Friedhofs-Bilddatenbank,
naja, wer's braucht) mit Verkn�pfungsm�glichkeit zu Personen. Analog lassen
sich auch noch beliebige Texte (und anscheinend auch Dateien?) hinterlegen
und verkn�pfen.
- Im Gegensatz zu PhpMyGedview werden die Daten komplett in mySQL gehalten, so
d�rften wohl auch bei gr��eren Datenmengen keine Performance-Engp�sse zu
erwarten sein.
- (einfache) Auswertungen (z.B. f�r Plausibilit�tspr�fungen) kann man sich
selbst zusammenklicken, sehr interessant
- die Eindeutschung ist an einigen Stellen etwas holperig (sehr nett z.B. der
"Gehe"-Button); in der Referenzliste fanden sich keine deutschsprachigen
Kunden
- die Datenschutzfunktionalit�ten sind nicht so ausgekl�gelt wie bei
PhpMyGedview, aber jedenfalls kann man die lebenden Personen ausblenden und
au�erdem Zugriffsrechte auch auf Basis von Stammbaumzweigen vergeben
- Supportforum: http://tngforum.us/ (englischsprachig)
Mein Fazit: TNG schaut recht vielversprechend aus.
Ulrich

PS: Eigentlich geh�rt dieser Beitrag thematisch eher auf die Liste
Homepages-L, aber ihn parallel an beide Listen zu schicken, erschien mir
wenig sinnvoll.

Hallo,

Ich habe GenProfi Stammbaum von Dr. C. Leue. Nun ist es mir passiert das
ich einen Mann als weiblich eingetragen habe.

Das hei�t in der Grafischen Ansicht bekommt er einen Ovalen Kasten. Wenn ich
nun in der Bearbeitungsansicht gehe kann ich leider das Geschlecht nicht
mehr �ndern das es abgeblenet ist. Was kann ich tun um ihn wieder als
m�nnlich einzustufen?

Danke f�r die Hilfe

Gru� Michael

Hallo Michael,

das finde ich ziemlich heftig, dass man das nicht direkt �ndern kann. Sowas
sollte in einem Programm zur Basisausstattung geh�ren.

Produktives zu diesem Produkt kann ich leider nicht beitragen.

Viele Gr��e,
Inga

-----Urspr�ngliche Nachricht-----
[mailto:genealogie-programme-bounces@genealogy.net]Im Auftrag von
Michael Heilmann

Liebe Kolleginnen und Kollegen,

eine Anfrage die eigentlich nicht hier her gehört!
Für mich war es immer eine Herausforderung Personen nach ihrer Herkunft
geografisch darzustellen. Als blutiger Anfänger tut man sich schwer alle
eintreffenden Informationen zu ordnen und zu verarbeiten.
Viele Fehler werden durch Namen begangen, viele durch Orte. Gerade bei Orten
kann man um viele KM daneben liegen, super Datenbanken im Internet geben
Auskunft wo die gesuchte Stadt liegt, wie sie heute heißt, aber wie heißen
die Nachbarorte, wo liegen die Matriken, wie kann ich meine effiziente
Forschung vor Ort betreiben?

Diese und noch mehr Fragen trieben mich eine Datenbank zu schaffen, die vom
räumlichen ausgeht, von den Orten der Vorfahren.
Eine Datenbank ohne Lizenzkosten und ohne Restrektionen (so weit wie
möglich)
Nun meine Frage:
Da ich nur freeware verwende, wer kennt Programme /Internetseiten(Downloads,
etc, wo man Landkarten unentgeltlich bekommt, in mehreren Maßstäben, Größen,
Details, etc. und wichtig von verschiedenen Jahren /Jahrzehnten.

Danke im vor raus für die Hilfe und reichlichen geistigen Anstoß
LG
Martin Mennert
Wien

Hallo Martin,

so etwas in der Art gibt es f�r Deutschland ja schon.
Schau mal hier:

http://www.emecklenburg.de/MFP/cgi-bin/loc.pl?ort=b�rgerende&lang=1

Du kannst zu dem gesuchten Ort - wenn er sich denn in der Datenbank befindet - auch die entsprechende Karte auf den Monitor holen. Auch das jeweilige zugeh�rige Kirchspiel ist mit aufgef�hrt.

Gru�

Heinz

Hallo Heinz,
danke für den Hinweis, aber das ist nicht im geringsten ähnlich dem, was ich
machen will. Für ein Bundesland so etwas zu machen ist recht nett, ich will
aber auch Grenzen sprengen, und nur Deutschland interessiert ja auch keinen.
Ich meine das jetzt nicht abschätzig, aber in der Genealogy - was fange ich
da mit einem jetzigem Staat an?!
Außerdem ist dort die Führung auf den Seiten katastrophal und eigentlich für
user nicht zumutbar.
Trotzdem danke für den Link.
LG
Martin

Hallo Martin,

ich schreibe mal meine Antworten zwischen Deinen Text.

heitow schrieb:
[...]

To: "'Genealogie-Programme'" <genealogie-programme@genealogy.net>
Sent: Tuesday, March 08, 2005 11:21 PM
Subject: [Gen-Programme] Landkarten

Liebe Kolleginnen und Kollegen,

eine Anfrage die eigentlich nicht hier her geh�rt!
F�r mich war es immer eine Herausforderung Personen nach ihrer Herkunft
geografisch darzustellen. Als blutiger Anf�nger tut man sich schwer alle
eintreffenden Informationen zu ordnen und zu verarbeiten.
Viele Fehler werden durch Namen begangen, viele durch Orte. Gerade bei
Orten
kann man um viele KM daneben liegen, super Datenbanken im Internet geben
Auskunft wo die gesuchte Stadt liegt, wie sie heute hei�t, aber wie
hei�en
die Nachbarorte, wo liegen die Matriken, wie kann ich meine effiziente
Forschung vor Ort betreiben?

Alle diese Punkt, plus die von Heinz angesprochenen
in unterschiedlichen Zeitr�umen unterschiedlichen politischen
und kirchlichen Zugeh�rigkeiten, haben wir vom Verein f�r
Computergenealogie in unserer n�chsten GOV-Version abgebildet.
Das neue GOV in einer Arbeitsversion (heisst: das Final-Layout,
die Suchfunktionen, die Ausgabe und die Daten werden sich noch �ndern)
kann man sich das gerne schon mal ansehen:
http://gov-neu.genealogy.net

Wer dar�berhinaus mehr zur Eingabesyntax sehen will, um vielleicht
auch an diesem Projekt mitzuarbeiten, Daten zu korrigieren, neu
einzugeben, etc. kann hier nachlesen:
http://wiki.genealogy.net/index.php/GOV_Quicktext

Wer am Projekt mitarbeiten m�chte, kann sich f�r die Projekt-
Mailingliste anmelden:
http://list.genealogy.net/mailman/listinfo/gov-develop

Martin: vielleicht w�re das auch etwas f�r Dich?
Wir w�rden uns freuen, denn Deine Ideen gehen genau in die Richtung,
die wir auch abdecken wollen.

Hallo Heinz,
im Grunde hast du natürlich recht, aber du siehst es viel zu klein.
Das was mir vorschwebt hat nichts mit Ländern, Religion oder so etwas zu
tun. Einen Landkarte ist im Grunde nur ein Raster, den du über den Erdball
legst. Wer wann zu wem gehört hat ist bei meiner Überlegung irrelevant, bzw.
zweitrangig. Die Matriken kann ich mir über hunderte Internetseiten holen,
aber wie heißen nun die Nachbarorte von Butschafka?
Ich habe lange in NÖ geforscht, bis ich drauf kam, dass dieser Ort nahe Prag
liegt.
Im Grunde will ich nur eine Landschaftliche Darstellung der Vorfahren
machen, damit man dann geballt seine Nachforschungen betrieben kann.

Ich bin Ihnen für die Denkanstöße wirklich dankbar, und würde mich freuen,
wieder von Ihnen zu hören. Eine Datenbank anlegen ist leicht, diese zu
erweitern aber schwierig.
LG
Martin