Hilden
zu Fuß
Ortsgruppe des
Hinweis: Zwischenzeitlich wurde die Berechnung etwas überarbeitet. Das betrifft vor allem die Auswahl der Gemeinden (jetzt Gemeindeverbände, Gemeinden und Bezirke in Berlin und Hamburg), sowie die Färbung der Karten. Dies wurde auf dieser Seite nicht berücksichtigt. Im Wesentlichen ist aber fast alles gleich geblieben...
Die Berechnung des Speed-Index bassiert auf den OpenStreetMap-Daten von Deutschland, die ich vom Geofabrik-Server bezogen habe. Diese Datei ist derzeit 3,0 Gigabyte groß.
Aus diesen Daten berechne ich als erstes die Grenzen aller Bundesländer
und aller Gemeinden. Mit Hilfe des Programms osmium werden zuerst
einmal alle Relationen herausgefiltert, die die folgenden drei Eigenschaften
haben:
admin_level ist gesetzt,
de:amtlicher_gemeindeschluessel ist gesetzt und
type ist gesetzt und hat den Wert boundary.
Die resultierende Datei ist 24 Megabyte groß. Diese wandle ich mit
osmconvert für die weitere Verarbeitung in das
O5M-Datenformat um (50 Megabyte). Und verwende dann ein
selbstgeschriebenes Programm, welches die gewünschten Grenzen
extrahiert und als .poly-Dateien speichert.
Bundeslandgrenzen erkennt das Programm an admin_level=4
und Gemeindegrenzen daran, dass der amtliche Gemeindeschlüssel
(de:amtlicher_gemeindeschluessel) eine Länge von 8
Zeichen aufweist und es sich nicht um ein gemeindefreies Gebiet
handelt.
Zudem erstellt dieses Programm eine Liste aller Bundesländer (16) und Gemeinden (10835).
Notiz: Hier wäre es vermutlich für die Zukunft sinnvoller, auf den Reginalschlüssel zu setzen und den Speed-Index nicht für Gemeinden, sondern für Gemeinde-Verbände zu berechnen. Für die vielen kleinen Gemeinden besitzt der Index ohnehin kaum Aussagekraft...
Löcher.
© OpenStreetMap-Mitwirkende, Bernhard Seckinger (ODbL)
Zu einigen Bundesländern und Gemeinden gehört ein Teil des Meeres. Für die Darstellung in Karten sind diese Grenzen unüblich, hierfür wird die Landmasse der entsprechenden Bereiche benötigt. Glücklicherweise ist diese in den OpenSteetMap-Daten ebenfalls gespeichert.
Erneut benutze ich osmium und extrahiere alle Relationen
bei denen der Tag land_area gesetzt ist und den Wert
administrative aufweist (2,9 Megabyte, in O5M umgewandelt
5,5 Megabyte).
Mit einem selbstgeschriebenen Programm extrahiere ich hieraus alle Landmassen-Polygone, auch gleich das für ganz Deutschland. Zu beachten ist, dass derzeit Hamburg eine Extrawurst braucht, weil die Daten in OpenStreetMap (in meinen Augen) fehlerhaft abgelegt sind.
Für die Berechnung des Speed-Index brauche ich ebenfalls nicht alle
Daten aus der Deutschland-Datei. Ich verwende einmal mehr
osmium um die folgenden Daten zu extrahieren:
traffic_sign=city_limit,
highway-Tag und
landuse-Tag, wenn
dieser residential, village_green,
retail, recreation_ground oder
allotments lautet.
Die so erstellte Datei ist 874 Megabyte groß.
Da die Dateien trotz allem immernoch recht groß sind, werden in
einem Zwischenschritt aus der Daten-Datei alle Daten für die einzelnen
Bundesländer herausgeschnitten. Hierfür kommt noch einmal
osmium zum Einsatz. Es wird mit der Option
complete_ways aufgerufen, damit Wege über die
Bereichsgrenzen hinweg erfasst werden. Das Ergebnis sind Datendateien
für alle Bundesländer von 3,8 Megabyte (Bremen) bis 180 Megabyte
(Bayern). Diese werden wiederum mit osmconvert ins
O5M-Datenformat umgewandelt (6,1-305 Megabyte).
Als nächstes kommt der Schritt, bei dem aus den Bundesland-Daten,
die Daten für die einzelnen Gemeinden berechnet werden. Diesen Schitt
könnte man auch mit osmium erledigen, aber das lässt sich
wegen Speicherplatzproblemen nicht vernünftig parallelisieren, was
dazu führt, das zwar jede einzelne Datei schneller extrahiert werden
kann, im Gesamten das Extrahieren aber viel, viel länger dauert.
Ich benutze stattdessen osmconvert, was das gleiche
Ergebnis liefert, wo ich aber immer vier Gemeinden gleichzeitig
berechnen kann. Etwa zwei Stunden später sind diese dann berechnet.
Die über 10,000 Dateien reichen von 2,3 Kilobyte bis 18 Megabyte.
Dieser, und die nächsten drei Schritte, werden von einem einzigen, selbstgeschriebenen, Programm ausgeführt. Auch hier können immer vier Gemeinden gleichzeitig berechnet werden.
Wie oben schon geschrieben, wurden alle Daten über den Rand der Gemeindegrenze fortgesetzt, damit keine Wege verloren gehen. Für die Berechnung des Speed-Index ist es notwendig, diese exakt an den Grenzen abzuschneiden. Die mir bekannten Tools können das alle nicht; in vielen Fällen ist es auch gar nicht wünschenswert.
Mein Programm führt den Feinschliff deswegen selber durch, indem es zusätzliche Punkte an den Gebietsgrenzen einfügt und alles entfernt, was außerhalb liegt.
Im Grunde genommen, möchte man nicht alle Straßen innerhalb der Gemeindegrenzen haben, sondern alle Innerorts-Straßen. Diese Information wird in den OSM-Daten allerdings nicht erfasst. Es gibt lediglich die Ortseingangsschilder, anhand derer man den Innerorts-Bereich erraten könnte, wenn denn alle gemappt wären. Aber auch dann gibt es zahlreiche Straßen, sogenannte Schleichwege, die aus den Gemeinden zwar herausführen, aber kein Ortseingangsschild aufweisen.
Um dieses Problem zu umgehen, musste ich selber Hand anlegen und den Innerorts-Bereich mit Heuristiken festlegen. Dafür dienen zum einen alle Straßen die als residential, living_street oder pedestrian getaggt sind, sowie die oben aufgeführten Landschaftsbereiche und alle Ortseingangsschilder.
Um alle Punkte, die sich aus diesen Punkten, Wegen und Gebieten ergeben, wurde nun ein Umschließungspolygon gelegt. Dafür wurde um jeden Punkt zuerst ein Quadrat mit Seitenlänge 500m gelegt – dieser Wert hat sich bei einigen Testläufen als am Brauchbarsten erwiesen. Nun wird außerhalb dieser Quadrate entlang gegangen, und gleichzeitig immer von jedem zugehörigen Punkt zum nächsten gesprungen. Letzteres liefert das Umgebungspolygon des Innenstadtbereichs.
© OpenStreetMap-Mitwirkende, Bernhard Seckinger (ODbL)
Im nächsten Schritt werden die ganzen Wege-Informationen noch ein letztes Mal reduziert, diesmal auf den Innenstadtbereich. Dafür wird erneut die Routine zum Abschneiden der Wege an den Grenzen verwendet, sodass alle Wege bis zum Ende des Innenstadtbereichs intakt bleiben und außerhalb keine mehr vorliegen.
© OpenStreetMap-Mitwirkende, Bernhard Seckinger (ODbL)
In einem letzten Schritt wird nun für jede Straße bestimmt, ob diese relevant ist und was die Maximalgeschwindigkeit der Straße ist.
Relevant ist eine Straße dann, wenn diese zum öffentlichen
Straßennetz der Stadt gehört. Also access=privat fällt weg,
genauso wie alle Straßen, die nicht residential, living_street,
primary, secondary, tertiary, unclassified, primary_link,
secondary_link, tertiary_link oder
pedestrian sind.
Für diese verbleibenden Straßen wird nun die Maximalgeschwindigkeit
berechnet. Diese wird im Tag maxspeed angegeben. Allerdings
kann maxspeed auch ein paar nichtnummerische Werte annehmen,
die umgerechnet werden müssen. Auch kann der Tag ganz fehlen.
Die üblichsten Werte sind: walk, was als 6 km/h
gewertet wurde, none, was bedeutet, dass es keine
Maximalgeschwindigkeit gibt, wie in der Regel auf Autobahnen. Hier
wurde 400 km/h gewählt, was in etwa den schnellsten erhältlichen
Autos mit Straßenzulassung entspricht. Dann gibt es noch ein paar
de:...-Tags, die ebenfalls entsprechend umgerechnet wurden.
Falls die Straße ein verkehrsberuhigter Bereich ist
(highway=living_street) bin ich bei Werten von 4 km/h
bis 8 km/h davon ausgegangen, dass diese Werte nicht explizit
vorgegeben werden, sondern die Mapper eine andere Vorstellung von
Schrittgeschwindigkeit haben. Dies habe ich demnach auf 6 km/h
angepasst.
Zuletzt wurde die Geschwindigkeit auf 0 km/h gesetzt, falls
auf der Straße Autos gar nicht fahren dürfen (motorcar=no
etc.).
Damit ist es leider nicht getan. Denn es gibt auch Straßen, die je
nach Tageszeit ein unterschiedliches Geschwindigkeitslimit aufweisen.
Diese werden über maxspeed:conditional angegeben. Der
Ausdruck wurde ebenfalls ausgewertet und anteilig auf die Straße
verteilt. Wenn also auf einer 300m langen Straße 8 Stunden lang
30 km/h gilt und 16 Stunden lang 50 km/h. So wurde dies
so gehandhabt, als wären 200m der Straße mit 50 km/h und die
anderen 100m mit 30 km/h begrenzt.
Gelegentlich unterscheiden sich auch die Maximalgeschwindigkeiten
in unterschiedliche Richtungen der Straße. Auch das wurde
berücksichtigt, ebenfalls, indem die Straße entsprechend aufgeteilt
wurde. (Und ja, auch da kann conditional geben und auch
das wurde berücksichtigt.)
Tja, und jetzt muss man das alles nur noch, mit der Länge der Straßen multipliziert, aufsummieren und kann den Speed-Index für die Gemeinde ausgeben.
Jetzt hat man zu jeder Gemeinde drei Dateien: Einmal die Landkarte als Postscript-Datei, mit deren Hilfe man fehlerhaft gemappte Straßen erkennen kann. Dann eine Datei mit dem Innerorts-Polygon und zuletzt die Datei mit dem Speed-Index. Diese enthält zudem noch die Gesamtlänge des Straßennetzes der Gemeinde und zu jeder in der Gemeinde vorkommenden Geschwindigkeit die Länge aller entsprechender Straßenteile.
Ein weiteres selbstgeschriebenes Programm berechnet jetzt aus den Innerorts-Polygonen die Innerorts-Fläche jeder Gemeinde und speichert diese Information in einer eigenen Datei ab.
Um den Speed-Index optisch zu veranschaulichen werden als nächstes zahlreiche Übersichtskarten erstellt:
