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.

Das Statistische Bundesamt hat mal wieder die Zahlen über Schulabgänger veröffentlicht. Die aktuellsten betreffen das Schuljahr 2007/2008. Das könnte natürlich auch neuer sein, aber die Mühlen der Bürokratie arbeiten langsam. LANGSAM.

Seis drum. In jenem Jahr haben fast 230.000 Schüler ihre Pflicht mit dem Abitur (allgemeine Hochschulreife) abgeschlossen. Wie das linke Cartogram (flächentreu) zeigt, die meisten davon in Nordrhein-Westfahlen. Berlin ist erwartungsgemäß aufgrund seiner hohen Bevölkerung auch ziemlich groß vertreten. Im Gegensatz zu den Statistiken über Erwachsene ist Brandenburg hier auch nicht völlig aufgesogen, sondern kann sich noch mit eigenen Abiturienten behaupten. Die Landflucht in die Hauptstadt setzt demnach offenbar erst ab einem bestimmten Alter ein.

Das rechte Cartogram ist eine neue Form. Hier habe ich die Zahl der Abiturienten mit der Zahl der Einwohner normalisiert. Mit der Zahl aller Einwohner - nicht der der Schulabgänger. Ein Bundesland mit ausbleibendem Nachwuchs hat einfach Pech gehabt und wird entsprechend verzerrt. Hier fällt besonders auf, dass Mecklenburg-Vorpommern an Größe zulegt. Das bedeutet, dass MVP im Verhältnis zu seinen Einwohnern den größten Output an Abiturbesitzern vorzuweisen hat. Die Erklärung dieses Phänomens sei dem geneigten Leser überlassen. Mir fällt dazu spontan nichts Plausibles ein.

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.

Diese Woche gibts wieder ein Cartogram mit Landkreisen: die aktuellen Arbeitslosenzahlen von der Federal Employment Agency (hach das klingt so modern, so international). Zur Diskussion des Inhalts fällt mir jetzt nicht allzuviel ein. Ideal wäre natürlich ein Punkt - rein geometrisch ein Objekt mit Null-Ausdehnung. Das hieße Vollbeschäftigung. Dem ist leider nicht so, also hier die transformierte Karte.

Auffällig ist, dass alle Großstädte Hotspots sind. Das ist logisch, weil hier die meisten Menschen leben. Also auch die Vielzahl der Arbeitslosen. Das führt zu einem enormen Berlin-Ausschlag im Osten. Im Westen beult sich das Ruhrgebiet ziemlich stark aus. Ähnlich wie in Sachsen gibt es hier aber kein offensichtliches Zentrum, sondern die gesamte Region ist mit durchgehend hohen Zahlen gekennzeichnet.

Bei der ganzen Kartogrammerei ist mir übrigens aufgefallen, dass diese Art der Darstellung eigentlich ein didaktisch sinnvoller Ersatz zu den bekannten Tortendiagrammen ist. Dort sieht man die Statistik in der Größe der Tortenstücke. Mit der Farbe des Tortenstückes kann man in der Legende herausfinden, um welchen Eintrag es sich konkret handelt. Das ist beim Cartogram nicht notwendig. Da die Transformation topologietreu ist (also Schlüsselmerkmale nicht unkenntlich macht), kann der Leser mit geeignetem Vorwissen (!) die Statistik direkt ablesen, ohne eine Legende bemühen zu müssen. Mithin dürfte die Darstellung von 400 Werten in einem Tortendiagram ziemlich unübersichtlich sein.

Letzte Woche wurde es politisch. Das werde ich heute nochmal fortsetzen. Da ich Gegenüberstellungen mag, diesmal mit dem Gegensatz der Unionsparteien. Doch was ist eigentlich der Gegenpart zur CDU/CSU? Die SPD fällt einem zuerst ein. Bei genauerem Hinsehen, finden sich allerdings fast nur Gemeinsamkeiten. Richtig gegensätzliche Positionen sind kaum auszumachen. Hmm. Dann muss eben eine Abspaltung der SPD herhalten: die Linken.

Damit fix zum Cartogram: Hier sieht man schön die Gegensätze in der Verteilung. Die CDU wurde ja übermäßig stark durch die weiter westlich gelegenen Bundesländer repräsentiert. Bei den Linken ist es nun fast genau andersrum. Obwohl kein Bundesland so stark geschrumpft (id est unterrepräsentiert) ist wie bei der CDU. Die Partei ist aber auch noch vergleichsweise jung - und so auch ihre Hochburgen.

Dass Bayern gerademal halb so groß ist wie Berlin, ist allerdings 'ne Ansage!

Die heutige Kartierung ist schwarz-weiß. Nicht etwa, weil mir die Farbe ausgegangen ist, sondern weil es dabei um die Mitgliederzahlen einer Partei geht. Genau genommen um zwei Parteien: die CDU/ CSU. Und deren bevorzugte Darstellung ist nunmal schwarz. (Jaja, seit einigen Jahren wird auch ein herzlich warmes, modernes Wohlfühlorange benutzt. Ein Hoch auf die Imageberater!) Aber die Farbe der Union ist und bleibt trotz aller Spins schwarz - das meine ich jetzt wirklich nicht doppeldeutig sondern rein physikalisch vom Farbspektrum.

Spektrum. Das bringt mich auch gleich zur kurzen Diskussion der Grafik. Die westlichen Bundesländer sind deutlich überrepräsentiert. Im Vergleich dazu sind die ostdeutschen Länder stark geschrumpft. Die Mitgliederzahlen sind hier vergleichsweise gering. Das ist insofern überraschend, als dass die Wiedereinigung bereits 20 Jahre her ist, das Ungleichgewicht in der Parteienmitgliedschaft aber immernoch gravierend ist. Offenbar braucht eine Partei mehr als 20 Jahre, um die Menschen überall gleichermaßen zu erreichen. Wobei die kostenpflichtige Mitgliedschaft eine höhere Motivation darstellt als blosse Stimmabgabe bei einer Wahl. Echte Überzeugung breitet sich offenbar langsamer aus, als Wahlplakate.

Das zugrunde liegende Zahlenmaterial ist übrigens aus dem Geschäftsbericht von 2008 (PDF). Ich habe diese Broschüre in megatrendigem Orange allerdings nicht selbst rausgesucht, sondern aus der Wikipedia übernommen, die sie dort rausgesucht haben. Es gibt zwei gesondert ausgewiesene Stadtverbände. Die habe ich eiskalt zum sie umgebenden Bundesland dazugerechnet.

Die Farbskala habe ich mit dem Colorbrewer v2 (Flash) generiert. Das Cartogram für Bundesländer wurde mit einem selbstgeschriebenen Konsolenprogramm auf Basis des GeoStat-Kerns erstellt.

Der Familienname Richter belegt den 14. Platz der häufigsten Namen in Deutschland. Ich habe mich für diesen Namen entschieden, weil sich in der Visualisierung geradezu vorbildlich eine Konzentration in Sachsen ausmachen lässt. Wenn man alle Richters gleichmäßig auf Deutschland verteilen wollte, müsste man die Grenzen wie in der folgenden Grafik anpassen. Oder anders ausgedrückt: Aus den Flächen der Landkreise lassen sich unmittelbar die Anteile der Richters ablesen. Sachsen ist dementsprechend 3x so groß wie Bayern, da es dort dreimal soviele Richters gibt. Die Landkreise habe ich zusätzlich aus didaktischen Gründen eingefärbt.

Erstellt habe ich diese Karte mit meinem aktuellen Build 20100609 von GeoStat 2010. Wie man unschwer erkennen kann, ist der Import von Geogen-Daten nun fertiggestellt. Ich werde noch an ein paar Kleinigkeiten feilen und hoffentlich demnächst eine Beta-Version veröffentlichen.

Wie ich auf Twitter bereits kurz schrieb, bin ich ganz begeistert von einem englischen Paper zur Kartographie. Darin geht es um die Generierung von Cartograms (die deutsche Entsprechung ist -man mag es sich denken- Kartenanamorphote). In Cartograms wird die Karte nicht nur eingefärbt sondern entsprechend des statistischen Wertes auch noch verzerrt. Das erinnert an die relative Verkartung, wenn man z.B. die Bevölkerungsdichte verrechnet. Hier wird aber direkt die Projektion verändert, so dass man aus der Größe der Darstellung (und eben nicht nur aus der Farbcodierung) die einzelnen Werte herauslesen kann.

Eine Implementierung für Deutschland war schnell erstellt. Als Beispiel seien die Landkreise Deutschlands verzerrt nach ihrer Bevölkerungszahl angeführt. Ich habe diese Grafik für den Wikipedia-Artikel zur Kartenanamorphote freigegeben.

Und was hat der geneigte Leser davon? Nun, die Implementierung war interessant, dass ich denke, dass dies ein neues Softwareangebot rechtfertigt. Wie der geneigte Leser bereits aus dem Titel entnimmt, lautet der Entwicklungsname GeoStat 2010. Ja, mit Jahreszahl. Eine regelmäßige Weiterentwicklung ist durchaus denkbar. Erstmal geht es aber nur darum, eine einfache Möglichkeit bereitzustellen an verkartete Statistiken zu kommen, die sonst nur wissenschaftlichen Instituten zugänglich sind.

GeoStat 2010 hat einen völlig neu geschriebenen Kartierungskern. Auch wenn die Optik den Geogen-Karten derzeit bis aufs Haar gleicht. Die interne Struktur ist weitaus besser auf Erweiterungen ausgelegt. Eine kurze Übersicht für die Technikinterssierten:

• Kern in C++ mit Verwendung der STL und Boost
• Oberfläche in MFC mit dem Visual C++ Feature Pack (Themes...) erweitert
• Visualisierung auf Basis der freien Cairo-Bibliothek
• Geographische Daten mit Grenzen von 2010
• Import und Georefenzierung beliebiger Daten im CSV-Format (geplant: OpenDocument-Tabellen, Geogen)
• Export in hochauflösende PNGs und interaktive HTML-Seiten (geplant: PovRay für 3D)
• frei konfigurierbare Farbschemata und Transformationen

So. Das erstmal zum Announcement. Der Plan ist, dass ich weitere Artikel schreibe, wenn irgendetwas besonders interessantes aus Entwicklersicht angefallen ist. Der Release steht dann an, wenn all das getan ist und wird wiederum hier verkündet.

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).