Announcing Geostat 2010

Samstag, 29 Mai 2010 06:00 by Christoph

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.

Screenshot

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.

Technische Machbarkeit von historischen Namenskartierungen

Donnerstag, 15 November 2007 06:00 by Christoph

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