Normalerweiseweise verlinke ich nicht auf andere Blog-Posts oder Social-Media Krimskrams, aber hier hat sich jemand aus den USA die Mühe gemacht, Geogen mehr zu dokumentieren als ich selbst. Die Autorin Elise Ann Wormuth hat auch noch ein paar andere Erfahrungen eingestreut: livinginpast.com.

Die Seite ist recht webzweinullig - man muss Newsletter-Angebote, Cookie-Disclaimer, Übersetzungshilfen usw. wegklicken, aber dann ist sie sehr passioniert aufgemacht.

Ich sammle Features ja nun nicht mehr für große Releases, sondern packe sie nach bestandenem Test sofort auf den Server. Für die Namenskartierungssoftware Geogen waren das in letzter Zeit drei Änderungen, weshalb ich als Zwischenstand mal die Version 4.0.3 ausrufe.

(4.0.1) Lokalisierung.

Nun gibt es Ausgaben auch in Deutsch und nicht mehr nur in Englisch. Zumindest die meisten Texte sind übersetzt, vom Server kommen noch manche extrem seltene Fehlermeldungen in Englisch, aber damit kann man leben. Die Übersetzung funktioniert mit i18next.

(4.0.2) Load-Control.

Ich habe bemerkt, wie eine IP systematisch Namenskarten in alphabetischer Reihenfolge abgerufen hat. Bei einer Frequenz von 5 Sekunden, kann das kein Mensch gewesen sein. Ich gehe von einem gescripteten Download der Datenbank aus. Ab jetzt kann man höchstens ein paar hundert Recherchen pro drei Stunden anstellen, dann wird man erstmal eine zeitlang gesperrt.

(4.0.3) Aktualisierte Abhängigkeiten.

Mit frischem jQuery, Three.js, D3.js und JSON.NET sollte die Seite schneller und runder laufen. In diesem Zuge habe ich auch kleine kosmetische Änderungen untergebracht, zum Beispiel sind die 3D-Balken jetzt heller.

Rundum zufrieden bin ich mit der vierten Generation von Geogen noch nicht, aber technisch immerhin zufriedener als mit der dritten. An der Benutzbarkeit kann man noch etwas feilen. Den meisten Besuchern ist zum Beispiel nicht auf Anhieb klar, dass man auf die 2D-Karte auch klicken kann und dann zu einer Landkreisdarstellung (v3) kommt. Gleiches für den Graphen mit ähnlichen Namen. Der zeigt auf Klick einen größeren Graphen mit noch mehr phonetisch naheliegenden Varianten an.

Eine Funktion ist leider von Anfang an flöten gegangen: mehrere Namen in einer Karte. Das habe ich schlichtweg vergessen - aber deswegen ist die alte Version ja auch noch online. Dafür normalisiert v4 jetzt Sonderzeichen weg: Süßé ist auf dem Server dasselbe wie Suesse. Analog Müller und Mueller.

Ich schrieb es bereits zum zehnjährigen von Geogen, dass ich mit der vierten Generation der Namenskartierungssoftware experimentiere. Vor drei Monaten war das hauptsächlich aus Spaß und ich wusste noch nicht genau, wo es hinführen sollte. Jetzt ist es immer noch Spaß, aber ich weiß, was das werden soll.

Die Version 4.0 ist öffentlich zugänglich. Sie ist Namenskartierung im modernen Gewand, mit besserer Übersicht und erhöhter Performance. Ich bin in den letzten Monaten ein Fan von Continuous Delivery geworden, d.h. ich habe kleine Features und Verbesserungen sofort nach bestandenen Tests auf das Live-System ausgerollt. Am letzten Wochenende war das zum Beispiel eine coole "Game of Thrones"-Animation der 3D-Karte. Womit ich auch schon bei den Details von Geogen 4.0 bin.

Die Software ist eine komplette Neuentwicklung. Ich habe wirklich keine einzige Codezeile der Vorversionen übernommen. Sie setzt auf aktuelle Webtechnologien und hier jeweils auf etablierte Hilfsbibliotheken. Das Grundgerüst ist HTML5 mit jQuery (was sonst?). Dazu kommen WebGL via three.js, Canvas und SVG via D3.js. Im Backend tummeln sich illustre Gäste wie MS SQL Server Compact, Json.NET und ZXing.Net.

Geogen 4.0 gibt es in zwei Fassungen:

• Bleeding Edge Graphics: geogen.stoepel.net
• PuristicTerminal: geogen.stoepel.net/console.html

Es gibt derzeit keine Bestrebungen Geogen 3.1 abzuschalten. Ich entwickle aber dort keine neuen Features mehr und deaktiviere höchstens Gadgets, die vor Jahren einfach schlecht implementiert wurden.

Update 07.03.2015: Ich habe begonnen, die neue Engine international parametrisierbar zu machen. Die Geogen-Konsole funktioniert jetzt auch für Österreich: http://geogen-at.stoepel.net/console.html und phonetische Namensgraphen gibt es ebenso.

Ich habe mal die Backup-Festplatten und alten Quelltexte durchstöbert und dabei fiel mir auf: Geogen ist nun schon 10 Jahre alt.

Es fing in den Semesterferien 2004 mit einer normalen Desktop-Anwendung an, mit der ich mir hauptsächlich selbst Landkarten für Familiennamen erstellen wollte. Schnell stellte sich heraus, dass auch andere diesen Wunsch hatten. Es gab eine Lücke zu füllen, die Anzahl der Downloads war überwältigend. Einiges am Programm war noch nicht rund, weil mir als Student damals schlichtweg die Erfahrung fehlte. Die Lokalisierungsdatenbank als MS Access auszuliefern war sicherlich ein Fehler und brachte unzählige Support-Anfragen. Der Einsatz des damals noch sehr neuen .NET-Frameworks in der Version 1.1 war zumindest ambitioniert.

Ich doktorte einige Male an der Architektur der Software, stieg auf Sqlite zur Datenhaltung um, aber als Desktop-Anwendung war Geogen einfach nicht zu warten. Das Ding musste auf den Server!

Version 2 schrieb ich Ende 2005 komplett neu, jedoch immer noch in C# (ASP.NET 2.0). Auf meinem Server hatte ich das Deployment schließlich selbst im Griff und ab da lief es weitestgehend problemlos. Eine größere Überarbeitung des Layouts brachte Geogen 3 und danach folgten kleinere Wartungs-Releases, aber keine größeren Änderungen im Backend mehr. Es funktionierte einfach.

Eher aus Spaß habe ich in den letzen Wochen mit einem neuen Kern experimentiert. Mit nun 10 Jahren Erfahrung in Geogen und fast doppelt soviel in Software-Entwicklung wollte ich sehen, was so geht. Ergebnis: 10-15 mal schneller geht. Nun, das ist ein guter Wert, aber ich habe selten Performance-Probleme. Es gibt also keine Not für ein Upgrade. Interessanter ist die neue Technologie, zeitgemäße Architektur, neuer Spaß. Vielleicht gibt es auf dieser Basis mal ein Geogen 4.0. Solange bleibt die Subdomain Entwicklerspielwiese. Oder um einen bekannten Mann aus der Informatik zu zitieren: Just for fun.

Geogen ist in der Version 3.1 online verfügbar. Die interne Datenbank-Zugriffsschicht ist nun unabhängig von einem bestimmten Hersteller. Vorher war die Verwaltung von Ranglisten, Nutzerkommentaren und Geograpphie nur mit dem MS SQL-Server via System.Data.SqlClient möglich. An dessen Stelle treten konsequent die Factory-Methoden aus System.Data.Common. Im derzeit stattfindenden Testlauf liegen alle Daten in einem SQL-Server Compact Edition 4.0 - also im selben Prozess wie ASP.NET. Dadurch sollte die Mehrzahl der Nur-Lese-Zugriffe etwas performanter sein.

Im Rahmen dieses Refactorings habe ich auch gleich die MS Ajax Bibliothek samt Ajax Control Toolkit entsorgt. Diese wird von Microsoft zwar noch ausgeliefert aber nicht mehr weiterentwickelt. Das Pferd ist also tot. Man muss sich da auch nichts vormachen: MS Ajax war zu aufgebläht, zu langsam und (was das Control Toolkit betrifft) zu fehleranfällig. Ich habe die Webseite daher komplett auf jQuery umgestellt. Es ist enorm was da grade in der Entwicklung abgeht.

Die erste Änderung, die dadurch möglich wurde, ist ein Autocompleter auf dem Eingabetextfeld. Einfach ein paar Buchstaben eingeben und im Hintergrund werden per Ajax einige Vorschläge herausgesucht, welchen Namen man meinen könnte. Das Control-Toolkit enthielt auch einen Autocompleter, allerdings vertrug er sich nicht nicht mit den per Javascript abgerundeten Ecken. Mein Bug-Report dazu wurde damit abgetan, dass man sich nicht um die Z-Order kümmern kann und das Problem nicht lösbar sei. Die jetzigen runden Ecken kommen per CSS auf alle modernen Browser. Im Internet Explorer bleibt es kantig.

Die Kartenübersicht wurde verschlankt. Die Steuerelemente für Zusatzparameter, die sowieso niemand benutzt hat, habe ich entfernt. Eine derartig fortgeschrittene Konfiguration ist nur noch über die Kaufsoftware möglich. In diesem Zuge wurden die Karten auch gleich in die Ergebnisseite integriert. Mit Hilfe der Fancybox werden sie in Form eines Overlays vor leicht ausgegrautem Hintergrund angezeigt.

Weitere Änderungen sind eher Kleinigkeiten: zu selteneren Namen wird ein maschinenlesbarer Balkencode berechnet mit dem man irgendwelche Gegenstände bekleben (neudeutsch taggen) kann, auf der Startseite läuft ein Ticker zuletzt abgerufener Namen aller Besucher, der phonetische Namensgraph hat den Beta-Status verlassen und ist nun auch in der englischen Version verfügbar und ganz neu gibt es auch eine Fassung für Mobilgeräte. Das nächste Update soll dann ein größeres werden (Version 4.0 oder zumindest 3.5). Ich experimentiere dazu etwas mit HTML5 und Canvas...

Die Beta-Version von GeoStat 2010 zur Verkartung beliebiger Daten gibt es nun hier zum Download (Zip-Datei, 7.5 MByte). Beta-Version bedeutet, dass das Projekt nicht ganz fertig ist und möglicherweise noch Fehler enthalten kann. Es handelt sich dementsprechend um eine Vorschau, die für interessierte Nutzer veröffentlicht wird. Die erstellten Karten sind nicht zur Veröffentlichung freigegeben, ein entsprechender Hinweis wird in der Karte vermerkt. Die Installation des Programms ist nicht notwendig, es genügt alle Dateien des Archivs in ein Verzeichnis zu entpacken.

Die vorliegende Beta beherrscht den Import statistischer Basisdaten im

• CSV-Format (Textdateien die manuell oder via Export von Excel, OpenOffice Calc, etc. erstellt werden können)
• Geogen Familiennamendaten (benötigt die Geogen-CDR oder den Geogen-Download)
• vorberechneten XML-Statistiken (bislang nicht dokumentiert, zur internen Verwendung des Programms)

Die Methode der CSV-Dateien ist sicherlich die einfachste. Erstellen Sie eine Datei namens Beispiel.txt. Hierin schreiben Sie zeilenweise Ihre Datensätze. Jede Zeile ein Datensatz. GeoStat 2010 benötigt zur Kartierung mindestens eine Postleitzahl und einen Ortsnamen. Die einzelnen Einträge müssen Sie durchgehend mit demselben Zeichen trennen. Empfohlen ist das Komma, das Semikolon, Tab oder Doppelpunkt. Wollen Sie beispielsweise Ihre Familie kartieren, schreiben Sie in jede Zeile ein Familienmitglied mit Adresse getrennt durch Komma.

Christoph Stöpel,14974,Ludwigsfelde
Christoph Stöpels Bruder,14974,Ludwigsfelde
Grakein Stöpel,14480,Potsdam

Innerhalb von GeoStat 2010 wählen Sie im Hauptmenü Datei den Punkt Daten importieren und hierin Von CSV/Text. Im erscheinenden Assistenten wählen Sie Ihre Beispieldatei aus. Das Programm versucht automatisch den Spaltentrenner zu erkennen. Sollte das Komma nicht identifiziert worden sein, können Sie dies manuell einstellen. Der nächste Schritt ist entscheidend für die Kartierung. Hier beschreiben Sie, in welcher Spalte GeoStat 2010 welche Daten findet. Im oberen Beispiel enthält Spalte 1 den Titel, Spalte 2 die Postleitzahl und Spalte 3 den Ortsnamen. Stellen Sie dies auch so ein, wie im Bilschirmfoto gezeigt.

Anschließend startet die Berechnung der Statistik und die Kartierung. Dies kann je nach Leistung Ihres PCs einige Zeit in Anspruch nehmen. Erzeugt werden Karten, die die Statistiken zugeordnet zu Landkreisen, in Clustern oder anamorph verzerrt darstellen. Über die Toolbar oder das Hauptmenü können Sie zwischen den verschiedenen Ansichten wechseln. Über das Menü Datei/Speichern unter können Sie die aktuelle Karte in verschiedenen Formaten sichern.

Systemvoraussetzungen:

• Betriebssystem MS Windows XP SP3, Vista, 7 oder neuer
• Prozessor mit 2 GHz oder mehr
• 512 MByte Arbeitsspeicher
• 25 MByte freier Festplattenspeicher

Bekannte Probleme in dieser Beta-Version:

• Die Zusammenlegung von Aachen Stadt und Land zu einem Landkreis ist noch nicht integriert. Die Landkreise werden gemäß Stand vom 31.12.2009 getrennt behandelt.
• Das Speichern von Karten im HTML-Format berücksichtigt nicht die aktuelle Ansicht und exportiert immer die Cluster-Ansicht.
• Die Karte der HTML-Ansicht ist etwas großformatig, so dass Nutzer innerhalb des Browserfenster häufig scrollen müssen.

Abstract: Für das Familientreffen der Stöpels an Pfingsten 2007 habe ich mich (als anerkannter Experte, was sonst?) um die Kartierung unseres Namens gekümmert. Diesmal sollte es allerdings historisch sein. Da es zu dieser Zeit noch keine einfache frei verfügbare Möglichkeit gab, musste wieder "Selbst ist der Mann" ran. Die entstandene Software ist im Beta-Labor meiner Homepage unter dem Namen "Geogen vNext" zu finden.

Sie verfügt über die folgenden Eigenschaften:

1. Import von Gedcoms
2. Laden von Mormonen-Daten via familysearch.org (deren seit 1,5 Jahren angekündigte Webservice-Schnittstelle steht immer noch nicht)
3. Georeferenzierung mit Hilfe des "Genealogischen Ortsverzeichnisses (GOV)" des Vereins für Computergenealogie (GenWiki usw.)
4. Export der referenzierten Daten in Gedcom oder HTML

Die Georeferenzierung ist hier wiedermal der Knackpunkt. Im Regelfall wird man sich auf Mormonendaten beziehen. Das ist die einfachste Möglichkeit, wenn die eigene Ahnenforschung noch nicht besonders weit fortgeschritten ist (Anmerkung: es gibt ein sehr interessantes Projekt von den GenWiki-Leuten, um verschiedene Quellen zu vernetzen, der Name war Genesis wenn ich mich recht erinnere). Diese liefern Personendaten einschließlich Ortsbeschreibung in Form komma-separierter Pfadangaben vom Groben zum Feinen. Zum Beispiel also so: "Deutschland, Brandenburg, Mittelstedt". Das war eine freundliche Angabe. Es gibt aber auch solche wie "Sachsen Prussia, Mittelstedt" oder noch gemeiner "Sachsen Prussia". Spätestens hier beginnt der zeitgenössische Namenskartierer die eindeutigen Identifikatoren zu vermissen, die Postleitzahlen.

Bei aktuellen Daten ist die Lokalisierung einfach: Postleitzahl und Ortsname genommen und in der Datenbank nachgeschlagen (bei Geogen die OpenGeoDb mit 30000 Ortseinträgen für Deutschland). Was aber machen wir nun mit Mittelstedt ohne Postleitzahl? Eine Datenbankabfrage, diesmal an das GOV, liefert 30 Treffer (hypothetisch). Es bleibt also nur, den Pfad der Ortsspezifikation abzulaufen, um überschüssiges auszuschließen. Eine Einschränkung auf Brandenburg ergibt allerdings gar keinen Treffer, weil sich die Grenzen in den letzten 250 Jahren verschoben haben und das heutige Sachsen gemeint ist.

Die schlechte Nachricht: Dieses Problem ist nicht lösbar. Hier kann man nur schätzen und raten. Das jedoch so, dass man (a) mit dem Ergebnis mit hoher Wahrscheinlichkeit richtig liegt und (b) ein Fehlschlag möglichst wenig negative Auswirkungen hat. Umgesetzt wird dies in "Geogen vNext" durch eine Lokalisierungspipeline, die verschiedene Algorithmen aneinanderreiht, wobei mit dem genauesten begonnen wird. Man stelle sich das wie eine Reihe von Sieben vor. Das erste hat die kleinste Löcher und liefert die besten Ergebnisse (exakter Treffer für Mittelstedt). Alles was hier nicht durchfällt geht in ein gröberes Sieb und dann in das nächstgröbere. Die derzeitige Implementierung besteht aus 6 solcher Stufen, wobei die letzte standardmäßig deaktiviert ist (Mittelwertbildung, sehr gierig und sehr grob).

Meiner mathematischen Meinung nach sind die Resultate nicht zufriedenstellend. Gut ein Viertel der Mormonen-Daten ist so schlecht, dass man die Lokalisierung komplett vergessen kann. Vom Rest beißt sich die Pipeline an etwa 15% die Zähne aus und lokalisiert falsch! Das heißt ein Ort kann schlimmstenfalls 1000km neben seiner eigentlichen Position liegen, weil es noch mehrere gleichnamige gibt und der falsche gewählt wurde oder weil sich der Mikrofilmer vertippt hat. An dieser Stelle hilft leider nur der manuelle Eingriff. Dessen sollte man sich bei Verwendung des Programmes bewusst sein (ich habe schon einige euphorische Mails drosseln müssen).

Conclusion: Leider stößt der Informatiker und damit der Automatismus beim Problem historischer Kartierung an Grenzen. Ein absolut genaues Verfahren ist aufgrund der schlechten Qualität der Mormonendaten nicht möglich. Der Einsatz von Heuristiken führt zu Ergebnissen, die nicht ruhigen Gewissens zur Veröffentlichung geeignet sind. Es gibt aber sicherlich auch bessere Implemententierungen als die Meine. Ein möglicher Ausweg wäre die Verlagerung der manuellen Qualitätssicherung auf eine Community. Hierfür fehlen mir allerdings die Resourcen (und in anbetracht des Randthemas ehrlicherweise auch etwas die Motivation).