Am Anfang sind es Studenten und Künstler, die einen Stadtteil entdecken. Wir verraten, wie daraus ein Szeneviertel entsteht und welche Quartiere in Zukunft besonders gefragt sein werden

Ob es tatsächlich einen Zusammenhang zwischen Gewerbestruktureinrichtungen und Gentrification-Dynmiken gibt, wollen wir im Rahmen der GentriMap überprüfen. Idee ist es, die räumliche Verteilung von Veranstaltungsadressen mit den soziodemographischen und wohnungswirtschaftlichen Entwicklungen in den jeweiligen Gebieten zu vergleichen. Eine Herausforderung dabei ist die zeitliche Dokumentation von Veranstaltungsadressen auf Basis einer über die Jahre hinweg einheitlichen Systematik.

Als Datenbasis haben wir uns für die im Berliner Stadtmagazin TIP veröffentlichten Veranstaltungsadressen entschieden. Wir sind uns bewusst, dass diese Adressen jeweils nur einen Ausschnitt der Berliner Kulturangebote umfassen, aber durch den regelmäßigen Erscheinungstakt des Mediums selbst ist eine hohe Kontinuität der Datenreihe gewährleistet. Durch die freundliche Unterstützung des Magazins wurden uns Adressenlisten seit 1971 zur Verfügung gestellt, so dass wir die Entwicklung der Angebotsstruktur über einen langen Zeitraum darstellen können.

Die Freude über die freimütige Unterstützung unseres Projektes erhielt ein paar Kratzer als wir realisierten, das uns dieser Adressenschatz in Form von eingescannten Fotokopien der jeweiligen Zeitungsseiten aus dem Archiv der Zeitschrift zur Verfügung gestellt wurde.

TIP-Veranstaltungsadressen von 1973

Die Frage der händischen Übertragung in ein für uns nutzbares Datenformat stellte sich angesichts des Umfangs nicht wirklich und wir entschieden uns, es mit mit dem Freeware-Programm Tesseract zu versuchen. Damit gelang es, alle wesentlichen Informationen der gescannten Adresslisten in digitale Tabellen zu übertragen. Nur einge Hausnummern, Straßennamen und Namen der Veranstaltungsorte mussten nachberabeitet werden.

Auf der Basis der Adressdaten können Veranstaltungsorte nicht nur geographisch zugeordnet werden, sondern auch Veränderungen von Veranstaltungsorten an einem Ort können dargestellt werden.

Weil das Veranstaltungsangebot recht vielfältig ist – schließlich gibt es neben Clubs und Konzert-Locations auch Orte für Kunstveranstaltungen, Museen, Lesebühnen, Galerien usw. –, brauchten wir noch ein Kategorisierungsschema, um die unterschiedlichen Veranstaltungsorte nach ihrem Angebot zu unterteilen. Das TIP-Magazin hat über die Jahre keine Kategorisierung dauerhaft beibehalten und teilweise sogar gar keine Unterscheidung gemacht und stattdessen alle Adressen in einer alphabetischen Liste geführt. Letztendlich haben wir uns an den Kategorien orientiert, die akuell auf der Internetseite und in den Papierausgaben der TIP verwendet wird.

TIP-Veranstaltungsadressen von 2012 (Onlineversion)

Im Scraping-Verfahren haben wir die Veranstaltungsorte, Adressen und Kategorien von der Webseite des Stadtmagazins herausgelesen, so dass uns für 2012 eine komplette Zuordnung aller Adressen zu den Katergorien zur Verfügung stand.  Dabei haben wir auch gleich die Geodaten (Latituden- und Longitudenwerte) für die Veranstaltungsorte extrahieren können, weil auf der Internetseite meist ein Google Maps-Eintrag verlinkt ist.

Der Adressenbestand der Onlineversion ist ausführlicher als der der Printausgaben. Da uns in der Zeitreihe aber nur die Angaben der Printausgaben zur Verfügung standen, mussten wir uns schweren Herzens und um der Vergleichbarkeit Willen von einem Teil unsere gerade gescrapten Daten wieder trennen.

Mit einem kleinen Script wurde für die verschiedenen Jahren nach Übereinstimmungen von Adressen und Namen der Veranstaltungsort gesucht. So konnten Zeitpunkte der erstmnaligen Nennung von Veranstaltungsortenb in den Tip-Adressenlisten identifiziert werden, die wir für weitere Auswertungen als Neueröffnungen behandeln werden. Die Veranstaltungsorte, die es heute nicht mehr gibt und deshalb nicht automatisch nach der aktuellen Kategorisierung unterteilt werden können, mussten allerdings noch einzeln kategorisiert werden.

Für unsere Untersuchung des kulturellen Wandels in Berliner Stadtteilen haben wir uns also eine erste Datengrundlage geschaffen. Die ersten Auswertungen stehen noch aus, aber wir bleiben am Ball!

Im World Wide Web sind Daten zwar reichlich vorhanden und können von Menschen gelesen, strukturiert und verknüpft werden – aber in den seltensten Fällen sind sie machinenlesbar, und in den meisten Fällen sind sie ziemlich verstreut: Ein PDF-Dokument da, eine dynamisch erstellte Liste dort, Zeitungsarchive im Web, und so weiter.

Wenn ich beispielsweise Veranstaltungsadressen auf der Seite der Zitty suchen möchte, gebe ich entweder den Suchbegriff ein oder klicke mich hier durch: zitty.de/list. Wenn ich aber alle Veranstaltungsorte einer Kategorie brauche, für einen interaktiven Stadtplan, zum Beispiel, wird es mit Klicken und Kopieren schwierig.

Scraping, zu deusch “abschaben”, ist eine Technik, die Websites als “Datenbanken” im weitesten Sinne behandelt und automatisiert Daten von einer oder mehreren Seiten ausliest und in ein maschinenlesbares Format, zum Beispiel eine Datenbank oder eine Textdatei, schreibt. (Gefunden müssen wir sie übrigens schon haben.) Dafür gibt es eine Reihe von Tools, die die Programmierarbeit vereinfachen.

Eines davon ist das ScraperWiki - nicht zu verwechseln mit einem echten Wiki! – das ein Framework für den Zugriff auf Websites und die Speicherung der Daten sowie gleich eine Online-Programmierumgebung anbietet. Voraussetzung für eine kostenlose Nutzung ist, dass ScraperWiki den Quellcode und das Ergebnis eines programmierten Scrapers der Community anbietet. Wenn wir uns damit einverstanden erklären, und noch dazu eine der drei Programmiersprachen PHP, Python oder Ruby einigermaßen beherrschen, können wir uns mühseliges manuelles Kopieren der Zitty-Adressenliste sparen.

ScraperWiki bietet feine Tutorials in allen drei Sprachen zur Einführung an, hier das in Python. Das Vorgehen beim Scrapen ist mehr oder weniger das selbe wie dort beschrieben:

1. Eine HTML-Seite aus dem Web laden.
2. Die HTML-Seite in eine bearbeitbare XML-Struktur aufsplitten (parsen)
3. Aus dem XML die benötigten Daten auslesen und weiter bearbeiten
4. Daten speichern

Also müssen wir vor dem Scrapen über die Struktur der HTML-Seite, die unsere Daten enthält, Bescheid wissen. Informationen darüber bekommt man zum Beispiel über das Firefox-Plugin Firebug.

Weiter im Beispiel. Zunächst laden wir die entsprechende Seite und parsen sie:

html = scraperwiki.scrape(http://www.zitty.de/anstalt-wedding-jugendgalerie.html))
leaf = lxml.html.fromstring(html)

Eine Veranstaltungsadresse in der Zitty-Liste hat auf ihrer Seite eine Kategorie, einen Namen/Titel und eine Adresse mit Postleitzahl, Straße, Hausnummer und altem Bezirk bzw. Landkreis (wenn in Brandenburg). Die HTML-Struktur: In einem eindeutigen <dl>-Container sind unsere Informationen aufgelistet:

<dl>
    <dt>Anschrift</dt>
    <dd>
        <ul>
            <li>Anstalt Wedding - Jugendgalerie</li>
            <li>Osloer Str. 103</li>
            <li>13359 Berlin (Wedding)</li>
        </ul>
        </dd>
        <dt>Internet</dt>
        <dd>
        <dt>Kontakt</dt>
        <dd>
</dl>

Da die Reihenfolge und Anzahl der <dt>-<dd>-Paare variiert, wird das jeweilige <dd>-Tag über den Text im vorigen <dt>-Tag identifiziert, in unserem Fall “Anschrift”. Dafür erzeugen wir eine Liste mit dem Inhalt der <dt>-Tags. In einem über lxml geparsten HTML-Dokument wählt man einzelne Elemente mit .cssselect(selstring), wobei selstring ein gültiger CSS-Selector-String sein muss.

keys = []
for dt in leaf.cssselect("dt"): keys.append(dt.text_content())

Über den Index jenes Elements, das den String “Anschrift” enthält, finden wir das dazugehörige <dd>-Tag, selektieren darin wieder die <li>-Tags und weisen deren Inhalte dem data-Dictionary zu. Später können wir die ausgelesenen Daten noch um Kontakt oder Weblinks erweitern.

i = 0
        for dd in leaf.cssselect("dd"):
            if keys[i] == "Anschrift":
                addr = dd.cssselect("li")
                data.update( { "name" : addr[0].text_content(), "address" : addr[1].text_content(), "district" : addr[2].text_content() } )
 #elif weitere Daten wie Kontakt und Web hinzufügbar
            i += 1

Die Geokoordinaten der Adresse sind anderswo im HTML-Code versteckt, glücklicherweise in eindeutigen <span>-Tags mit den Klassen latitude und longitude:

<span class="latitude">52.555730</span>
<span class="longitude">13.381410</span>

for latitude in leaf.cssselect("span.latitude"): data.update( {"latitude" : latitude.text_content().strip()} )
for longitude in leaf.cssselect("span.longitude"): data.update( {"longitude" : longitude.text_content().strip()} )

scraperwiki.sqlite.save(unique_keys=['name'], data=data)

from lxml.cssselect import CSSSelector
linkselector = CSSSelector("a")

for th in root.cssselect("th.teaser-cell"):
    for e in linkselector(th): innerhtml = "http://www.zitty.de/" + e.get('href').strip()
    leaf = lxml.html.fromstring(scraperwiki.scrape(innerhtml))
    #leaf wird wie oben gezeigt weiter verwendet...

Für uns war vermutlich die Webanwendung FIS-Broker am auffälligsten: Eine interaktive Karte, die von den verschiedenen Abteilungen der SenStadt für Berichte genutzt wird. Der Broker selbst verweist nur auf die Daten, die auch von anderen Senatsverwaltungen stammen können, und bietet den Zugang dazu an. So gut wie alle Karten, die wir in den Berichten gefunden haben, basieren auf einem FIS-Broker-Output. Leider ist der FIS-Broker für ungeübte Benutzer schwierig zu bedienen – und obendrein noch ziemlich langsam. Für unsere Bedürfnisse kommt noch hinzu, dass es in den meisten Fällen weder möglich ist, Karten zu überlagern, noch das Datenmaterial zu den Karten herunterzuladen. Berücksichtigt man den eingeschränkten Anwendungsbereich des FIS-Brokers, stellt er eine wirklich gute Übersicht über die Geodaten dar, die bei der SenStadt verwendet werden.

Der letzte Hackday der Open Knowledge Foundation drehte sich rund ums Thema Geoinformationsdaten und FIS-Broker. Einerseits, um die Benutzeroberfläche des Brokers zu optimieren, andererseits, um den Austausch und die Diskussion um Offene Daten in Berlin anzuregen. Wir sind schon gespannt auf die Ergebnisse!

Jetzt schon als Offene Daten verfügbar sind übrigens die Lebensweltlich Orientierten Räume (LOR) als Geodaten zum Download und zum Einbinden in eigene Geoanwendungen.

Neben den Wohnatlas und der Mietspiegel-Übersicht sowie Infos zu Quartiersmanagement und Aktionsräumen waren folgende Berichte, in denen Daten zu sozialen und wohnungsbaulichen Veränderungen vorkommen, für uns interessant: Das Monitoring Soziale Stadtentwicklung, der Wohnungsmarktbericht und der Umweltatlas. Dazu mehr in Teil 2…

Wir haben uns als interdisziplinäres Team zusammengerauft – so viel zu unserer persönlichen Befindlichkeit. Wir haben aber auch ein Gentrification-Modell entwickelt, das unterschiedliche Erklärungsansätze mit einbezieht. Wir erklären das Phänomen “Aufwertung der und Vertreibung aus innenstadtnahen Lagen” nicht einseitig aus angebots- oder nachfrageseitigen ökonomischen oder kulturellen Faktoren, sondern versuchen, die Beziehungen zwischen diesen Erklärungsmodellen zu verstehen und in ein erweitertes Modell zu integrieren. Das führt in erster Linie zu dem Problem, dass wir einerseits Abhängigkeiten der Daten über die Zeit hinweg modellieren müssen, andererseits, dass wir diese Daten erst finden müssen:Zu Projektbeginn beabsichtigten wir, dass unser Datenmaterial möglichst aus so genannten (Linked) Open Data-Quellen stammen sollte, also aus Datenmaterial, das öffentlich und frei verfügbar und darüber hinaus auch maschinenlesbar ist. Mehr zu Open Data hier: wikipedia.org/wiki/Open_Data und hier: okfn.de. Beispiele für Open-Data-Anwendungen im deutschsprachigen (aber nicht nur) Raum finden sich hier: opendata-showroom.org. Im Gegensatz zum angloamerikanischen Raum – siehe zum Beispiel data.gov, die offizielle Seite der US-amerikanischen Regierung; daneben lassen sich noch Daten von Stadtverwaltungen finden – steckt Open Government Data am Europäischen Festland noch in den Kinderschuhen. Erste Bemühungen für Berlin lassen sich auf daten.berlin.de finden. Nach einiger Recherche können wir sagen: Das Portal vereint wirklich beinah alle berlin-relevanten Daten, die einigermaßen als Open Data bezeichnet werden können…

Deshalb haben wir uns weiter auf die Suche gemacht und Berichte und Kartenmaterial durchforstet, mit dem Ziel, Zugang zu verwertbarem Datenmaterial zu bekommen, das diesen Karten und Berichten zugrunde liegt. Aktuell sind wir dabei, bei den zuständigen Stellen um die Basisdaten anzufragen. Gleichzeitig versuchen wir, im Internet vorhandene, aber verstreute, Daten mittels so genanntem Scraping “zusammen zu kratzen” – eine im Data Journalism verbreitete Technik, über die wir in den nächsten Tagen mehr berichten werden…

In unserem Blog werden wir in unregelmäßigen Abständen von unseren Rechercheerlebnissen und -ergebnissen erzählen, den Projektfortschritt dokumentieren, interessante Hintergrundinfos zu Forschung, Technik und Politik bereit stellen und aktuelle Entwicklungen der Stadtentwicklung in Berlin und Anderswo beleuchten. Neues zu OpenData, zu Geoinformationssystemen, zu Stadtteilinitiativen gibt es genug – unser Team ist interdisziplinär, also werden das auch die Infos sein. Von uns selbst erarbeitete Inhalte und Anwendungen findet ihr dann eher auf den statischen Seiten.