gis Analytik mit Grass und Quantum gis
Inhaltsverzeichnis
Team
Wolfgang, 0426588
Marek, 0425527
Einleitung
Problemstellung
Ziel unseres Open Source Projekts ist die Analyse der öv - Erreichbarkeit in den Wiener Bezirken. Dabei soll auch die Einführung der Nacht U-Bahn seit einigen Monaten betrachtet werden. Erste Überlegungen waren dann schließlich, dazu die Entfernung zu allen öv - Haltestellen der Wiener Linien mittels einer Netzwerkanalyse zu berechnen. Das Ergebnis könnte danach so aussehen, dass jeder Bezirk einen Erreichbarkeitsfaktor an Wochentagen (ohne Nacht U-Bahn) und am Wochenende (mit Nacht U-Bahn) erreicht und somit ein Vergleich gegeben ist, wo am meisten profitiert wird und wo sich die Situation eventuell sogar verschlechtert.
Hypothese
Die öv Erreichbarkeit ist durch die Einführung der Nacht U-Bahn zu diesen Zeiten an den Wochenenden in den Bezirken Wiens gestiegen.
Software
Für unsere Aufgabenstellung benötigen wir Geoinformationssystem-Software, die frei zur Verfügung steht. Marek kennt die Open Source Programme Gass gis und Quantum gis bereits lose wegen seines persönlichen Interesses diesbezüglicher Datenverarbeitung. Deshalb wussten wir auch schnell, dass diese Werkzeuge uns Ergebnisse liefern sollten, die wir später präsentieren werden. Da jedoch keiner von uns sich bereits näher mit diesen Open Source Programmen auseinandergesetzt hat, sollten wir erst beim Arbeiten selbst daraufkommen, welches der Programme für welche Arbeitsschritte besser geeignet ist.
Weitere Informationen
Sowohl Qgis, als auch GRASS bieten umfangreiche Dokumentationen an, die einen angenehmen Einstieg in die Programme ermöglichen.
Natürlich gibt es auch von den Communities der beiden Programme umfangreiche Foren und Wikis, welche alle möglichen Probleme behandeln. Es empfiehlt sich jedoch, wenn man bei einem Problem nicht weiter kommt, vorher an allen möglichen Schaltern zu drehen, bevor man eine Frage an die Community stellt, denn so lernt man auch am meisten.
Datenbeschaffung
osm Daten herunterladen
Das Projekt Openstreetmap, bei welchem Geodaten gesammelt und weitergegeben werden, bietet einen guten Startpunkt für die Beschaffung der, für unsere Analyse erforderlichen, Daten. Da es allerdings nicht möglich ist, große Datenmengen direkt über die Projekthomepage zu exportieren, greifen wir auf ein anderes Projekt zu, welches die in regelmäßigen Abständen aktualisierten Geodaten von Openstreetmap länderweise zur Verfügung stellt.
Abb1: Firefox. Quelle: Eigene Darstellung.
Bei Geofabrik finden wir die oben gezeigte Internetseite. Von dort wird die Datei austria.osm.bz2 auf die Festplatte heruntergeladen und dekompresiert (unter Windows z.B. mit 7zip). Die entpackte Datei müsste dann ca. 1,5gb haben.
Daten importieren
Im nächsten Schritt wird diese Datei ins Qantum gis importiert.Dazu gehen wir auf: Erweiterungen -> openstreetmap -> Load osm from file (abb.2) und füllen dann die Optionen, wie in Abb.3 zu sehen, aus. Wir brauchen nur die Spalten für Straßen und Bahnen, daher wollen wir nur diese zwei importiert bekommen. Ben. definierte Darstellung der Karten ist im Grunde egal, da wir sie nur kurz importieren und an grass weitergeben wollen und nicht darstellen werden. Dieser Vorgang dauert sehr lange. Bei unserm Rechner dauerte das Importieren mehrere Stunden. Siehe Anmerkungen weiter unten um den Vorgang zu beschleunigen.
Abb2. Qgis. Quelle: Eigene Darstellung.
Abb3. Qgis, osm Plugin. Quelle: Eigene Darstellung.
Abb4. osm Daten geladen. Quelle: Eigene Darstellung.
An dieser Stelle ist anzumerken, dass es, um Zeit zu sparen, möglich wäre, mit Osmosis die heruntergeladene osm Datei vor dem Importieren nach der Wiener Region zu stutzen. Dieses Tutorial will sich aber eher auf das Analysieren der Daten konzentrieren. Mehr Informationen dazu findet man beispielsweise hier.
Da dass Laden der Daten wirklich ewig dauert hier die Bounding Box Koordinaten für den "Großraum" Wien: Top: 48.34621 Left: 16.209526 Right: 16.567268 Bottom: 48.093674. Diese können mit Hilfe von Google Maps (Rechtsklick, "What's here?") bestimmt werden. Das Extrahieren mit Hilfe von Osmosis beschleunigt das Laden immens!
Ausschneiden
Das Ergebnis sehen wir in Abb. 4. Als Nächstes markieren wir den Layer austria.points, danach mit dem Auswahl-Werkzeug ein Stück Karte auf der Wien sicher drauf ist und gehen dann auf Bearbeiten -> Auswahl als Vektordatei speichern -> ok. Das gleiche wiederholen wir für den Layer austria lines. Danach schließen wir Quantum gis, öffnen es neu und laden mit Vektor-> Vektorlayer hinzufügen die neu erstellten Vektordateien (Abb 5).
Abb5. osm Daten ausgeschnitten. Quelle: Eigene Darstellung.
Projizieren
Man kann erkennen, dass die Karten falsch projiziert sind. openstreetmap projiziert nämlich die Vektoren als wgs84, was wir benutzen wollen ist aber utm Zone 33n. Das erreichen wir, indem wir im Menü auf Vektor -> Datenmanagement-Werkzeuge -> In neue Projektion exportieren gehen, dort auf Wählen clicken, dann ok und dann speichern es als eine neue Datei ab. Das machen wir wieder zweimal, einmal für lines und dann für points. (siehe Abb. 6). Achtung: Ab Version 1.7.1 gibt es den Dialog "In neue Projektion exportieren" nicht mehr. Das gleiche Result kann aber erreicht werden wenn man mit der rechten Maustaste auf den Layer klickt und ihn neu abspeichert. Im nachfolgenden Dialog kann man die gewünschte Projektion wählen.
Abb6. Auswahl der Projektion in Qgis. Quelle: Eigene Darstellung.
Bezirksgrenzen
Da im osm die Bezirksgrenzen nicht konsequent definiert wurden bzw. das Vervollständigen dieser mit viel Arbeit verbunden wäre, haben wir uns entschlossen, auf die Daten der MRS Übung zurückzugreifen. Durch Probieren wurde dann festgestellt, dass diese in mgi Austria Lambert 48 projiziert wurden (es wurde die Projektionsdatei .prj der gis Übung verwendet). Wir haben sie dann wie alle anderen Dateien in utm 33n projiziert.
Bearbeitung
Einführung in grass
grass gis ist eine freie gis Software. Sie wurde ab 1982 von der amerikanischen Regierung entwickelt und zur freien Verfügung gestellt. Seit 1999 wird es unter der gpl Lizenz veröffentlicht. Obwohl es bei unserer Präsentation den Eindruck gemacht hat, dass Grass instabil oder nicht fertig ist, muss man sagen, dass bei einer korrekten Installation und Konfiguration die Software sehr schnell und stabil arbeitet. Sie bietet abgesehen von den Standardwerkzeugen wie Vektor- und Rasterfunktionalität auch eine Vielzahl von spezialisierten Bearbeitungs- und Visualisierungsmöglichkeiten. Es wird in verschiedenen Bereichen professionell eingesetzt. In der Hydrologie, aber auch in der Meteorologie und Archäologie. Die Möglichkeiten der Software werden ständig erweitert und mit Hilfe von Python Scripts kann man sie mit relativ wenig Aufwand an die eigenen Anforderungen anpassen. Grass gis läuft sowohl auf Windows- Betriebssystemen, als auch unter Linux und Mac. Es gibt sehr viele Tutorials, welche den Einstieg in die Software ermöglichen. Hier möchten wir nur die Grundüberlegungen zusammenfassen, die das Verstehen des Tutorials vereinfachen. Das gis Datenverzeichnis, welches man beim ersten Start definieren muss, ist das Verzeichnis, in dem die Locations mit ihren Mapsets gespeichert werden. Eine Location ist grundsätzlich ein Projekt. Sie definiert das Koordinatensystem für das Projekt und die Rasterauflösung mit der gearbeitet wird und auch noch andere projektbezogene Einstellungen. Ein Mapset wiederum ist so etwas wie ein Kapitel im Projekt. Wir können für jede Aufgabe ein neues Mapset definieren - oder für jede Bearbeiterin und jeden Bearbeiter. Bei Projekten, die in einem Netzwerk bearbeitet werden, haben zusätzlich nur die Benutzer Schreibrechte, die ihr Mapset erstellt haben.
Importieren der Daten ins Grass
Wir starten Grass und erstellen eine neue Location für unser Projekt mit dem Location Wizard.
Im ersten Fenster wird der Name eingegeben (erreichbarkeit), im zweiten wählen wir die Option epsg-Code des Koordinatensystems, und im dritten suchen wir den Code 32633 (ist der epsg Code für wgs84/utm zone 33n mit dem wir weiter arbeiten werden).
Danach gehen wir auf Fertigstellen und Grass fragt uns, ob wir die Ausdehnung und Auflösung der Standardregion eingeben wollen, wollen wir aber nicht.
Schließlich wählen wir im Willkommensfenster die Projekt-Location erreichbarkeit und das Mapset permanent und gehen unten auf den grünen Knopf Start Grass.
Der Ebenen Manager und das Kartenfenster werden geöffnet. Wir arbeiten ab jetzt vor allem mit dem Ebenen Manager.
Abb.7: Grass, Ebenen Manager. Quelle: Eigene Darstellung.
Im unteren Teil des Fensters kann man zwischen drei Tabs wechseln:
- Map Layers: Hier kann man das Aussehen der Karten, welche im Kartenfenster angezeigt werden, steuern.
- Command Console: Hier werden Befehle für Module eingegeben.
- Search Module: In diesem Tab kann man nach spezifischen Modulen suchen.
Als Erstes erstellen wir für unsere neue Location eine Datenbank. Dazu geben wir im Tab Command Console folgenden Befehl ein:
db.connect driver=sqlite database=$GISDBASE/$LOCATION_NAME/$MAPSET/sqlite.db
Dieser Schritt ist insofern wichtig, als dass Grass ansonsten mit den Standardtreibern rechnet, also mit der dbf Datenank, und diese unterstützt die erweiterten sql Befehle nicht, die wir später verwenden werden.
Die Dateien können dann mit diesem Befehl importiert werden, die Adresse muss natürlich an den Speicherort der Dateien in der eigenen Arbeitsumgebung angepasst werden.
v.in.ogr dsn=E:\tutorial\lines_proj.shp output=lines
Für die Haltestellen dann entsprechend:
v.in.ogr dsn=E:\tutorial\montaghaltestellen.shp output=haltestellen_montag
sowie
v.in.ogr dsn=E:\tutorial\freitaghaltestellen.shp output=haltestellen_freitag
Und für die Gemeindegrenzen:
v.in.ogr dsn=E:\tutorial\gem_proj.shp output=grenzen
Darstellen kann man die neu erstellten Vektorkarten mit dem folgenden Befehl, wobei der Kartenname dabei durch den Namen, der im Output festgelegt wurde, ersetzt werden muss:
d.vect map=kartenname
Das Ergebnis schaut recht chaotisch aus, wie man in der nächsten Abbildung sehen kann. Die Punkte wurden rosa eingefärbt, darunter sieht man die Linien und grau die Gemeinden. Es sind recht viele Daten und im nächsten Schritt werden nur die, welche für die Analyse benötigt werden, ausgewählt.
Abb.8: Alle Daten eingefügt. Quelle: Eigene Darstellung.
Eingrenzen des Analysebereiches
In diesem Schritt werden alle Vektoren, welche außerhalb der Wiener Gemeindegrenzen liegen, gelöscht oder, genauer gesagt, werden Objekte, welche sich innerhalb dieser Grenzen befinden, in neue Vektorkarten geschrieben.
Zuerst werden die Wiener Bezirke in einer neuen Karte gespeichert.
v.extract input=grenzen output=grenzen_bezirke where=GEM > 90000
Input und Output sind selbsterklärend, where ist die Selektionsbedingung im sql Format. Hier werden Gemeinden ausgewählt, deren Kennzahl höher 90000 ist. In Niederösterreich sind ja alle Kennzahlen im 30000-Bereich.
Als Nächstes verschneiden wir die Karten linien und punkte mit der eben erstellten Karte bezirke.
v.overlay ainput=lines atype=line binput=grenzen_bezirke output=lines_bezirke operator=and
Der Operator "and" in dem Befehl bedeutet Schnittmenge, Schnittmenge aus lines und bezirke in diesem Fall.
Filtern der Daten
In diesem Kapitel werden aus der Gesamtheit aller Daten, die uns osm zur Verfügung stellt, nur die von uns benötigten durchgesiebt.
Grundsätzlich sind alle Vektordaten, sowohl Punkte als auch Linien, mit Attributtabellen verbunden. In diesen Tabellen sind die Eigenschaften aller Objekte gespeichert. Solche Eigenschaften können beispielsweise beschreiben, ob ein bestimmter Punkt auf der Karte eine Apotheke ist oder eine Haltestelle. Durch gezieltes Durchsuchen dieser Tabellen kann man folglich nur die, die man für die Analyse benötigt, auswählen.
Die Spalte highway der Attributtabelle lines gibt über die Straßenart Auskunft. Diese Seite bietet darüber mehr Auskunft.
Für unsere Untersuchung müssen wir von diesen Straßenarten folgende auswählen: living_street, pedestrian, primary, residential, secondary, tertiary. Diese werden mit folgendem Befehl ausgewählt und in eine neue Vektordatei wege gespeichert:
v.extract input=lines_bezirke output=strassen_bezirke where=(a_highway === 'living_street') or (a_highway === 'pedestrian') or (a_highway === 'primary') or (a_highway === 'residential') or (a_highway === 'secondary') or (a_highway === 'tertiary')
Die Tabelle schaut jetzt so aus (mit dem Befehl db.describe -c -t table=strassen_bezirke erstellt):
Abb.9: Ergebnis eine db.describe Abfrage. Quelle: Eigene Darstellung.
Man könnte fragen, wieso aus der Spalte ?highway? der Tabelle lines jetzt ?a_highway? in der Tabelle lines_bezirke geworden ist. Durch den Verschnitt mit dem Befehl v.overlay wurden auch die dazugehörenden Tabellen miteinander verschmolzen. Damit die Spalten der beiden Tabellen nicht durcheinanderkommen, haben alle Spalten aus line die Präfix "a_" und aus bezirke "b_" in der neuen lines_bezirke bekommen. Für die Analyse ist das insofern von Bedeutung, als dass jetzt jeder Straßenzug mit dem Auslesen der Spalte b_gem nach seiner Bezirkzugehörigkeit abgefragt werden kann.
Die Daten weisen einige Probleme auf. Beispielsweise sind sowohl Kärntner Straße oder Meidlinger Hauptstraße Fußgängerzonen, aber auch die Prater Hauptallee, wobei es hier in Wirklichkeit aber völlig unterschiedliche Nutzungen gibt. Das ist ein Fehler des Datenmaterials.
Abb.10: Oben: Alle lines aus osm. Unten: Straßen, rausgefiltert. Quelle: Eigene Darstellung.
Die zwei Karten veranschaulichen die letzten zwei Schritte. Die obere zeigt das Ergebnis des Verschnitts mit den Bezirken (rosa sind die Bezirksgrenzen) und die untere das Rausfiltern aller nicht benötigten Linien.
Analyse der Daten
In diesem Kapitel werden die zuvor erstellten und importierten Daten mit den in grass vorhanden Werkzeugen analysiert. Zuerst wird die analytische Vorgangsweise erläutert, dann die technische Umsetzung erklärt. Danach besprechen wir die Ergebnisse. Die Kritik an der von uns gewählten Vorgangsweise sowie mögliche Erweiterungen der Methoden werden dann im darauf folgenden Kapitel diskutiert.
Vorgangsweise
In diesem Teil der Arbeit soll mit einfachen Methoden die Erreichbarkeit des ÖV Netzes in der Nacht untersucht werden. Dazu wird zwischen zwei Szenarien unterschieden. Zum einen wird der ÖV Verkehr unter der Woche, zum anderen am Wochenende analysiert. Dieser Vergleich ist insofern wichtig, als dass am Wochende das Netz einerseits ausgeweitet wird, andererseits aber löst die Ubahn gleichzeitig einige Nachtbusse ab. Die Einzugsbereiche werden dann bezirksweise miteinander verglichen.
Dazu sind also grundsätzlich drei Schritte notwendig.
- Die Berechnung der Gesamtlänge aller Straßen pro Bezirk.
- Die Berechnung der Erreichbarkeit aller Haltestellen pro Bezirke für die zwei Szenarien.
- Das Verhältis der erreichbaren Straßen zum gesamten Straßenbestand pro Bezirk.
Als Letztes muss noch geklärt werden, wie die Erreichbarkeit einer Haltestelle gemessen werden kann. Mit den uns zur Verfügung stehenden Daten kann es nur durch Längen ermittelt werden (andere Lösungsansätze siehe Literaturhinweise). Die einfachste Variante wäre es, Luftlinien-Puffer innerhalb eines fixen Abstandes von jeder Haltestelle zu erstellen und dann die in dem Bereich liegenden Straßen abzumessen. Diese Methodik hat aber einige Nachteile. Zum Beispiel ist in den meisten Fällen die Fußwegdistanz aufgrund verschiedener Barrieren, wie Gebäude, Brücken etc. länger als die Luftliniendistanz. Aus diesem Grund wird bei dieser Analyse der so genannte Service-Bereich Ansatz verwendet. Dieser Ansatz geht von der Annahme aus, dass die Einzugsbereiche von Einrichtungen in Städten entlang von vordefinierten Pfaden, sprich Straßen begrenzt sind.
Die Präzision des Service Bereich Ansatzes hängt zum großen Teil von der Genauigkeit der gis Daten ab. Bei Andersen/Landex, 2009 wird vor allem auf zwei Fehlerquellen hingewiesen: Einerseits muss sichergestellt werden, dass nicht nur Straßen, sondern auch Fußwege (Parkanlagen etc.) digitalisiert werden. Zum Anderen werden manche Straßenzüge, wie Autobahnen, oft doppelt digitalisiert, für jede Fahrbahn eine Vektorlinie. Was die erste Fehlerquelle angeht, so haben wir uns entschlossen, Wege, die nicht der Erschließung von Gebäuden dienen, aus dem Datensatz möglichst auszuschließen, denn das Ergebnis soll einen Wert für die Erschließung der Haltestellen darstellen. Zum Zweiten werden die Fahrspuren in osm als Attribute gespeichert, nicht als parallel verlaufende Vektoren.
Wir gehen von einer Durchschnittsgeschwindigkeit von 85m pro Minute aus. Legt man eine zumutbare und akzeptierbare Marschstrecke bis zur nächsten Haltestelle mit fünf Minuten fest, dann erhält man eine Distanz von 425m. Mit dieser Distanz werden wir weiter rechnen.
Zum Schluss soll eine Sensitivitätsanalyse durchgeführt werden. Deren Ziel ist es, die Anfälligkeit des Modells auf Veränderungen der Variablen zu testen. In unserem Fall wird der Puffer um 50m vergrößert und mit den Ergebnissen der Untersuchung verglichen.
Berechnen der Gesamtlänge pro Bezirk
Als Erstes werden wir die Strassenlängen auf Bezirke aggregieren. Das Ergebnis soll in einer externen Datei gespeichert werden, die bei der Auswertung der Ergebnisse in ein anderes Programm (OOo zum Beispiel) importiert werden soll.
Wie man in der Spaltenauflistung weiter oben sehen kann, hat die Tabelle keine Informationen bezüglich der Länge der Strassen. Diese fügen wir mit dem Befehl v.to.db hinzu. Zuerst erstellen wir aber eine neue Spalte Namens length und Gleitkommazahlformat double.
v.db.addcol map=strassen_bezirke columns=length double
Und jetzt speichern wir die Vektorlängen in der neuen Spalte.
v.to.db map=strassen_bezirke option=length units=k columns=length
Der zweite Schritt besteht darin, die berechneten Längen nach Bezirken zusammenzufassen und in einer Datei zu speichern. Beide Schritte werden mit einem Befehl unternommen:
db.select sql=SELECT "b_GEM", SUM("length") FROM "strassen_bezirke" GROUP BY "b_GEM" fs=; output=E:\tutorial\laenge_gesamt.csv
Der Befehl db.select führt die schon früher erwähnten sql Anfragen aus. Die Anfrage ist leicht zu verstehen. Wähle Spalte b_GEM, berechne die Summe der Spalte length aus der Tabelle strassen_bezirke und gruppiere sie nach der Spalte b_GEM (siehe auch http://www.1keydata.com/sql/sqlgroupby.html).
Die nächste Tabelle zeigt das Ergebnis.
Die Gesamtlänge beträgt demnach 2845 km. Noch Zahlen und Fakten zum Wiener Straßennetz:
Das Wiener Straßennetz umfasst derzeit eine Länge von rund 2.800 Kilometern (davon 51 Kilometer Autobahnen und Schnellstraßen sowie 216 Kilometer Hauptstraßen
mit einer Fläche von insgesamt zirka 40 Quadratkilometern. Demnach ist unser Ergebnis akzeptabel.
Zwei Anmerkungen an dieser Stelle: An manchen Betriebssystemen muss man die sql Abfrage in Anführungszeichen setzen, damit sie ausgeführt wird. Nach sql== und vor fs=; ist also jeweils ein Anführungszeichen. Der Code würde dann so aussehen:
db.select sql="SELECT "b_GEM", SUM("length") FROM "strassen_bezirke" GROUP BY "b_GEM"" fs=; output=E:\tutorial\laenge_gesamt.csv
Grass benutzt einen Punkt um den ganzzahligen Teil der Zahl zu trennen. Wenn man die Tabelle also in Excel importiert, kann sie falsch interpretiert werden. Es empfiehlt sich, vorher mit einem Texteditor alle Punkte durch Kommas zu ersetzen. Oder auf Excel zu verzichten.
Berechnen der Erreichbarkeit der Haltestellen
Die Ermittlung der Erreichbarkeit erfolgt grundsätzlich in drei Schritten. Als Erstes muss das Netzwerk für die Analyse vorbereitet werden. Im zweiten Schritt wird die Analyse dann durchgeführt und zum Schluss werden die Ergebnisse exportiert.
Netzwerkbereinigung
Da die Haltestellen nicht direkt auf den Straßen liegen, müssen sie damit verbunden werden. Das erledigt der folgende Befehl:
v.net input=strassen_bezirke points=haltestellen_montag output=strassen_haltestellen_montag operation=connect alayer=1 nlayer=1 thresh=20
Mit diesem Befehl werden mehrere Aufgaben auf einmal durchgeführt. Einerseits werden Haltestellen und Straßen in einer gemeinsamen Vektorkarte gespeichert, was Voraussetzung für weitere Werkzeuge ist (v.net.iso), andererseits werden die Haltestellen mit den Straßen durch Linien verbunden (die Haltestellen befinden sich ja nicht direkt auf den Straßen, sondern müssen erst mit dem Netz verbunden werden). Zum Schluss werden kleine Unterbrechungen im Netzwerk geschlossen.
Durchführen der Analyse
Der Befehl, welcher den Service Area Ansatz umsetzt lautet v.net.iso. Der Input ccats gibt an, für welche Punkte die Puffer berechnet werden sollen. Angegeben werden sie mit ihren Kategorie-Nummern "cat". Jeder Haltestelle ist nämlich eine eindeutige cat Nummer zugewiesen. Mit 1-999 werden einfach alle miteinbezogen. Mit costs werden die Pufferlängen definiert. Wir haben zwei festgelegt, 425m und 475m für die Sensitivitätsanalyse.
v.net.iso input=strassen_haltestellen_montag output=erreichbarkeit_montag_425 nlayer=1 ccats=1-999 costs=425,475
Die neu erstellte Vektorkarte erreichbarkeit_montag_425 verfügt zwar über alle benötigten Daten, sie wurden aber als sogenannte Features in der Vektorkarte gespeichert. Damit wir mit den Ergebnissen rechnen können, müssen wir sie aber in eine Tabelle extrudieren. Das wird mit folgendem Befehl erledigt:
v.db.addtable map=erreichbarkeit_montag_425
Abb.11: Ergebnis der Analyse für Szenario Montag. Quelle: Eigene Darstellung.
Die grau gefärbten Straßenabschnitte liegen innerhalb der 425m Grenze. Zoomen wir etwas näher heran:
Abb.12: Ausschnitt aus der Analyse. Dargestellt in qgis. Quelle: Eigene Darstellung.
Hier sieht man den Vorteil der Methode gegenüber dem einfacheren Luftlinien-Puffer. Eine Straße, welche in direkter Nähe der Haltestelle liegt, ist nicht erreichbar. Das kann verschiedene Gründe haben, doch fehlen hier die Daten um diese genauer zu untersuchen. Die Karte wurde diesmal mit Qgis erstellt, da dort die Kartendarstellung viel einfacher gehandhabt wird.
Aufbereitung der Ergebnisse
In diesem Schritt wird die Gesamtlänge pro Kategorie, aggregiert auf Bezirke, exportiert.
Durch die v.net.iso Operation ging, wie wir schon oben festgestellt haben, die Tabelle mit den Längen und Bezirkzugehörigkeiten, verloren. Daher muss die Karte mit den Erreichbarkeiten mit den Bezirksgrenzen neu geschnitten werden.
v.overlay ainput=erreichbarkeit_montag_425 atype=line binput=grenzen_bezirke output=erreichbarkeit_montag_425_bezirke operator=and
Dann erstellen wir eine neue Spalte, in der wir die Längen speichern werden.
v.db.addcol map=erreichbarkeit_montag_425_bezirke columns=length double
Als Nächstes speichern wir die Längen in die neue Spalte length:
v.to.db map=erreichbarkeit_montag_425_bezirke option=length units=k columns=length
Der letzte Punkt ist das Aggregieren und Exportieren. Am einfachsten erstellt man drei neue Tabellendateien, wie schon oben, und verarbeitet sie dann weiter in einem anderen Programm.
db.select sql=SELECT "b_gem", SUM("length") FROM "erreichbarkeit_montag_425_bezirke" WHERE "a_cat" === 1 GROUP BY "b_gem" fs=; output=E:\tutorial\laenge_montag_cat1.csv
db.select sql=SELECT "b_gem", SUM("length") FROM "erreichbarkeit_montag_425_bezirke" WHERE "a_cat" === 2 GROUP BY "b_gem" fs=; output=E:\tutorial\laenge_montag_cat2.csv
db.select sql=SELECT "b_gem", SUM("length") FROM "erreichbarkeit_montag_425_bezirke" WHERE "a_cat" === 3 GROUP BY "b_gem" fs=; output=E:\tutorial\laenge_montag_cat3.csv
Hier sehen wir das Ergebnis für die drei Kategorien. 1 liegt innerhalb der 425m Zone, 2 innerhalb von 475m, 3 ist ausserhalb. Wenn man die Daten mit dem Gesamt bestand an Strassen für Wien vergleicht, so ergibt sich ein anderes Ergebnis. Der Grund dafür ist, dass manche Wege an das Netzwerk nicht angeschlossen sind, stellen so zu sagen Inseln dar. v.net.iso kommt an diese also nicht heran und deshalb kommen sie in dieser Tabelle nicht vor.
Analyse für Szenario Freitag
Jetzt muss die ganze Analyse für das zweite Szenario durchgeführt werden. Im Grunde bleibt die Vorgangsweise gleich, es müssen nur andere Karten verwendet werden, bzw. muss auf die Überschreibung der Tabellen aufgepasst werden. Im Grass selbst ist das Überschreiben von Dateien nur mit einer sehr ausführlichen Erlaubnis gestattet (Attribut --overwrite am Ende der Befehle). Eine Hilfe bietet die Auflistung aller verwendeten Karten im Anhang.
Man soll beachten, dass es im achten Bezirk keine Wege der Kategorie 3 gibt. Dies ist insofern von Bedeutung, da Grass diese Zeile dann auslässt, anstatt ihr den Wert 0 zu geben. Das muss händisch korrigiert werden.
Analyse der Ergebnisse
Zuerst noch einmal die Erklärung zu den Kategorien:
Das gesamte Straßennetz eines Bezirkes wird in die schon vorgestellten Kategorien 1, 2 und 3 eingeteilt. Die Straßenlängen der ersten Kategorie befinden sich in einem "Einzugsgebiet" von höchstens 425m bis zur nächsten ÖV Haltestelle. Die Straßenlängen in der zweiten Kategorie weisen eine Entfernung von mehr als 425m bis höchstens 475m bis zur nächsten Haltestelle auf. In die dritte Kategorie schließlich fallen jene Straßenlängen, die weiter als 475m entfernt sind.
Sieht man sich nun die Anteile der Straßenlängen in einem Bezirk an diesen Kategorien an, so kann man sagen, wie gut ein Bezirk von ÖV Haltestellen erschlossen ist.
Beispiele:
Fällt das gesamte Straßennetz in die Kategorie eins, so ist dieser Bezirk unseren Annahmen entsprechend perfekt erschlossen. Es gibt also keine Stelle an einer Straße, von der aus ich mehr als 425m bis zur nächsten Haltestelle gehen muss.
Fallen mehr als 60% des Straßennetzes in die 3. Kategorie, so ist der Bezirk schlecht erschlossen. Bei mehr als der Hälfte aller Straßenstellen im Bezirk muss ich weiter als 475m bis zur ÖV Haltestelle gehen.
Analyse für Szenario "Vor Werktagen"
Die nachfolgende Tabelle zeigt nun die berechneten Ergebnisse für jeden Wiener Gemeindebezirk. Herausgehoben wurden die Bezirke, die besonders gute Erreichbarkeiten aufweisen (grün) sowie jene, bei denen gesagt werden kann, dass die ÖV Haltestellen durchschnittlich sehr weit entfernt sind (rot). Wirklich sehr gut erschlossen sind der 7. und der 9. Bezirk. In letzterem befinden sich über 85% des Straßennetzes innerhalb der ersten Kategorie. Auch überdurchschnittlich gut erreichbar und wahrscheinlich auch etwas überraschend ist der 10. Bezirk laut unseren Berechnungen. Sehr schlecht schneiden die Bezirke 21 und 22 ab, was jedoch sowohl durch die Größe des Straßennetzes zu erklären ist als auch durch die Randlage jenseits der Donau. Überraschender ist dafür wiederum, dass der 13. und 14. Bezirk schlechter abschneiden als zum Beispiel der 11. oder der 23. Bei den Bezirken, die weder besonders positiv noch besonders negativ bezüglich ihrer ÖV Erreichbarkeit eingestuft worden sind, kann eventuell zum 2. Bezirk noch erwähnt werden, dass der Prater die Ergebnisse etwas verfälscht. Tendenziell kann gesagt werden, dass die inneren Bezirke besser erreichbar sind als die Außenbezirke, wobei es Ausreißer auf beiden Seiten gibt (10. Bezirk; 2. Bezirk).
Abb.13: Ergebnisse, vor Werktagen.
Analyse für Szenario "Vor Sams- Sonn- und Feiertagen"
Hier die Ergebnisse:
Besonders gut schneiden der 4., 6., 7., 8., und 9. Bezirk ab. Die Josefstadt ragt hier besonders heraus, befinden sich doch beinahe 100% des Straßennetzes in der ersten Kategorie. Wirklich schlecht ist die Erreichbarkeit nur in den Bezirken 13, 21 und 22.
Abb. Ergebnisse, Szenario Freitag.
Man soll beachten, dass es im achten Bezirk keine Wege der Kategorie 3 gibt. Dies ist insofern von Bedeutung, da Grass diese Zeile dann auslässt, anstatt ihr den Wert 0 zu geben. Das muss händisch korrigiert werden.
Vergleich "Vor Werktagen" mit "Vor Sams-, Sonn- und Feiertagen"
Durch die U-Bahn, die nur im 2. Szenario fährt, erwartet man vielleicht, dass dieses auch in allen Bezirken eine bessere Erreichbarkeit ergibt. Dass dies nicht so ist, zeigt die Tabelle unten. Aufgrund des Wegfalles einiger Nachtbusse kommt es in manchen Bezirken nämlich genau umgekehrt. Die Haltestellen des ÖPNV liegen nun durchschnittlich weiter weg, als im Szenario 1. Dies ist der Fall in den Bezirken 1, 3, 12, 15, 21, 23. Eine Begründung dafür ist, dass durch U-Bahnen substituierte Nachtbusse die gleiche Strecke fahren, aber deutlich mehr Haltestellen auf dieser Strecke aufweisen. Zu einer wesentlichen Verbesserung kommt es in den Bezirken 4, 5, 6, 8, 9, 13, 14, 16, 22. Die Veränderung in den restlichen Bezirken ist zu vernachlässigen. Jedoch ist bei der Großzahl dieser Bezirke eine minimale Verbesserung gegeben.
Abb.14: Vergleich der Ergebnisse
Abb.15: Verleich der Ergebnisse
Weitere mögliche Analysen
Neben unserer durchgeführten Netzwerkanalyse wären noch folgende weitere Berechnungen für die betrachtete Fragestellung sinnvoll (siehe auch Literaturverzeichnis für weitere Beispiele):
- Einzugsgebiete untersuchen auf Einwohnerzahlen oder bauliche Dichten
- Attraktivität der Haltestelle mit einbeziehen
- Erweiterung der Abstände zu Haltestellen mit Kreuzungen als Kosten
- Distanzgewichtung nach einer linearen oder Cosinusfunktion.
- Haltestellen gewichten nach Fahrzeit zum Zentrum.
- Gesamtreisezeit === Gehzeit + Wartezeit + Fahrzeit
Schlussfolgerungen
Stärken / Schwächen der Programme
Grass gis
Stärken:
- Sehr vielschichtig, viele Funktionen
- Arbeitet flüssig mit Qgis zusammen
- Gute Dokumentation, nette Community
- Als freie Alternative zu arcgis durchaus vorstellbar
Schwächen:
- Lernaufwand am Anfang hoch
- Kartenvisualisierung eingeschränkt
- Immer wieder trifft man auf Bugs, die Software wird aber ständig verbessert, täglich werden neue Versionen angeboten.
Quantum gis
Stärken:
- Einfach zu erlernen
- Bessere Kartenvisualisierung
- Einfache Bearbeitung/Überarbeitung von Vektorlayern
Schwächen:
- Stürzt häufig ab
- Nicht gut geeignet für Analyseaufgaben
Quellen
Andersen, Jonas Lohmann Elkjær; Landex, Alex, 2009: GIS-based Approaches to Catchment Area Analyses of Mass Transit. Working Paper.Department of Transport. Technical University of Denmark. http://proceedings.esri.com/dvd/uc/2009/uc/papers/pap_1072.pdf. Abruf: 10.10.2010
HTU Wien, “NightLine (Wien) - Stadtverkehr-Austria-Wiki,” http://xover.htu.tuwien.ac.at/~tramway/stvkr-a-wiki/index.php/NightLine_%28Wien%29. Abruf: 10.10.2010
Helmut Augustin und Birgit Binder, “Bauliche Dichte und ÖV-Erreichbarkeit Wiens” (MA18, Stadtentwicklung und Stadtplanung, Wien, o. J.).
Overkämpig, Beate und C. Rüther, Christoph, “Modellierung von Erreichbarkeit in GIS-Optimierung der Haltestellenplanung im ÖPNV,” CORP, Wien, Schrenk, M (2001).
Thomas Prinz und Stefan Herbst, “Multikriterielle Modellierung der ÖV-Erreichbarkeit für die Stadt Wien” (Research Studios Austria Forschungsgesellschaft mbh. Stadt Wien - MA18 - Stadtentwicklung und Stadtplanung, Juli 2008).
wien.at, “Zahlen und Fakten zum Wiener Straßennetz,” http://www.wien.gv.at/verkehr/strassen/fakten/zahlen.html. Abruf: 12.10.20101.
Anhang
Ablauf inkl. Operationen und Kartenbezeichnungen
Quelle: Eigene Darstellung.
