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.

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