English version below.

tl;dr: Probier doch mal die Overpassabfrage für Straßen mit veralteten Parkraumdaten in deiner Gegend aus oder für Straßen gänzlich ohne Parkrauminformationen, um zu sehen, ob es Handlungsbedarf gibt :)

Try the overpass queries for streets with deprecated parking data in your area or for streets without any parking information at all to see if there is a need for action :)

---

Das Tagging von Parkplätzen entlang von Straßen hat vor kurzem ein großes Update erfahren: Das vorherige parking:lane-Schema wurde mit bestehenden OSM-Konventionen harmonisiert und durch ein einfacher und flexibler anwendbares Street-Parking-Taggingschema abgelöst. Existierende Daten nach dem alten Schema müssen nun also geprüft und in die neue Form überführt werden.

Für das Verständnis des neuen Parkraumschemas hilft dieser Schnelleinstieg. Aber auch, wer sich nicht tiefer mit diesem komplexen Schema beschäftigen möchte, kann dabei helfen, die Daten zu vervollständigen und zu aktualisieren. Dafür gibt es helfende Werkzeuge, in deren Benutzung ich hier einführen möchte.

Woran erkennt man alte Parkraum-Tags?

Alle Tags an Straßen, die mit parking:lane oder parking:condition anfangen, gehören zum alten Schema und sollten aktualisiert werden. Diese Overpass-Abfrage listet dir alle Straßen, die das alte Schema verwenden (oben links auf den grünen Knopf Ausführen klicken). Bleibt die Abfrage leer, sind entweder noch keine Parkraumdaten erfasst (siehe unten) oder sie sind bereits auf dem aktuellen Stand.

Die Tags des neuen Schemas beginnen nur noch mit parking:left|right|both, also ohne die Bestandteile lane und condition. Aktuelle Parkraumdaten lassen sich mit dieser Abfrage finden.

OSM Parking Lane Tag Updater

Das Tagging-Schema für Parken im Straßenraum erscheint den meisten Usern (zu) kompliziert, aber keine Angst: Der OSM Parking Lane Tag Updater hilft dabei, es ohne großes Hintergrundwissen von der alten in die neue Form zu übersetzen und die OSM-Daten auf diese Weise “halbautomatisch” zu aktualisieren.

Es ist Absicht, dies nicht weiter zu automatisieren, denn einige Daten sind schon viele Jahre alt und können sich in der Zwischenzeit geändert haben. Während des Aktualisierens sollte das im Abgleich z.B. mit Luftbildern auffallen und kann direkt korrigiert werden. Außerdem können die alten Parkraumdaten Fehler oder komplizierte, nicht dokumentierte, teils phantasievolle Tags enthalten, bei denen man im Einzelfall entscheiden muss, wie damit verfahren werden soll. Der Tag-Updater gibt Hinweise aus, wenn er auf solche Tags stößt und hilft beim Umgang damit.

Den Tag Updater verwenden

Nach Start des Online-Tools erscheinen zunächst einige Hinweise, die mit Klick auf “About this tool” ausgeblendet werden können, um die Oberfläche übersichtlicher zu halten. Anschließend könnt ihr auswählen, ob ihr die Daten direkt über die OSM-ID eines Straßensegments einladen wollt (Option 1) oder per Copy and Paste hinein- und herauskopieren wollt (Option 2). Die folgende Kurzanleitung geht auf Option 2 ein.

Wählt ihr Option 2, könnt ihr alte Tags links in das Feld einfügen, mit Klick auf Update übersetzen (Shortcut: Alt + Enter) und aus dem rechten Feld wieder herauskopieren. Mit etwas Übung lassen sich auf diese Weise viele Daten in kurzer Zeit aktualisieren:

• Ein möglicher Weg, dies effektiv zu tun, ist, alle alten Tags gemeinsam im OSM-Editor auszuwählen (mit alphabetischer Reihenfolge und dem gemeinsamen Prefix parking: sollte dies leicht möglich sein) und direkt auszuschneiden bzw. zu kopieren und zu löschen, um sie später nicht mit den neuen Tags zu vermischen. Dann in den Updater einfügen, übersetzen und zurückkopieren.
• Ein anderer möglicher Weg ist es, aus dem OSM-Editor einfach alle Tags – auch die, die nichts mit Parken zu tun haben – auszuschneiden und ins Tool einzufügen und nach dem Übersetzen unter dem Ausgabefeld die Option Copy All Tags zu klicken. Dann werden auch alle Tags wieder zurückkopiert, nun allerdings mit ausgetauschten aktualisierten parking-Tags.

Achtet stets darauf, das Ergebnis kurz mit einem Luftbild oder im Zweifelsfall anderen Quellen wie Straßenfotos (falls vorhanden, insbesondere Mapillary oder KartaView) abzugleichen, um es auf Aktualität und Fehler zu prüfen. Ein sehr gutes grafisches Feedback im Editor gibt außerdem der Parkraum-Style in JOSM (siehe unten).

Review-Funktion des Tag Updaters bei fehlenden oder unverständlichen Tags

Der Tag Updater basiert auf einer Übersetzungsliste mit vorgegebenen Werten. Enthalten die eingefügten OSM-Daten Fehler oder unbekannte Attribute, kann der Updater sie nicht übersetzen und gibt Warnhinweise aus. In diesem “Review new tags”-Bereich unterhalb der Ein- und Ausgabefelder könnt ihr die ausgegebenen Tags prüfen und ggf. überarbeiten oder vorgeschlagene Werte übernehmen. Durch die Umstellung des Tagging-Schemas kann es außerdem Situationen geben, in denen nach Möglichkeit weitere Tags manuell ergänzt werden sollten, um die Angaben zu vervollständigen. Die häufigsten Hinweise und der Umgang damit sind im OSM-Wiki erläutert.

Wer mit einem der Hinweise im Updater nicht weiterkommt oder sonst irgendwelche Fragen oder Probleme mit dem Tagging hat, kann mich gern anschreiben und ich helfe gern bei der “Übersetzung”!

Fehlende Parkraumdaten ergänzen

Vielerorts fehlen Parkraumdaten in OSM sogar noch gänzlich. Als interessantes und den Straßenraum fast aller Städte prägendes Attribut rückt es aber mehr und mehr in den Fokus einiger urbaner Mapper (diese Overpass-Abfrage zeigt aller Straßenabschnitte, an denen Parkstreifenattribute weder nach dem neuen noch dem alten Schema erfasst sind).

Die wohl einfachste Möglichkeit zur Erhebung von Parkraumdaten ist das StreetComplete Parking Overlay. Dafür in der Android-OSM-App StreetComplete über das Einstellungsmenü oben rechts und “Overlays” die Option “Parkstreifen” auswählen. Straßen werden nun entsprechend vorhandener Parkraumdaten eingefärbt. An rot gefärbten Straßen fehlen noch Parkraumattribute. Um diese zu ergänzen, einfach auf das Straßensegment klicken und die passenden Daten für die linke und rechte Straßenseite auswählen. Ändern sich die Position oder Ausrichtung der parkenden Fahrzeuge entlang des ausgewählten Straßensegments, kann die Straße über das Menü unten links (drei Punkte) an der passenden Stelle aufgespalten werden.

Natürlich lässt sich Parkraum auch mit den anderen OSM-Editoren mappen. Dafür wird dann aber ein Blick in die Dokumentation zum Kartieren von Parkplätzen im Straßenraum nötig sein. Ein hilfreiches Tool ist auch der Zlant Parking Lanes Viewer und Editor, mit dem Parkstreifeninformationen angezeigt und bearbeitet werden können (für letzteres unten rechts auf Editor klicken). Auf Grundlage dahinterliegender Luftbilder lässt sich so auch auf effektive Weise und aus der Ferne Parkraum kartieren.

Tipps für JOSM-User

Um Parkstreifen-Taggings korrekt anzuwenden, ist es sehr hilfreich, ein visuelles Feedback im OSM-Editor zu bekommen. Für den OSM-Editor JOSM gibt es dafür einen Map Style, der ganz einfach über die Einstellungen, den Reiter “Kartenstile” und dort einer Suche nach “Parkstreifen” aktiviert werden kann. Der Stil visualisiert sowohl physische Parkraumtags (Position und Ausrichtung der Fahrzeuge) als auch Parkbeschränkungen und markiert Straßensegmente mit veralteten oder widersprüchlichen Parkraumtags. Auch eine Vorlage zum Mappen von Parkstreifen lässt sich unter gleichem Namen finden.

In JOSM lassen sich außerdem Daten mit Overpass herunterladen, sodass sie gezielter und übersichtlicher bearbeitet werden können. Dafür muss der “Expertenmodus” eingeschaltet sein, wofür im Einstellungsfenster unten links ein Häkchen gesetzt werden muss. Nun im Dialog zum Herunterladen von Daten oben “Von Overpass-API herunterladen” auswählen, den Inhalt der oben verlinkten Abfrage einfügen und Daten herunterladen. Auf diese Weise lassen sich alte Daten sehr effizient und zielgerichtet aktualisieren.

Und wofür ist das eigentlich alles nützlich?

Parkraum ist ein prägendes Merkmal vieler Städte und dort fast überall gegenwärtig, aber dennoch bisher nur bei wenigen Mappern im Fokus. Dabei können OSM-Daten in diesem Bereich ganz nebenbei eine wertvolle Datenlücke in der Stadtplanung schließen – denn niemand anderes (weder Kommunen, noch Behörden oder Unternehmen) verfügt über strukturierte Daten zum Parken auf den Straßen. Wenn überhaupt, gibt es Erhebungen für einzelne Stadtteile oder Parkzonen, aber diese sind fast nie als offene Daten verfügbar und nicht miteinander vergleichbar.

Das OSM Parkraumprojekt aus Berlin hat demonstriert, dass man mit den OSM-Daten vielfältige Analysen anstellen kann, bis hin zur Interpolation von Stellplatzzahlen für ganze Städte (Work in Progress), der detaillierten kartographischen Darstellung des Parkraums und Berechnungen zur Parkraumdichte. Der Autor dieses Posts ist Teil der Projektgruppe, die zwischen September 2022 und Februar 2023 durch den Prototype Fund gefödert wurde, um die Analysemethode für Parkraumdaten aus OSM weiterzuentwickeln.

OSM bietet in diesem Bereich also ein großes Potential und ein Alleinstellungsmerkmal, was bisher kaum ausgeschöpft wird. Ihr alle könnt dazu beitragen, das zu ändern! In diesem Sinne: Viel Spaß beim Parkraum mappen :)

---

---

EN

---

The tagging for parking spaces along streets recently got a major update: The previous parking:lane scheme has been harmonised with existing OSM conventions and replaced by a street parking tagging scheme that is easier and more flexible to use. Therefore, existing data based on the former scheme needs to be reviewed and converted to the new scheme.

This quick guide helps to understand the new parking scheme. But even if you don’t want to deal with this complex scheme in depth, you can help to add and update the data. There are some tools to help with this, and I would like to introduce you to their use.

How can you identify old parking tags?

All tags on streets that start with parking:lane or parking:condition are old, deprecated tags and should be updated. This overpass query shows all streets that are tagged with the old scheme (click on the green button in the upper left corner to run the query). If the query remains empty, either no parking data has been recorded yet (see below) or they are already up to date.

The tags of the new scheme just start with parking:left|right|both, i.e. without the lane and condition infixes. Up-to-date street parking data can be found with this query.

OSM Parking Lane Tag Updater

The tagging scheme for street parking seems (too) complicated for most users, but don’t worry: The OSM Parking Lane Tag Updater helps to translate it from the old to the new syntax without much background knowledge thus updating the OSM data “semi-automatically”.

It is intended to not fully automate this, because lot of the data is already many years old and may have changed in the meantime. During the updating process, this should be noticed by comparing it e.g. with aerial photos and can then be corrected. Moreover, the old parking lane data may contain tagging mistakes or complicated, undocumented, sometimes fancy tags, for which you have to decide on a case-by-case basis how to deal with them. The tag updater issues notices when it encounters such tags and helps reviewing them.

Using the Tag Updater

After starting the online tool, you will first see some notes that can be hidden by clicking on “About this tool” to keep the interface clear. You can choose whether you want to load the data directly via the OSM ID of a road segment (option 1) or copy and paste it in and out (option 2). The following brief instructions focus on the second option.

If you choose the second option, you can paste old tags into the field on the left, translate them by clicking “Update” (shortcut: Alt + Enter) and copy them from the field on the right. With some practice, you can update a lot of data in a short time this way:

• One possible way to do this effectively is to select all old tags in the OSM editor (with alphabetical order and the shared prefix parking: this should be easy) and cut or copy and delete them directly to not mix them with the new tags later. Then paste into the updater, translate and copy back.
• Another possible way is to simply cut and paste all tags from the OSM editor - even those that have nothing to do with parking - and click the Copy All Tags option below the output field after translating. Then all tags will be copied back again, but now with the replaced, updated parking tags.

Always make sure to briefly verify the result with an aerial photo or, in case of doubt, other sources such as street photos (if available, esp. Mapillary or KartaView) to check for up-to-dateness and mistakes. A very good visual feedback within the editor is also provided by the parking lanes style in JOSM (see below).

Review feature of the tag updater for missing or ambiguous tags

The tag updater is based on a translation list with predefined values. If the pasted OSM tags contain mistakes or unknown attributes, the updater cannot translate them and provides warnings. In this “Review new tags” section below the input and output fields, you can check the output tags and revise them if necessary or accept suggested values. Due to the changes in the tagging scheme, there may also be situations where additional tags should be added manually, if possible, to complete the information. The most common warning notes and how to deal with them are explained in the OSM Wiki.

If you are stuck with one of the warning notes in the updater or have any other questions or problems with the tagging, feel free to contact me and I will be happy to help with the translation or issue!

Complete missing street parking data

In many places, street parking data is still completely missing in OSM. However, it is becoming more and more the focus of some urban mappers as an interesting attribute that dominates the streetscape of almost all cities (this overpass query shows all streets where street parking attributes are neither mapped according to the new nor the old scheme).

Probably the easiest way to collect street parking data is the StreetComplete Parking Overlay. To do this, in the Android OSM app StreetComplete, select the setting menu at the top right, choose “Overlays” and select “Street parking”. Streets are now coloured according to existing parking data. Streets coloured in red are still missing parking attributes. To add these, simply click on the street segment and select the appropriate values for the left and right sides of the street. If the position or orientation of the parked vehicles along the selected street segment changes, the street can be split using the menu at the bottom left (three dots).

Of course, street parking can also be mapped with the other OSM editors. However, this may require a look at the documentation on mapping street parking. Another helpful tool is the Zlant Parking Lanes Viewer and Editor, which can be used to display and edit parking lane information (for the latter, activate the Editor at the bottom right). Using aerial photographs in the background, street parking can be mapped effectively and remotely.

Tips for JOSM users

To use street parking tagging correctly, it is very helpful to get visual feedback in the OSM editor. For the OSM editor JOSM there is a map style for this purpose, which can easily be activated via the preferences, the tab “Map Paint Styles” and there a search for “Parking lanes”. This style visualises physical parking tags (position and orientation of vehicles) as well as parking restrictions and marks street segments with deprecated or conflicting parking tags. A preset for mapping parking lanes can also be found under the same name.

In JOSM, it is also possible to download data via Overpass queries to allow more targeted editing of the data. For this, the “expert mode” must be activated, for which a tick must be set in the preferences menu at the bottom left. Now, in the dialogue for downloading data, select “Download from Overpass API” at the top, paste the content of the query linked above and “Download data”. In this way, old data can be updated very efficiently and in a targeted manner.

And what is all this actually useful for?

Street parking is a dominant characteristic of many cities and is present almost everywhere, but isn’t focused on by many mappers yet. But OSM data can close a valuable data gap in urban planning here - because no-one else (neither municipalities, nor administrative authorities or companies) has any structured data for street parking. If at all, there are surveys for individual districts or parking zones, but these are almost never available as open data and are not comparable with each other.

The OSM Parking Project from Berlin has proven that OSM data can be used for a wide range of analyses, including the interpolation of parking space counts for entire cities (work in progress), the detailed mapping of parking space and calculations of parking densities. The author of this post is part of the project group funded by the German Open Source Prototype Fund between September 2022 and February 2023 to further develop the analysis method for parking data from OSM.

OSM therefore offers great potential and a unique feature in this field, which has hardly been exploited so far. You all can contribute to change this! With this in mind: Have fun mapping street parking :)

This post is also available in English.

OSM-Daten bieten das Potential, präzise Parkplatzzählungen und Parkraumanalysen durchzuführen und damit wertvolles Wissen für Diskussionen rund um die Verkehrswende, Stadtentwicklung und Mobilität bereitzustellen. Vielerorts gibt es nämlich noch gar kein systematisches Wissen, wo es wie viele Parkplätze am Straßenrand (oder auch darüber hinaus) gibt. In aufwendigen Studien müssen diese Daten bei Bedarf erfasst werden – und meist sind diese Daten anschließend nicht für die Öffentlichkeit zugänglich. Im Gegensatz dazu stellt OSM eine optimale Umgebung dar, in der solche Daten frei zugänglich erfasst und analysierbar gemacht werden können.

Am Beispiel des Berliner Stadtteils Neukölln haben wir demonstriert, wie urbane Parkplätze systematisch auf OSM-Basis kartiert und mit Geoinformationssystemen (hier: QGIS) und unter Einbezug weiterer offener Daten hochaufgelöst ausgewertet werden können. Dieser Blogpost soll euch einen Überblick über die Methodik geben und ein paar wichtige Ergebnisse und Erfahrungen für die OSM-Praxis mit euch teilen.

Einen ausführlichen Blick auf die Ergebnisse und Daten könnt ihr in der Neuköllner Parkraumkarte werfen, in der die Parkplatzinformationen visualisiert werden, die zugrunde liegenden Daten zum Download bereit stehen und bei Bedarf ausführlichere Infos zur Herangehensweise und Methodik zu finden sind.

Abbildung 1: Ausschnitt der Parkraumkarte, die auf verschiedenen Zoomstufen verschiedene Ergebnisse visualisiert: Von einzelnen Stellplätzen über straßenzugsweise Stellplatzzahlen bis hin zur Stellplatzdichte und dem Flächenverbrauch durch geparkte Fahrzeuge.

Hinweis: Die hier vorgestellte Parkraumanalyse geht auf erste Experimente im vergangenen Jahr zurück, über die hier damals bereits berichtet wurde. Das Verfahren ist inzwischen weiter automatisiert worden, sodass es leichter auf andere Orte übertragen werden kann. Da OSM-Daten zum Parken am Fahrbahnrand aber bisher an vielen Orten noch nicht zu den „Standardinformationen“ gehören und oft nur rudimentär oder gar nicht erfasst sind, ist es dafür wohl meistens notwendig, diese Daten selbst zu kartieren bzw. zu vervollständigen.

Methodik

Für die hier vorgestellte Parkraumanalyse sind im letzten Jahr zunächst systematisch alle straßenbegleitenden Parkplätze (Parkstreifen am Straßenrand) im Untersuchungsgebiet in OSM kartiert worden – ebenso wie andere relevante Objekte wie Grundstückseinfahrten und Informationen zu Gehwegübergängen (da dort nicht geparkt werden darf). Das zur Erfassung straßenbegleitenden Parkens etablierte OSM-Schema ist das parking:lane-Schema: Auch wenn dieses Schema seine Macken hat, ihm eine Weiterentwicklung an manchen Stellen gut tun würde und es nicht alternativlos ist (siehe letzter Abschnitt), eignet es sich grundsätzlich dennoch sehr gut für Auswertungen wie diese und liefert relativ präzise Ergebnisse. Der Ansatz dieses Schemas ist es, einem Straßensegment jeweils Informationen zum Parken am linken und rechten Fahrbahnrand zuzuordnen. Dazu gehören vor allem die Art des Parkens (entweder Park- oder Halteverbote oder die Anordnung/Ausrichtung der geparkten Fahrzeuge, insbesondere Längs-, Schräg- und Querparken), die Position des Parkens (die Fahrzeuge können auf der Fahrbahn, in einer Parkbucht, auf dem Gehweg, halb auf dem Gehweg oder auf dem Seitenstreifen stehen) sowie Bedingungen und Einschränkungen (Stellplätze können insbesondere für bestimmte Nutzergruppen reserviert, zeitlich begrenzt nutzbar oder gebührenpflichtig sein).

Die Straßensegmente liegen geometrisch als Linienobjekte vor, die geteilt werden können, wenn sich Attribute im Straßenverlauf ändern. Besteht entlang eines Teilabschnitts einer Straße beispielsweise ein Parkverbot, kann dieses direkt über ein eigenes Straßensegment differenziert werden. Kurze und kleinteilige Änderungen (wie Halteverbote vor Einfahrten oder an Gehwegübergängen) müssen – und sollen – nicht gesondert segmentiert werden, da ansonsten eine unübersichtliche Anzahl von Linienstücken entstehen würde und diese Informationen im späteren Verlauf der Auswertung ohnehin aus den entsprechenden OSM-Datenobjekten abgeleitet werden können.

Die Verarbeitung der OSM-Daten erfolgte unterstützt durch Python-Skripte in QGIS (ein Skript zur Erzeugung von Parkstreifen aus OSM-Daten ist hier zu finden) und orientierte sich etwa an dieser Abfolge:

• Entsprechend der Fahrbahnbreite, die entweder direkt am Straßenobjekt hinterlegt ist oder aus seinen Attributen abgeschätzt werden kann, können die räumlichen Verläufe der jeweils linken und rechten Parkstreifen (durch versetzen) mit ihren jeweils spezifischen Eigenschaften abgeleitet werden.

• Bereiche, an denen laut Straßenverkehrsordnung ein Park- bzw. Halteverbot besteht oder die sich entsprechend ihrer baulichen Anlage nicht zum Parken eignen, und die nicht bereits durch beschilderte Park- und Halteverbote mit dem parking:lane-Schema abgebildet sind, können anschließend aus den Daten ausgeschlossen werden, in dem dort Abschnitte mit einer vorbestimmten Länge abgetrennt werden. Die Ausdehnung dieser Bereiche ergibt sich aus juristischen Richtwerten oder ihrer typischen baulichen Anlage (z.B. kein Parken 5 Meter vor Kreuzungen oder 15 Meter vor oder hinter einer Bushaltestelle, kein Parken vor Einfahrten, an Fußgängerüberwegen oder im Bereich von Gehwegvorstreckungen etc.).

• Objekte, die das Parken im Parkstreifenbereich verhindern, wurden vor der Auswertung systematisch kartiert und in einem separaten Arbeitsschritt mit Sicherheitsabständen von den Parkbereichen abgezogen (z.B. Straßenbäume, Laternen, Poller, Bordsteinstrukturen, Fahrradständer und insbesondere beim Parken auf Gehwegen auch Straßenschilder, Straßenmöbel und Gehweg-Einbauten wie Verteilerkästen).

• Das Ergebnis wurde anschließend für die vorliegende Auswertung auf Fehler überprüft und teils aufwendig manuell nachbearbeitet, um die Präzision der Ergebnisse zu erhöhen (siehe Parkraumkarte). Die allgemeine Aussagekraft der Ergebnisse wäre (bei ausreichend guter Kartierung der wesentlichen Objekte) aber auch ohne eine solche Nachbearbeitung gegeben und ist bei Übertragung auf andere Orte daher eher verzichtbar.

• Abschließend wurden Stellplatzkapazitäten für zusammenhängende Parkstreifensegmente berechnet (Quotient aus der Länge eines Segments und dem Abstand der dort geparkten Fahrzeuge, je nach Ausrichtung des Parkens).

Abbildung 2: Generierung von Parkstreifensegmenten (blau) und baulichen Park-/Halteverbotszonen (Kreise). Weitere Objektgeometrien, die das Parken verhindern, können an die Parkstreifen gesnappt und von diesen abgezogen werden (hier Fahrradständer im Fahrbahnbereich, gestreifte Flächen). Kleiner Ausschnitt des Untersuchungsgebiets und provisorische Visualisierung während des Berechnungsprozesses.

Die hier vorgestellte Parkraumanalyse berücksichtigt darüber hinaus auch Informationen zu (meist privaten) Stellplätzen abseits des Straßenraums, die ebenso systematisch erhoben wurden. Dazu zählen allgemeine, meist ebenerdige Park- und Stellplätze, Tiefgaragen, Garagen und Carports sowie Parkhäuser. Für diese Objekte kann häufiger eine genaue Stellplatzzahl angegeben werden, da diese oft markiert und abzählbar sind. Aus ihrer Grundfläche (und, bei mehrstöckigen Objekten, ggf. unter Berücksichtigung ihrer horizontalen Ausdehnung) kann die Stellplatzkapazität aber auch hier geometrisch abgeschätzt werden.

Da viele dieser Stellplätze nicht oder nur schwer aus dem öffentlichen Raum zugänglich oder erkennbar sind, wurden für die Erhebung und Vervollständigung dieser Flächen einige externe Geodatensätze einbezogen, die hier in Berlin zum Glück zahlreich in guter Qualität und frei verwendbar vorhanden sind: So wurden Luftbilder systematisch auf Stellplätze in Hinterhöfen etc. geprüft und Tiefgaragenflächen oder Infos zu Garagengebäuden konnten aus dem Amtlichen Liegenschaftskatasterinformationssystem (ALKIS) abgeleitet werden. Nach Plausibilitätsprüfung fanden diese Daten Eingang in die verwendeten Rohdatensätze – insbesondere bei den Tiefgaragen wurden in OSM aber nur die vor Ort überprüfbaren Merkmale hinterlegt, also die Ein- und Ausfahrten, aber nicht die Grundflächen.

Die Stellplatzdaten sind damit nicht nur geometrisch erfasst, sondern können auch zusätzliche Attribute enthalten wie zu Beschränkungen der Nutzung oder Zugänglichkeit (öffentlich/privat/Kunden etc., Gebühren, zeitliche Beschränkungen) und können auf dieser Grundlage gezielt ausgewertet werden.

Bei einer Größe des Untersuchungsgebiets von über 20 km², einer Länge des dortigen Straßennetzes von etwa 170 km, insgesamt 2.200 in OSM gemappten Grundstückseinfahrten und über 2.000 Parkplatzflächen klingt dies zunächst nach erheblichem Arbeitsaufwand. Tatsächlich war es aber innerhalb weniger Monate ohne weiteres möglich, diese Informationen auch als Einzelperson zu erfassen bzw. zu prüfen und zu vervollständigen – umso schneller geht es natürlich, wenn mehrere Mapper arbeitsteilig vorgehen.

Zentrale Zahlen und Ergebnisse

Viele Ergebnisse und Zahlen des Projekts sind in der Neuköllner Parkraumkarte dargestellt und können kaum übersichtlich in Worte gefasst werden. Der Fokus dieses Projekts lag auch eher in der Entwicklung einer Methode und der Bereitstellung der Daten als in der Interpretation von Ergebnissen, daher soll hier nur kurz darauf eingegangen werden. Mehr Daten und Zahlen sind außerdem im Methodenbericht und auf der Datenseite zum Projekt zu finden.

Für den Ortsteil Neukölln, einem großstädtischen Wohnquartier mit etwa 165.000 Einwohnenden, ergaben sich insgesamt über 27.300 Kfz-Stellplätze im öffentlichen Straßenraum. Dazu kommen noch einmal etwa 12.200 Stellplätze abseits des Straßenraums, die sich dauerhaft bzw. über Nacht zum Parken für Anwohnende eignen (sowie 8.100 nicht zum dauerhaften Parken geeignete Stellplätze wie Mitarbeiter- und Kundenparkplätze und knapp 430 ungenutzte Stellplätze, beispielsweise in leerstehenden Tiefgaragen).

Werden die beiden Gewerbegebiete am Rande des untersuchten Stadtteils außen vor gelassen – also nur die Wohnquartiere berücksichtigt – stehen zusammen 35.447 Stellplätze zum dauerhaften Parken zur Verfügung, denen 33.513 angemeldete Kraftfahrzeuge im gleichen Gebiet gegenüber stehen. Theoretisch stehen für jedes Kraftfahrzeug also 1,08 Stellplätze zur Verfügung.

Die Parkraumanalyse umfasste auch eine kleinräumige Berechnung von Stellplatzdichten, wofür ein eigenes Bevölkerungs- und Kfz-Datenmodell auf Grundlage von externen geografischen und demografischen Daten sowie Kfz-Meldedaten entwickelt wurde (Details dazu können im Methodenbericht nachgelesen werden). Damit lassen sich die verfügbaren Stellplätze in einem kleineren Gebiet oder im Umkreis um einen Wohnort mit den tatsächlich dort zugelassenen Kfz ins Verhältnis setzen. Für die Parkraumanalyse wurden diese Stellplatzdichten für eine Distanz von 350 Metern um einen Wohnort – bezogen auf ein engmaschiges Gitternetz – berechnet (350 Meter entsprechen dabei der Nahdistanz um einen Wohnort, also einer Entfernung, die innerhalb von 3 bis 4 Minuten – bei 7 bzw. 5 km/h – fußläufig erreichbar ist). Im Durchschnitt (Median) ergibt sich dabei für die Neuköllner Wohnquartiere eine Anzahl von 835 Stellplätzen (604 davon im öffentlichen Straßenraum) und eine Zahl von 759 zugelassenen Kraftfahrzeugen.

Abbildung 3: Parkraumdichte in den Wohnquartieren des Untersuchungsgebiets: Verhältnis zwischen verfügbaren Stellplätzen und angemeldeten Kraftfahrzeugen im Umkreis von 350 Metern (3-4 Minuten Fußweg) um einen Ort.

Im Zuge der Verkehrswende und den Debatten über lebenswertere Städte stehen die am Straßenrand geparkten Fahrzeuge zunehmend im Fokus, da sie sich vor allem durch einen dauerhaften, vergleichsweise hohen Flächenverbrauch auszeichnen. Allein für die Neuköllner Wohnquartiere kann dieser Flächenverbrauch durch geparkte Fahrzeuge im öffentlichen Straßenraum auf eine Fläche von insgesamt 327.000 Quadratmetern beziffert werden, was 19 Prozent des öffentlichen Verkehrsraumes und 4,4 Prozent der Gesamtfläche des Gebiets entspricht. Parkplätze und Stellflächen abseits des Straßenraumes beanspruchen darüber hinaus noch einmal zusätzlich 171.000 Quadratmeter (2,3 Prozent der Gesamtfläche des Gebiets). In die obligatorischen Fußballfelder umgerechnet bedeutet dies, dass 70 Fußballfelder allein in den Wohnquartieren Neuköllns für stehende Fahrzeuge in Anspruch genommen werden, 46 davon im öffentlichen Straßenraum.

Bewertung von Unsicherheitsfaktoren des Datenmodells

Die vorgestellte Parkraumanalyse basiert auf einem interpolativen Datenmodell, also aus geografischen Daten und empirischen Annahmen abgeleiteten Aussagen und Vereinfachungen, um die (komplexe) Realität modellhaft abzubilden und „berechenbar“ zu machen. Viele der zu Grunde liegenden Annahmen und Ergebnisse können in der tatsächlichen Realität überprüft, gezählt oder gemessen werden, andere unterliegen bestimmten Unsicherheiten, die sich kaum oder nur mit erheblichem empirischen Aufwand quantifizieren lassen.

Da das Straßenparken die Parkraumsituation wesentlich prägt, ist sie das Kernstück des Datenmodells. Zwar wurden die automatisiert erzeugten Parkstreifendaten der vorliegenden Parkraumanalyse einer aufwendigen manuellen Nachbearbeitung unterzogen, allerdings wichen die Ergebnisse dieser Nachbearbeitung nur um 0,6 Prozent von den direkt aus OSM erzeugten Rohdaten ab. An anderen Stellen können aber signifikante Fehlerquellen lauern. So wurden die interpolierten Stellplatzzahlen durch Zählung von über 1.500 Fahrzeugen und Parklücken mit der Realität verglichen (ohne Falschparker dabei mitzuzählen). Dabei zeigte sich mit einer Abweichung von unter einem Prozent zwar eine insgesamt sehr hohe Übereinstimmung, allerdings gab es drei Straßenabschnitte mit auffallend hoher Abweichung. In diesen Straßen, in denen jeweils Schräg- oder Querparken angeordnet ist, überschätzte das Datenmodell den Einfluss von Einfahrten und blockierenden Objekten im Parkraum (Bäume, Straßenlaternen). In solchen Fällen kann es sich also lohnen, das Ergebnis mit der Realität zu vergleichen und ggf. nachzujustieren oder schon während der Erfassung die tatsächliche Anzahl von Stellplätzen anzugeben, wenn diese durch Markierungen eindeutig abzählbar sind. Eine Schätzung von nicht markierten oder klar zählbaren Stellplatzkapazitäten sollte man beim Mapping aber eher vermeiden – das kann ein GIS im Zweifelsfall besser und dabei flexibel auf zugrundeliegende Annahmen wie durchschnittlichen Fahrzeuglängen Rücksicht nehmen.

Darüber hinaus gibt es eine Reihe anderer Faktoren, die zu einer Über- oder Unterschätzung der realen Parkraumsituation im Vergleich zum Datenmodell führen können. Für einige der vermutlich wichtigsten Faktoren wurde eine Schätzung angestellt, um ihren Einfluss bei der Interpretation der Daten berücksichtigen zu können (ausführlicher im Methodenbericht). So bildet das Datenmodell eine juristische, StVO-konforme Situation ab; in der Realität ist jedoch häufiges Falschparken zu beobachten – vor allem zu enges Parken an Kreuzungen oder Parken vor Gebäudedurchfahrten (von denen es in Berlin viele gibt, und die häufig nicht beachtet werden). Nimmt man an, dass vor Kreuzungen im Mittel nur ein Abstand von 2,5 statt 5 Metern eingehalten und vor jeder zweiten Einfahrt geparkt wird, erhöht sich die Zahl der „Stellplätze“ beispielsweise bereits um 6 Prozent. Andererseits gibt es in der Realität insbesondere durch Dienst- und Mietwagen wahrscheinlich auch mehr Fahrzeuge als in der Meldestatistik – dabei kann wohl von einer Größenordnung von etwa 5 Prozent mehr Fahrzeugen ausgegangen werden.

Ein weiterer wesentlicher Faktor: Insbesondere die Stellplatzangaben außerhalb des öffentlichen Straßenraums müssen als theoretisch verfügbare Stellplatzpotentiale verstanden werden und nicht als tatsächlich genutzte Kfz-Stellplätze, da ihre tatsächliche Auslastung meist unbekannt bleibt. Vor allem Garagen werden beispielsweise häufig anders genutzt als zum Abstellen eines Kfz (unter der Annahme, dass jede zweite Garage nicht zum Abstellen eines Kfz genutzt wird, reduziert sich das Gesamt-Stellplatzangebot im Datenmodell beispielsweise um 3 Prozent). Auch die Parkhäuser im Untersuchungsgebiet stehen zwar Anwohnerinnen und Anwohnern zur Verfügung und tragen insgesamt fast 4 Prozent der Gesamtstellplatzkapazitäten im Datenmodell bei, faktisch wird dieses Potential jedoch offenbar nicht ausgeschöpft, da oft ein größerer Leerstand beobachtet werden kann.

Erkenntnisse für die OSM-Mapping-Praxis

Die sehr geringen Abweichungen zwischen den interpolierten bzw. aus den OSM-Daten berechneten Stellplatzzahlen und der realen, gezählten Situation sind im vorliegenden Fall vermutlich auf den vergleichsweise hohen Detailgrad der OSM-Daten im Untersuchungsgebiet zurückzuführen. So wurden beispielsweise die Gebäude- und Grundstückseinfahrten systematisch vervollständigt und teils mit Breitenangaben versehen, auch einige Straßen verfügen über exakte Breitenangaben (OSM-Key: width:carriageway – obwohl sich die Breite einer Straße im Allgemeinen ausreichend genau aus ihren Attributen wie Straßentyp, Einbahnstraße oder Anzahl der Fahrspuren ableiten lässt). Vor allem aber wurden die Parkstreifeninformationen relativ genau erfasst: Ausgeschilderte Park- und Halteverbote wurden dabei ebenso berücksichtigt wie andere Bedingungen zum Parken von „signifikanter“ Länge, auch wenn diese z.B. nur ein 15 Meter langes Straßensegment betreffen. Einige Mapper erschaudern vermutlich angesichts so viel Micro-Mappings – solch präzise Daten können aber nicht nur für ein Projekt wie dieses äußerst wertvoll sein.

In den meisten Fällen ist es aber gar nicht notwendig, Straßen in viele kleinteilige Segmente zu zerstückeln, da sich die relevanten Informationen aus anderen Objekten im Raum ableiten lassen, wenn diese gut erfasst sind: So ist klar, dass auf einem Zebrastreifen, vor einer Bushaltestelle oder im Bereich einer Fußgängerampel nicht geparkt werden darf. Für einige speziellere Situationen haben sich hier in der lokalen Mapping-Community auch neue Tags etabliert, die sich als sehr nützlich für diese Auswertung herausgestellt haben: Insbesondere Details an Gehwegübergängen im Kreuzungsbereich wie Gehwegvorstreckungen oder randseitige Straßenmarkierungen für Fußgänger sind hier vielerorts kartiert (Diskussionen zu solchen Taggings finden hier vor Ort vor allem in der Berliner Verkehrswendegruppe statt und münden z.B. in Empfehlungen wie diese zum detaillierten Mappen von Gehwegübergängen). Auch das neue Schema zum genaueren Kartieren von Parkbuchten (parking=street_side) ist teils vor dem Hintergrund dieser Parkraumanalyse entstanden.

Eine spannende Frage ist natürlich, welchen Einfluss die kartografische Präzision auf das Ergebnis der Parkraumanalyse hat. Im Detail konnte ich das bisher noch nicht ergründen. Bei den ersten Versuchen für solche Parkraumauswertungen vor einem Jahr habe ich aber die Erfahrung gemacht, dass es vor allem bei Schräg- und Querparken (wenn die Fahrzeuge im Winkel zum Fahrbahnverlauf stehen) schnell zu größeren Abweichungen kommen kann, da hier sehr viele Fahrzeuge entlang relativ kurzer Wegstrecken parken. Beginnt das Schrägparken beispielsweise erst 20 Meter hinter einer Kreuzung und wird der Bereich davor nicht mit einer entsprechend abweichenden Parkstreifeninformation erfasst (und ist diese auch sonst nicht aus anderen Objekten ableitbar), summiert sich bereits ein Fehler von mehreren Stellplätzen. Feinteiliges Mappen lohnt sich also insbesondere beim Quer- und Schrägparken.

Die vorliegende Parkraumanalyse zeigt, dass mit einer genauen Kartierung eine äußerst präzise Wiedergabe der Realität erreicht werden kann. Sie ist aber auch an die Grenzen einiger Tagging-Schemata und des „Geschmacks“ einzelner anderer Mapper gestoßen. Alles in allem hat sich OSM aber als perfektes Werkzeug bewiesen, um auch solche speziellen Informationen zu erfassen und analysierbar zu machen. Unglücklich kann manchmal der Umstand erscheinen, dass die Parkstreifeninformationen geometrisch an der Straßenlinie erfasst werden, und nicht dort, wo sie on-the-ground ihren Ursprung haben, nämlich an einer Bordsteinlinie. Zwar gibt es seit ein, zwei Jahren mit CurbLR eine OpenData-Spezifikation zur Erfassung von Parkstreifen an der Bordsteinlinie mit ausführlichen Überlegungen und Tagging-Schema zur Umsetzung in OSM. Dieser Vorschlag hat bisher aber noch keinen Einzug in die tatsächliche Mappingpraxis gehalten. Nach den Erfahrungen, die ich mit der vorliegenden Parkraumauswertung gesammelt habe, hat sich das OSM-parking:lane-Schema aber als ausreichend genau und vermutlich einfacher auszuwertendes Schema erwiesen.

Ich bin gespannt, wie sich der Erfassungsgrad von Parkstreifen in OSM weiter entwickelt. In den letzten beiden Jahren scheint der Gebrauch des parking:lane-Schemas etwas zugenommen zu haben. Ebenso nehmen vor allem in Großstädten die Diskussionen um stehende Fahrzeuge und Flächengerechtigkeit im öffentlichen Straßenraum zu, womit Daten wie die hier vorgestellten eine immer wichtigere Bedeutung in der Stadtentwicklung, Planung und demokratischen Diskussion darum einnehmen werden. OSM hat sich wieder einmal als geeignetes Werkzeug erwiesen, um solche Daten für alle zugänglich zu machen – nun ist es an uns, diese Daten auch zu erfassen.

This post is also available in German / Dieser Post ist auch in deutscher Sprache verfügbar.

OSM parking space data can be a great source of information for the debate around urban development and the transition towards a more sustainable transport system. In many places, there is still no systematic knowledge of where and how much parking is avaliable along the road and beyond. Right now, this data is usually only collected as a part of expensive studies, which are usually not available to the public once they are done. In contrast to this, OSM is an environment in which such data can be freely collected and analysed.

Using the Berlin district of Neukölln as an example, we have demonstrated how urban parking spaces can be systematically mapped using OSM as a basis. We then analysed the collected information at high resolution using geoinformation systems (here: QGIS) and incorporating other open data. This blogpost will give you an overview of the methodology and share some important results and experiences for OSM practice.

You can take a look at the results and data in the Neukölln parking map, where different parking information is visualised, the underlying data is available for download and more detailed information on the approach and methodology can be found (in German).

Figure 1: The same section of the parking map at three different zoom levels, depicting different results each: From individual parking spaces to street-level parking space numbers to parking space density and land consumption by parked vehicles.

Note: The parking space analysis presented here goes back to initial experiments last year. In the meantime, the approach has been automated further, so that it can be transferred to other locations more easily. However, since OSM data on parking lanes is not yet frequently mapped in many places, it is probably necessary to map or complete this data yourself.

Methodology

For the parking space analysis presented here, all parking lanes along the streets in the study area were mapped systematically in OSM last year – as well as other relevant objects such as driveways and details on sidewalk crossings (since parking is not allowed there). The OSM scheme established for recording lane parking is the parking:lane scheme: Even though this scheme has its quirks, would benefit from further development in some places and is not without alternatives (see last section), it is fundamentally well suited for evaluations like this one and provides fairly precise results. The approach of this scheme is to add left and right side parking information to the road segment at this location. This includes, above all, the type of parking (e.g. restricted parking and stopping zones or the arrangement/orientation of the parked vehicles, in particular parallel, diagonal and perpendicular parking), the position of parking (vehicles may be parked on the carriageway, in a street-side parking bay, on the sidewalk, half on the sidewalk or on the shoulder) as well as conditions and restrictions (e.g. parking spaces may be reserved for certain user groups, usable only for a limited period of time or subject to a fee).

The road segments exist geometrically as line objects that can be divided into smaller segments in case attributes change along the course of the road. If, for example, parking is prohibited along a section of a road, this will be recored on a separate road segment. Short and small-scale changes (such as stopping bans in front of driveways or at pavement crossings) do not have to – and should not – be recored as separate segments, as it would create a confusing number of line segments. Also, this information can be derived from the corresponding OSM data objects, as was done in the following evaluation.

The processing of OSM data was carried out via Python scripts in QGIS (a script for generating parking lanes from OSM data can be found here) and followed these steps:

• The spatial layout of left and right parking lanes and their respective specific characteristics can be derived from the lane width by offsetting. The lane width itself is either given directly at the road object or can be estimated from its attributes.

• There are areas where parking or stopping is prohibited according to road traffic regulations and there are areas which are not suitable for parking due to their structural design. These are not always represented by parking and stopping prohibitions with the parking: lane scheme. They can be excluded from the data by separating sections with a predefined length. The extent of these areas results from legal guidelines or their typical structural layout (e.g. no parking 5 metres in front of intersections or 15 metres in front of or behind a bus stop. No parking in front of driveways, at pedestrian crossings or in the area of kerb extensions, etc.).

• Objects that prevent parking in the parking lane area were mapped systematically before the evaluation. Then these objects were subtracted from the parking zones with safety buffers (e.g. street trees, lampposts, bollards, kerb structures, bicycle stands and in the case of sidewalk parking also street signs or street furniture).

• The result was then checked for errors and manually reworked in order to increase the precision of the results (see parking map). However, untouched results would also give a very good picture of the research area and when carrying out this approach in another area such post-processing would therefore be unnecessary (given a good mapping of the essential objects).

• Finally, parking space capacities were calculated for contiguous parking lane segments. Technically it’s the quotient of the length of a segment and the distance of the vehicles parked there, depending on the orientation of the parking.

Figure 2: Generated parking lane segments (blue) and structural no-parking/no-stopping zones (circles). Further object geometries that prevent parking can be snapped onto the parking lanes and subtracted from them (here, bicycle stands on the carriageway, striped areas). Sample section of the study area and provisional visualisation during the calculation process.

The parking space analysis presented here also takes into account information on (mostly private) off-street parking spaces, which were also systematically collected. These include general, mostly surface parking spaces, underground garages, garages and carports as well as multi-storey car parks. For these types of objects it is easy to collect the exact capacity, as they are often marked and countable. Alternatively, the parking space capacity can be estimated based on the space’s geometry (in the case of multi-storey objects, taking into account their horizontal dimension).

Since many of these parking spaces cannot be accessed freely, external geodata sets were included for the survey. Fortunately such data is available in Berlin in good quality and under an OSM conformant licence: Aerial photographs were systematically checked for parking spaces in backyards, etc., and underground parking spaces or information on garage buildings could be gathered from the Government’s Cadastre Information System (ALKIS). After plausibility checks, this data was included in the raw data sets used – especially in the case of underground garages. However, only the features that could be checked on the ground were mapped in OSM, i.e. the entrances and exits, but not the underground garage area.

The parking space data are recorded not only with their geometric extent, but can also contain additional attributes such as restrictions on use or accessibility (public/private/customers etc., fees, time restrictions) and can be specifically evaluated on this basis.

With a study area size of over 20 km², a road network length of about 170 km, a total of 2,200 driveways mapped in OSM and over 2,000 parking space sites, this initially sounds like a considerable amount of work. However, it was easily possible to record or check and complete this information within a few months as a single person.

Key statistics and findings

Many results and statistics of the project are presented in the Neukölln parking map. The focus of this project was more on the development of a method and the provision of data than on the interpretation of results, so they will only be discussed here briefly. More data and numbers can also be found in the methodology report and on the project’s data page.

For the district of Neukölln, a metropolitan residential neighbourhood with about 165,000 inhabitants, a total of more than 27,300 car parking spaces were found in the public street space. In addition, there are about 12,200 off-street parking spaces that are suitable for permanent or overnight parking for residents (as well as 8,100 parking spaces that are not suitable for permanent parking, such as employee and customer parking spaces, and almost 430 unused parking spaces, for example in abandoned underground garages).

If the two commercial areas on the outskirts of the district are left out of the calculation – meaning that only the residential areas are taken into account – there is a total of 35,447 parking spaces available for permanent parking, compared to 33,513 registered motor vehicles in the same area. Therefore theoretically, there are 1.08 parking spaces available for each motor vehicle.

The parking space analysis also included a fine-scale calculation of parking space densities, for which a separate population and motor vehicle data model was developed on the basis of external geographic and demographic data as well as motor vehicle registration data (details can be found in the methodology report (in German)). This allows the available parking spaces in a smaller area to be compared with the number of vehicles actually registered there. In the course of the parking space analysis, these parking space densities were calculated for a distance of 350 metres around a place of residence (350 metres correspond to the close-up distance around a place of residence, i.e. a distance that can be reached on foot within 3 to 4 minutes – at 7 or 5 km/h). The average (median) number of parking spaces in this distance is 835 (604 of which are on public roads) and the number of registered motor vehicles in the same distance is 759.

Figure 3: Parking space density in the residential neighbourhoods of the study area: ratio between available parking spaces and registered motor vehicles within 350 metres (3-4 minutes walk) of a location.

In the wake of the “Verkehrswende” which can be translated as the desired transition of mobility and the debates about more liveable cities, parking vehicles at the roadside have gained a lot of attention, as they constitute a permanent, comparatively high consumption of space. For the residential neighbourhoods of Neukölln alone, this land consumption by parked vehicles in the public street space can be quantified to a total area of 327,000 square metres, which corresponds to 19 per cent of the public traffic space and 4.4 per cent of the total research area. Off-street parking and parking spaces also take up an additional 171,000 square metres (2.3 per cent of the total area). Converted into the obligatory football fields, this means that 70 football fields in the residential neighbourhoods of Neukölln are taken up by stationary vehicles alone. 46 of those are in public street space.

Evaluation of uncertainty factors in the data model

This parking analysis is based on an interpolative data model, i.e. on statements and simplifications that are derived from geographical data and empirical assumptions in order to represent (a complex) reality in a model-like way and to make it “calculable”. Many of the underlying assumptions and results can be verified, counted or measured in factual reality. Others are subject to some uncertainties that can hardly be quantified or only with considerable empirical effort.

Because street parking significantly shapes the parking space situation, it is the core of the data model. Although the automatically generated parking lane data of the present parking analysis was manually post-processed, the results of this post-processing only differed by 0.6 percent from the raw data generated directly from OSM. However, significant sources of error can lurk in other places. The interpolated parking space numbers were compared with ground truth by counting more than 1,500 vehicles and parking spaces (not counting illegal parkers). Although the overall accuracy was very high, with a difference of less than one percent, there were three street sections with striking discrepancies. In these streets, where diagonal or perpendicular parking is arranged, the data model overestimated the influence of driveways and blocking objects in the parking space (trees, street lamps). In such cases, it may be worth comparing the result with reality and readjusting it if necessary, or specifying the actual number of parking spaces during data collection, if they can be clearly counted. However, an estimation of unmarked or not clearly countable parking space capacities should be avoided in mapping – a GIS can do this better and flexibly take into account underlying assumptions such as average vehicle lengths.

Additionally, there are a number of other factors that can lead to an over- or underestimation of the real parking situation compared to the data model. For some of the most important factors, an estimate was made in order to be able to take their influence into account when interpreting the data (more detailed in the methodology report). For example, the data model represents a legal situation; in reality, however, frequent parking violations can be observed – especially parking too close to intersections or parking in front of building passages (of which there are many in Berlin and which are often ignored). If one assumes that on average only a distance of 2.5 instead of 5 metres is kept in front of intersections and that parking is done in front of every second driveway, for example, the number of “parking spaces” already increases by 6 percent. On the other hand, in reality there are probably more vehicles than in the reporting statistics, especially due to company and rental cars – about 5 percent more vehicles can be assumed.

Another essential factor: the parking space data in private space must be understood as theoretically available parking space and not as actually used motor vehicle parking spaces, as their actual occupancy remains mostly unknown. Garages in particular, for example, are often used for other purposes than parking a car (assuming that half of all garages are not used for parking a car, the total number of parking spaces in the data model is reduced by 3 per cent, for example). Also, although the car parks in the study area are available to residents and contribute a total of almost 4 per cent of the total parking space capacity in the data model, in fact this potential is apparently not utilised, as a larger vacancy can often be observed.

Lessons learned for OSM mapping practice

The very small differences between the interpolated parking space numbers/those calculated from the OSM data and the real cars counted on site are in this case probably due to the comparatively high level of detail of the OSM data in the study area. For example, driveways were systematically completed and partly provided with width information; some streets also have exact width information (OSM key: width:carriageway – although the width of a street can generally be derived sufficiently precise from its attributes such as street type, one-way street or number of lanes). Most importantly, parking lane information was captured relatively accurately: Signposted parking and stopping restrictions were taken into account, as were other parking conditions of “significant” length, even if they only affect a 15-metre road segment, for example. Some mappers might shudder at the prospect of this level of micro-mapping – but such precise data can be extremely valuable, and not just for a project like this.

However, in most cases it is not even necessary to break up roads into many small segments, as the relevant information can be derived from other objects in the space if they are well mapped: For example, it is clear that parking is not allowed on a zebra crossing, in front of a bus stop or near a pedestrian traffic light. For some more specific situations, new tags have also been established here in the local mapping community that have proven to be very useful for this evaluation: In particular, details at sidewalk crossings such as kerb extensions or kerb-side road markings for pedestrians are mapped here in many places (discussions on such tagging take place here locally, especially in the Berlin Verkehrswende group and result, for example, in recommendations such as this one on the detailed mapping of pavement crossings). The new scheme for more detailed mapping of parking bays (parking=street_side) has also partly emerged from this parking analysis.

An exciting question is, of course, what influence the cartographic precision has on the result of the parking space analysis. A question I have yet to answer. However, during the first tests for such parking space analyses a year ago, I made the experience that especially in the case of diagonal and perpendicular parking, larger discrepancies can quickly occur, as many vehicles are parked along relatively short distances. If, for example, diagonal parking only begins 20 metres behind an intersection and the area in front of it is not recorded with the appropriate parking lane information (and if this information cannot otherwise be derived from other objects), an error of several parking spaces occurs already. Fine-grained mapping is therefore particularly worthwhile for perpendicular and diagonal parking.

The parking space analysis shows that an extremely precise reproduction of reality can be achieved with accurate mapping. However, it has also come up against the limits of some tagging schemes and the “taste” of other mappers. All in all, however, OSM has proven to be a perfect tool to capture even such specific information and use it for analyses. What can sometimes seem unfortunate is the fact that parking lane information is captured geometrically at the street line, rather than where it originates on-the-ground, namely at a kerb line. In fact, an OpenData specification for capturing parking lanes at the kerb line has been available for a year or two with CurbLR, including detailed considerations and a tagging scheme for implementation in OSM. However, this proposal has not yet made its way into actual mapping practice. Based on my experience in this parking analysis, it seems that the OSM-parking:lane scheme has proven to be sufficiently accurate and probably easier to analyse.

I am curious to see how the coverage of parking lanes in OSM continues to progress. In the last two years, the use of the parking:lane scheme seems to have increased somewhat. Likewise, especially in big cities, discussions about parked vehicles and spatial justice are increasing, which means that data like the one presented here will become more and more important in urban development, planning and democratic discussions about these issues. OSM has once again proven to be a suitable tool to make such data accessible to all – now it is up to us to collect this data.

Translation: tordans, koriander

Die Qualität von Straßenoberflächen ist ein wichtiger Faktor, insbesondere um gezielt Routen danach auszurichten. Wer auf einem Rennrad oder Inline Skates unterwegs ist oder einen Kinderwagen über sanft schaukelnde Oberflächen schieben will, wird sich freuen, wenn Routing-Algorithmen (oder die User selbst) auf Informationen zur Oberflächenbeschaffenheit zurückgreifen können. Schlechte Oberflächen wie Kopfsteinpflaster sind für einige Verkehrsmittel unpassierbar und auch beispielsweise mit einem normalen Stadtrad muss die Geschwindigkeit an solchen Stellen oft erheblich reduziert werden.

Zur Bewertung der Oberflächenbeschaffenheit gibt es in OSM – neben surface für den Fahrbahnbelag selbst – den Schlüssel smoothness, der jedoch oft mehr oder weniger nach subjektiven Kriterien vergeben wird. Ein Autofahrer wird hier beispielsweise etwas andere Maßstäbe anlegen als eine Rennradfahrerin. Dabei besitzen fast alle Mapper ein Smartphone und könnten damit auf ein hochpräzises Sensorium als Entscheidungshilfe für die Kategorisierung zurückgreifen, wenn sie es an einem Fahrzeug fixieren und die Vibrationen aufzeichnen. Ob das funktioniert, habe ich auf einem Abendspaziergang mit dem Fahrrad getestet.

Voraussetzung ist ein Beschleunigungssensor/Accelerometer, wie es eigentlich jedes aktuelle Smartphone an Bord haben müsste. Ich habe meins (ein aktuelles 300-Euro-Mittelklasse-Gerät) mit einer flexiblen Silikon-Halterung am Lenker befestigt und bin eine Teststrecke mit verschiedenen Oberflächen abgefahren. Die Vibrationen habe ich mit der erstbesten App, die ich zur Aufzeichnung des Beschleunigungssensors gefunden habe, mitgeschnitten. Die Silikonhalterung führt vermutlich dazu, dass die Vibrationen verstärkt werden und damit differenziertere Ergebnisse ermittelt werden. Die (absolute) Beschleunigung in X-, Y- und Z-Richtung habe ich zu einem Mittelwert zusammengefasst, der Grundlage für die folgenden Ergebnisse ist.

Das Ergebnis

Die Oberflächen besitzen – in Abhängigkeit von ihrer Oberflächenebenheit – auf jeden Fall ein eindeutiges „Vibrationsprofil“: Exzellente Fahrbahnen weisen sehr niedrige Vibrationswerte mit einer sehr niedrigen Varianz auf, gute Fahrbahnen lassen sich durch höhere Varianzen klar abgrenzen. Bei mittelmäßigen Oberfllächen steigen sowohl Vibrationen als auch Varianz spürbar an. Auf schlechten Oberflächen (in meinem Fall mehrere Kopfsteinpflasterabschnitte) steigen die Werte noch einmal sprunghaft an. Beispielhaft die Ergebnisse für ausgewählte Streckenabschnitte:

surface	smoothness	Median [m/s²]	St.-Abw.	Vibration	Varianz
asphalt	excellent	0,674	0,317	sehr niedrig	sehr niedrig
asphalt	excellent/good	0,742	0,77	sehr niedrig	niedrig
paving_stones	good	1,03	0,633	eher niedrig	niedrig
asphalt	good	1,075	0,869	niedrig	eher moderat
compacted	intermediate	1,577	1,011	moderat	eher hoch
sett	bad	6,554	4,036	sehr hoch	sehr hoch

Werden die aufgezeichneten Vibrationen visualisiert, lassen sich die verschiedenen Oberflächenprofile eindeutig voneinander unterscheiden:

Was folgt daraus?

Die Messung von Vibrationen mit einem Smartphone-Sensor ergibt hervorragende Ergebnisse, um die Ebenheit von Oberflächen (objektiv) klassifizieren zu können. Die Ergebnisse könnten Mappern damit als Entscheidungshilfe zur smoothness-Kartierung dienen. Beachtet werden sollte dabei meiner Meinung nach Folgendes:

• Vermutlich ermittelt jeder Mapper mit seinem Gerät und seiner Halterungstechnik eigene Größenordnungen, innerhalb derer die Vibrationswerte schwanken. Um die Werte „automatisiert“ zu erfassen, braucht es also eine individuelle Eichung am eigenen Halterungs- und Fahrstil.

• Die Fixierung des Geräts am Fahrzeug (ideal: Fahrrad) muss ebenso konstant gehalten werden wie der Fahrstil bzw. die Geschwindigkeit (wird ein Streckenabschnitt langsamer befahren, ergeben sich andere Werte als bei schneller Fahrt).

• Ich habe die Test-Streckenabschnitte einzeln aufgezeichnet und – um Manipulationen durch die Bedienung des Geräts auszuschließen (Hand am Smartphone, teils Geschwindigkeitsreduzierung) – jeweils am Anfang und am Ende Werte aus der Auswertung ausgeschlossen. Die Aufzeichnung könnte aber – besonders bei längeren Fahrten – auch parallel zu einem GPS-Track mitlaufen. Aus der Aufzeichnung ergibt sich das Intervall, wie oft ein einzelner Beschleunigungswert aufgezeichnet wurde, was sich mit dem GPS-Track (Ort und Zeit) vergleichen lassen müsste.

• Am Ende sollte dennoch immer die Mapperin/der Mapper entscheiden, insbesondere um weitere qualitative Merkmale zu berücksichtigen. Eine ebene Fahrbahn, die jedoch regelmäßig kurz durch starke Wurzelschäden durchbrochen wird, könnte beispielsweise eher geringe Vibrationswerte aufweisen (aber auch eine höhere Varianz).

• Bei Gelegenheit versuche ich weitere Teststrecken aufzunehmen, um solche Faktoren ebenso beurteilen zu können wie beispielsweise den Einfluss des Fahrbahnbelags (z.B. sehr schlechter Asphalt, Fahrbahnen mit sehr gut versiegeltem Kopfsteinpflaster…). Im Idealfall kann ich numerische Klassen bilden, um die smoothness-Werte abzubilden.

Zum Abschluss noch eine radfahrbasierte Klassifizierungshilfe für die Bewertung der Oberflächenqualität/Ebenheit einer Fahrbahn, die ich kürzlich im Zuge von Überlegungen zu einem erweiterten Radwegeschema aufgestellt habe – ganz ohne Smartphone:

• excellent: Glatter, unbeschädigter Asphalt mit sehr guten Rolleigenschaften und ohne spürbare Vibrationen (Faustregel: Perfekt zum Inlineskates fahren).

• good: Asphalt (oder andere glatte versiegelte Oberfläche) mit höchstens kleineren Schäden oder Rissen, die kaum spürbare Verwerfungen hervorrufen. Insbesondere ohne Wurzelschäden o.ä. (Faustregel: Perfekt zum Rennrad fahren).

• intermediate: Im allgemeinen gut befahrbare Oberfläche, auf der aber kleinere Verwerfungen spürbar sind: Beispielsweise Pflastersteine/Kleinpflaster mit geringen Zwischenräumen, Asphalt mit kleineren, seltenen Wurzelschäden, gut verfestigter Boden oder sehr gut (!) versiegeltes Kopfsteinpflaster (Faustregel: Perfekt zum Fahren mit einem Stadtrad).

• bad: Deutlich spürbare Verwerfungen oder “Rütteln”, z.B. auf üblichem Kopfsteinpflaster, aufgrund zahlreicher Wurzelschäden/Schlaglöcher oder auf unbefestigten Wegen mit Pfützenlöchern oder ähnlichem. Nicht mehr zum Rennradfahren geeignet, signifikanter Geschwindigkeitsverlust (Faustregel: Beim nächsten Mal kaufe ich mir ein Fahrrad mit besserer Federung - oder gleich ein Mountain Bike)

• very_bad: Starke Verwerfungen oder Schäden, nicht mehr zum Radfahren mit City- oder Trekkingrad geeignet bzw. nur mit erheblichem Geschwindigkeitsverlust (Faustregel: Wege, nach deren Befahrung ich dem zuständigen Baustadtrat eine E-Mail schreibe – und wirklich ein Mountain Bike brauche)

---

---

Zusammenfassung: Bei der Diskussion um die Verkehrswende rückt insbesondere in Großstädten immer wieder das Thema Parkplätze und der Flächenverbrauch von (stehenden) Fahrzeugen in den Mittelpunkt. Auch rund um eine aktuelle Diskussion zur Einrichtung eines Radwegs an der Berliner Hermannstraße wird darüber diskutiert. Das habe ich zum Anlass genommen, die Parkplatzsituation dort mit Hilfe von OSM-Daten und ergänzenden Geodaten genauer anzusehen:

• Im Umkreis von 500 Metern um einen 2,6 Kilometer langen Abschnitt der Hermannstraße gibt es etwa 15.000 Parkplätze, davon 10.500 auf Parkspuren am Straßenrand.
• 4% der Gesamtfläche im Untersuchungsgebiet werden durch Parkspuren belegt – bezogen auf den öffentlichen Straßenraum zwischen den Gebäudefassaden sind es sogar über 20%.
• Allein in diesem kleinen Stadtgebiet wird damit bereits eine Fläche von 23 Fußballfeldern durch stehende Autos belegt.
• Theoretisch gibt es mehr verfügbare Parkplätze als Autos – praktisch scheinen Ausweichpotentiale jedoch nicht genutzt zu werden, wenn sie nicht vor der Tür bzw. in unmittelbarer Umgebung liegen.

---

---

Seit Beginn der Corona-Pandemie sind in Berlin – wie auch in anderen Städten in Deutschland und weltweit – zahlreiche „Pop-up-Radwege“ entstanden, um insbesondere Radfahrenden, die volle Nahverkehrsangebote meiden möchten, mehr Sicherheit im Straßenverkehr zu bieten und den Umstieg aufs Fahrrad zu erleichtern. Dabei werden Spuren für fahrende oder parkende Kraftfahrzeuge kurzerhand zu Fahrradwegen umgewidmet, wo es für ein Mindestmaß an Verkehrssicherheit notwendig ist. Zwar verfügt Berlin seit wenigen Jahren über ein weitgehendes Mobilitätsgesetz, um andere Verkehrsarten gegenüber dem Autoverkehr zu stärken und damit den Grundstein für eine zeitgemäße urbane Verkehrsinfrastruktur zu legen. Viele Straßen genießen jedoch noch immer den Ruf von „Fahrradhöllen“, sodass sich Radfahrende nicht wegen, sondern trotz der Infrastrukturen auf zwei Rädern fortbewegen.

Eine dieser Straßen ist die Hermannstraße im Bezirk Neukölln, auf der nun auch ein Pop-up-Radweg entstehen soll. Die Umsetzung lässt derzeit aufgrund von Prüfungs- und Planungsvorgängen noch auf sich warten; blockiert wird die Radspur im wahrsten Sinne des Wortes aber auch von parkenden Fahrzeugen, die dem Vorhaben weichen müssten. Die Diskussionen um das Vorhaben habe ich zum Anlass genommen, mit Hilfe von OpenStreetMap-Daten eine Parkplatzzählung für das Umfeld der Hermannstraße vorzunehmen, um eine bessere Einschätzung der Größenordnungen und Raumaufteilung zu bekommen, um die es hier geht. Damit wiederhole ich an einem praktischen Beispiel eine erst kürzlich durchgeführte Parkplatzanalyse für einen anderen Berliner Kiez, die als Demonstration der Möglichkeiten von OpenStreetMap (OSM) in Verbindung mit der Geoinformationssoftware QGIS gedacht war. Diese kann hier eingesehen werden und umfasst auch eine anfängerfreundliche Schritt-für-Schritt-Anleitung zur Umsetzung.

Hinweis: In der Berliner OSM-Community gibt es seit einem Jahr eine Verkehrswendegruppe, die sich mit der Erfassung, Pflege und Verarbeitung von Verkehrsinfrastrukturen bzw. mobilitätsbezogenen Geodaten beschäftigt. Ziele dieser Gruppe sind unter anderem Auswertungen wie die Folgende.

Das Vorgehen und die Methodik

Ziel der Parkplatzanalyse war es, einen Überblick über die Parkplatzsituation und den Flächenverbrauch parkender Kfz im Umkreis von 500 Metern um den 2,6 Kilometer langen Abschnitt der Hermannstraße zu erlangen, an dem über eine Radverkehrsanlage diskutiert wird. Der Wert von 500 Metern wurde als gut erreichbare „Ausweichdistanz“ angenommen. Da im Bereich des Radweges noch unklar ist, welcher Anteil von Parkplätzen entfallen soll – wobei eine niedrige bis mittlere dreistellige Zahl von Parkplätzen diskutiert wird – wurden diese Parkplätze insgesamt gar nicht erst in die Auswertung einbezogen. Die Berechnung geht also vollständig ohne Parkplätze an der Hermannstraße selbst aus und bezieht sich ausschließlich auf ihr Umfeld.

Zum Parken geeignet sind in erster Linie die Parkspuren im öffentlichen Straßenraum. Relevant sind jedoch auch (zumeist private) Parkplätze, Garagen und Tiefgaragen. Daten dazu lassen sich mit OSM erfassen und sind in Neukölln in einigen Kiezen bereits gut vorhanden. Für den Untersuchungsraum der Hermannstraße habe ich vorher noch ein paar Lücken gefüllt: Also Straßen mit fehlenden Parkspuren komplettiert, Parkmöglichkeiten in Hinterhöfen etc. gesucht und Gebäudeeinfahrten ergänzt. Begehungen vor Ort, Mapillary und die in OSM-kompatibler Lizenz vorliegenden detaillierten Daten des Berliner Geoportals – insbesondere hochaufgelöste Luftbilder – sind dabei hilfreich.

Liegen die genannten Daten vor, können sie mit QGIS weiter verarbeitet werden. Basis der Analyse ist es, aus der Länge von Straßenabschnitten und den Informationen zum Parken bzw. Parkverboten in ihrem Verlauf auf die Anzahl von Parkplätzen zu schließen. Automatisiert lassen sich dabei Bereiche aus der Zählung ausschließen, die nicht zum Parken geeignet sind: Kreuzungsbereiche, Einfahrten, Fußgängerüberwege, Bushaltestellen oder auch blockierte Parkplätze durch Baumscheiben oder Fahrradständer im Fahrbahnbereich. Nicht berücksichtigt bleiben temporäre Park- und Halteverbote, da sie für die Gesamtsituation nur eine geringe Bedeutung haben (da sie insbesondere meist nur am Tag gelten, die meisten Fahrzeuge hier aber nachts abgestellt werden). Darüber hinaus können die Kapazitäten von Parkplätzen, Garagen und Tiefgaragen – wo nicht bereits exakt erfasst – aus ihrer Flächengröße abgeleitet werden.

In diesem Fall habe ich die Daten in QGIS gründlich weiter nachbearbeit – beispielsweise Tiefgaragenflächen aus dem Berliner Geoportal sowie weitere vereinzelt fehlende Daten integriert und Straßenabschnitte insbesondere mit Diagonal- und Querparken korrigiert – sodass sich mir der Eindruck weitgehend vollständiger Daten ergibt. Als Extra konnte ich aus kleinflächig vorliegenden Daten zur Einwohnerzahl (aus dem Berliner Geoportal) die erwartbare Anzahl von Pkw abschätzen und mit der Parkplatzverfügbarkeit verknüpfen, woraus sich ein Bild der „Parkplatzdichte“ ergibt.

Ziel ist stets eine gute Annäherung an die Größenordnungen des Parkens, nicht eine exakte Wiedergabe des Ist-Zustands. Eine Abschätzung der (wahrscheinlich eher geringen) Fehlerquote dieser Form der Berechnung findet sich in der Demo der ersten Parkplatzanalyse.

Das Ergebnis

In einem Umkreis von 500 Metern um den 2,6 Kilometer langen Abschnitt der Hermannstraße befinden sich etwa 15.000 Parkplätze. Diese teilen sich auf in:

• 10.480 Parkplätze am Fahrbahnrand im öffentlichen Straßenraum,
• 2.721 Stellplätze in (privaten) Tiefgaragen,
• 1.031 Stellplätze auf (privaten) Parkplätzen,
• 686 Stellplätze in (privaten) Garagen,
• entspricht insgesamt 14.918 Stellplätzen.

Die untenstehende Karte (Abb. 1) zeigt die Straßenabschnitte mit Längs-, Schräg- und Querparken sowie alle weiteren Parkplatzflächen. Entlang von 42 Kilometern Straßenlänge kann auf 48,5 Kilometern (oft zugleich links- und rechtsseitig) geparkt werden.

Die Gesamtfläche des Untersuchungsgebiets beträgt 3,36 km². Die 10.480 Parkplätze im öffentlichen Straßenraum verbrauchen eine Fläche von etwa 132.000 m² (oder in die berühmten Fußballfelder umgerechnet: Mehr als 18 Fußballfelder). Das entspricht einem Anteil von vier Prozent der Gesamtfläche des Untersuchungsgebiets und etwa 20 Prozent des öffentlichen Raumes zwischen den Gebäudefassaden (vgl. Abb. 2). (Oberirdische) Parkplätze und Garagen beanspruchen noch einmal etwa 38.700 m² (etwa 5,5 Fußballfelder).

Übrigens befinden sich im Untersuchungsgebiet Kundenparkplätze (z.B. vor Supermärkten) mit einer Gesamtkapazität von fast 2.000 Stellplätzen, darunter zwei Parkhäuser mit je 500 Stellplätzen. Diese sind nicht in die Auswertung eingeflossen, da sie üblicherweise nicht zum privaten Parken genutzt werden können. Da Kundenverkehr jedoch üblicherweise tagsüber stattfindet und privates Parken über Nacht seinen Höhepunkt findet, läge hier theoretisch ein großes Ausweichpotential.

Auf Grundlage kleinteiliger Bevölkerungsdaten konnte ich zuletzt noch eine Parkplatzdichteverteilung ermitteln, also die Anzahl verfügbarer Parkplätze mit der Zahl erwarteter Fahrzeuge vergleichen. Im Untersuchungsgebiet wohnen laut diesen Daten 72.161 Menschen. Auf 1.000 Personen kommen dabei etwa 200 private Pkw (im nördlichen Teil eher weniger, im südlichen Teil mehr – genauere Daten auf Blockebene habe ich nicht vorliegen). Das entspricht insgesamt einer Anzahl von 14.400 Fahrzeugen, also etwa 500 weniger als Stellplätze ermittelt wurden (sogar ohne die real vorhandenen Parkplätze an der Hermannstraße, die aus oben genannten Gründen nicht berücksichtigt wurden). Für die abgebildete Dichteverteilung (Abb. 3) wurde für jeden einzelnen Parkplatz ermittelt, wie viele andere Stellplätze und wie viele Bewohnerinnen und Bewohner (bzw. daraus abgeleitet private Pkw) im Umfeld angenommen werden können, woraus sich Ausweichflächen mit (theoretischem) Überangebot an Parkplätzen ergeben.

Das Fazit

Die Parkplatzzählung illustriert einen hohen Flächenverbrauch durch privaten Pkw-Verkehr: Ein Fünftel des öffentlichen Straßenraums wird lediglich als Standfläche für Autos verwendet. Die Bewertung, ob dieser Flächenverbrauch für die Annehmlichkeit privater Pkw-Stellplätze in der Innenstadt gerechtfertigt ist und in welchem Verhältnis diese Annehmlichkeit zur Sicherheit von anderen Verkehrsteilnehmern steht, kann jeder für sich selbst vornehmen…

Die Parkplatzzählung und -dichteverteilung ergibt ein theoretisches Überangebot an Kfz-Stellplätzen, wovon in der Realität jedoch – zumindest auf den ersten Blick – wenig zu erkennen ist. Möglicherweise ist das ein weiteres Indiz dafür, dass freie Stellplatzkapazitäten nicht genutzt werden, da die Bereitschaft bei Autonutzenden gering ist, wenige 100 Meter zu einem Stellplatz zurückzulegen.

Last Edit by SupapleX on 1 April 2023

Inzwischen ist Augmented Reality im wahrsten Sinne des Wortes in der Realität angekommen – auch unserer OSM-Realität. Und das im Guten wie im Schlechten. Der Hype um The Elder Scrolls Go (TESG) hatte ja spätestens seit Sommer letzten Jahres erneut zu einer eher zweifelhaften Qualitätsentwicklung der OSM-Daten geführt – wie oft schon mussten wir bei Grünflächen in unserer Gegend die Wald- und Sumpftaggings wieder entfernen, weil irgendwelche TESG-Kiddies hofften, damit Zweiglinge neben ihrem Schulhof spawnen zu lassen. In einigen abgelegeneren Gebieten hat die ganze Map Engine Optimization bereits heftigste Blüten geschlagen, wo sich Gamer ganze Traumwelten für den Sommerurlaub zusammengemappt haben.

So kamen wir jedenfalls auf die Idee, das sich mit dem Augmented Reality-Hype bestimmt auch ein Gewinn für OSM erzeugen ließe, wenn wir nur das richtige Werkzeug dafür hätten. Gerade in Großstädten wie hier in Berlin, wo uns seit Jahren die noch fehlenden Objekte ausgegangen sind und es nur noch um Datenpflege und immer detaillierte Micro-Mappings im letzten Hinterhof geht, dürfte damit noch einmal ein ordentlicher Schub für die Datenqualität herauszuholen sein – sowohl geodätisch als auch für noch fehlende Tags.

Der aus diesen Überlegungen entstandene Augmented Editor funktioniert im Prinzip ganz einfach und lässt sich wie JOSM als Ebene im realen Raum vorstellen: Während man sich durch die Straßen bewegt (in der Realität, also „draußen“), werden die Nodes, Ways und Polygons der OSM-Datenbank ins Sichtfeld projiziert. Objekte können mit Hand-Gesten verschoben oder einfach nur ausgewählt werden, um Eigenschaften zu verändern. So lassen sich z.B. Gebäudeumrisse oder Node-Standorte nebenbei auf dem Weg nach Hause ganz bequem zentimentergenau anpassen. Neue Objekte anlegen können nur User mit mehr als 200 Changesets – wobei diese Funktion vor allem für Nodes und kürzere Ways gedacht ist. Für großflächigere Bearbeitungen eignet sich der gewohnte Sessel-Editor eurer Wahl wohl weiterhin am besten und die neuen 10cm-Orthophotos für Europa bieten dafür ja auch schon eine geeignete Grundlage.

Im 3D-Modus des Editors werden die Objekte außerdem realistisch gerendert, was es beispielsweise vereinfacht, fehlende oder verschobene Objekte beim Durchstreifen der Straßen zu entdecken. Die meisten der im Wiki dokumentierten Attribute haben bereits ein Modell bzw. Textur und auch Gebäude werden - je nach Einstellung - gerendert, wobei wir auf das OSM 3D Model Repository zurückgreifen. In diesem Modus lassen sich bequem Objekthöhen, Farben, Materialien und ähnliches bearbeiten. Das Ergebnis kann direkt vor Ort in Echtzeit überprüft und mit dem tatsächlichen Objekt abgeglichen werden.

Zuletzt haben wir mit dem Attribute-Modus eine weitere einfache Möglichkeit für den Datenabgleich integriert: Dabei werden nicht die Objekte selbst, sondern lediglich ihre Eigenschaften eingeblendet. In der Projektion erscheinen Infoblasen über den Positionen, an denen sich laut OSM bestimmte POI‘s befinden. Dieser Modus ist besonders für Geschäfte, Stadtmöbel und ähnliches geeignet, sodass sich fehlende oder fehlerhafte Namen, Öffnungszeiten und andere wichtige Eigenschaften schnell erkennen und beheben lassen.

Geplant ist für die nähere Zukunft außerdem ein Routing-Modus, mit dem sich bestimmte POI‘s direkt im Editor abfahren lassen. Dieser wäre z.B. für die laufende Wochenaufgabe zur Pflege der inzwischen immer seltener werdenden alten Deutsche-Post-Briefkästen geeignet: Einfach alle gemappten Briefkasten-Nodes im Augmented Editor abfahren, vor Ort prüfen, ob noch vorhanden und ggf. löschen. In einigen Gegenden sollen sogar – trotz des vor kurzem abgeschlossenen automatischen Exports – noch Telefonzellen gemappt sein…

Probleme entstehen im Augmented Editor bisher – neben dem desaströsen Breitand-/Mobilfunkausbau in Deutschland – vor allem durch User, die manuell eine ungenaue Kartenprojektion als Grundlage eingestellt haben und dabei ihre halbe Stadt um einen Meter versetzen. Die Verortung im Raum selbst funktioniert über die Kombination aus Galileo und GPS (soweit von den Geräten noch unterstützt) allerdings inzwischen sehr gut. Zur Not bzw. fürs Indoor-Mapping tuts auch OWPS (Open Wifi Positioning System).

Die Software für den Augmented Editor findet ihr natürlich auf GitHub; Sprachunterstützung gibt es zur Zeit für die 162 Sprachen aus dem Language Machine Learning Project. Der Editor läuft bisher leider nur unter Android – wer eine Portierung für Amazon OS beisteuern kann, kann sich gern bei uns melden!