Nun mal wieder ein Panorama. Die älteren bestanden aus 5 Einstellungen pro Panorama, diesmal sollte es etwas mehr sein. Das Maximum von 360°. Ich habe 67 Aufnahmen in je drei Belichtungen (HDR) gemacht. Das ist soviel, weil ich sogar den Boden unter meinen Füßen und den Himmel über meinem Kopf geknipst habe. Leider hat das beim Ausbelichten dann Probleme bereitet: der wirklich interessante Bereich um den Horizont wirkte dunkel und flau. Boden und Himmel habe ich deswegen leider weggeschnitten, das Panorama lässt sich nur um 12° nach oben und nach unten neigen.

Die Darstellung läuft in einem Flash-Plugin ab, das ich überlicherweise nicht so mag. Aber hier war es ziemlich einfach für das Web einen Viewer zu schreiben, der Skyboxen, genauer Skyspheres beherrscht. Wobei schreiben ist übertrieben. Mit PaperVision3D gibt es eine ziemlich ausgereifte 3D-Engine in Flash, die man nur noch integrieren braucht. Achja, der Aufnahmeort.

Nachtrag 27.04.2017: nun sind so viele Jahre vergangen, dass kein Mensch mehr Flash benutzt und ich keinen Browser mehr habe, der das Panorama anzeigen kann. Ersteres ist gut, letzteres nicht so ganz. Daher das ganze schnell als Javascript nachimprovisiert. Allerdings mit einem Sky-Cylinder, die Darstellung ist also nicht korrekt projeziert. Man schiebt nur noch die Tapete hin und her, jedoch wäre mir eine texturierte Kugel in WebGL jetzt zu viel Aufwand.

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.

Fotos ohne Nachbearbeitung? Gibts doch garnicht mehr! Aber richtig macht mans nicht mit ein klein wenig Retusche hier und da, sondern wenn schon dann komplett synthetisch. Besonders interessant sind hierbei die High-Dynamic-Range Techniken (Hochkontrast-Fotographie). Ich benutze dafür die Powershot G9 von Canon, die eine Belichtungsreihe mit einem Knopfdruck aufnehmen kann. D.h. es wird nicht nur ein Bild geschossen sondern zusätzlich noch ein oder mehr unterbelichtete und ein oder mehr überbelichtete. Die Belichtungen werden dann zum "perfekten" Bild kombiniert. Vorbei sind die Zeiten mit überstrahltem reinweißen Himmel!

Die Kombination zum HDR-Bild übernimmt Photomatix. Hat man mehrere Aufnahmen einer Szene, die sich überlappen kann man diese zu einem Panorama kombinieren. Gute Arbeit im automatischen zusammenpappen (stitching) leistet Autopano Pro. Doch genug der Vorrede, hier die Bilder: ich habe jeweils 3 Belichtungen in 5 veschiedenen Winkeln, also in der Summe 15 Bilder pro Panorama aufgenommen.

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