OpenStreetMap

tordans's Diary

Recent diary entries

I wrote a blog post to show and explain the many improvements to the “Straßenraumkarte” that Alex @Supaplex030 worked on for the last few month: https://supaplexosm.github.io/strassenraumkarte-neukoelln/posts/2021-12-31-micromap-update

With this public space map for Neukölln, Berlin Alex continues to push the boundaries of the level of detail that can be rendered based on OSM data.

The blogpost shows many interesting details like cycleways, turn lanes and junctions and explains how the data is processed to allow this rendering.

One conclusion is, that a collaboration on pre-processed OSM data for streets would be a huge benefit.


Please use this place here to comment on the blog post.

Ausschnitt der Straßenraumkarte Neukölln mit Details wie parkenden Autos, Fuß- und Radwegen.

Tobias: Hallo Alex, das ist unser Teil 2 auf dem Weg zur Beschreibung deiner größeren Parkraum-Analyse. In Teil 1 haben wir uns angeschaut, wie du mit Hilfe verschiedener OpenData-Quellen ein Bevölkerungsmodell und Autobesitzer-Modell auf Häuser-Ebene erstellt hast.

Jetzt schauen wir uns ein anderes Nebenprodukt an:

Eine Karte von dem Ortsteil Neukölln in einem ganz eigenen Kartenstil.

Das ist die erste Karte, die ich so kenne, bei der die parkenden Autos anhand des Parking-Lane-Schemas von OSM visualisiert sind. Das gibt der Karte gleich einen ganz anderen Informationsgehalt und auch eine andere Stimmung. Darüber hinaus gibt es weitere Gestaltungsentscheidungen, die ich spannend finde, über die wir jetzt sprechen.

Screenshot: Vergleich bei Zoomstufe 16 zwischen dem OSM Standard-Kartenstil und der Straßenraumkarte

Was macht den Kartenstil besonders?

Tobias: Was ist an diesem Kartenstil aus deiner Sicht grundsätzlich anders als bei der Standard-OSM-Karte oder bei anderen bekannten Karten?

Alex: Du hast ja schon erwähnt, die Autos sind auf jeden Fall etwas besonderes. Das ist ein Ziel dieser Karte gewesen: die parkenden Autos und die Straßen im Straßenraum darzustellen. Sie stellt aber auch sehr präzise die Straßenraumaufteilung dar. Und dafür ist insbesondere die Bordsteinkanten-Information sehr relevant. Straßen sind – wie normalerweise in Karten – nicht einfach nur Linien mit einer generischen Breite. Stattdessen zeige ich die real existierenden Fahrbahnflächen: Mit Rundungen im Kreuzungsbereich, mit Gehwegvorstreckungen und mit sonstigen speziellen Formen und Abweichungen, die es in der Realität gibt. Davon lebt diese Karte auch und ich stelle es mir relativ schwierig vor, diesen Kartenstil ohne diese Bordstein-Informationen zu erzeugen. Man könnte zwar generische Straßenbreiten annehmen, das habe ich auch in dem Modell für die Parkraum-Analyse so gemacht. Das funktioniert relativ gut, solange die präzise Darstellung unwichtiger ist. Aber da es hier wirklich darum geht, eine sehr hohe Präzision in der Straßenraumaufteilung darzustellen, ist die generische Straßenbreite keine Lösung. In meiner Darstellung kann man beispielsweise sehen, wenn ein Poller zwanzig Zentimeter vom Bordstein entfernt steht.

Tobias: Lass uns gleich nochmal im Detail auf die Bordsteine schauen. Vorab aber: Welche anderen kleinen Details fallen dir ein, die sich lohnen hervorgehoben zu werden?

Urbanes Micro-Mapping

Alex: Das meiste ergibt sich aus den OSM-Daten, in die alle Aktiven in Neukölln viel Liebe reinstecken. Das ist auch ein Alleinstellungsmerkmal dieser Karte, sie lebt davon, dass die Datengrundlage sehr gut und präzise ist. Ich nenne das immer „urbanes Micro-Mapping”, was wir hier in Neukölln betreiben. Dieses Mikro-Mapping wird in Berlin zum Glück vereinfacht, weil wir gute, externe Datensätze von der Stadtverwaltung haben – mit einer OSM-kompatiblen Lizenz –, mit denen wir die on the ground vorgefundenen Dinge zuhause am Computer sehr präzise verorten können. Und die Daten sind wirklich zentimetergenau. Das merkt man zum Beispiel an diesen Bordsteinkanten.

Spielplätze

Was mir persönlich sehr gut gefällt in der Karte, sind die Visualisierungen auf Spielplätzen. Ich habe beispielsweise die Spielgeräte angedeutet. Ich träume schon seit längerem von so einer Art Spielplatzkarte, auf der man den Spielplatz mit seinen Schaukeln und Mülleimern in eine Art Übersichtsplan sehen kann.

Screenshot: Spielplatz zwischen Karl-Marx-Platz und Richardplatz mit ausgerichteten Bänken, Wegen, Sandkasten und angedeuteten Spielgeräten. Zum Kartenausschnitt

Fahrbahnmarkierungen

Ein weiteres Detail sind die Fahrbahnmarkierungen. Es gibt zum Beispiel Zebrastreifen und Haltelinien vor Ampeln oder Stoppschildern. Gut gefallen mir auch die Gehweg- und Radwegfurten. Ist alles noch etwas provisorisch und es fehlen viele Markierungen, ist aber schonmal ein nettes Detail. Ich plane mittelfristig dann auch Fahrspuren, Turn Lanes und soetwas einzubauen. Gleichzeitig merkt man bei den Haltelinien auch, dass man bei der Darstellung an Grenzen stößt, gerade was die Ausrichtung angeht. Ich habe mir ein Tagging-Schema ausgedacht, um einer Haltelinie neben ihrer bereits erfassten Position auch einen Winkel zuzuordnen, wenn sie nicht rechtwinklig zum Straßenverlauf ist. So dass man sagen kann, die Haltelinie in dieser Straße ist z.B. im Winkel von 168 Grad ausgerichtet. Das ist dann in so einer Visualisierung sehr wertvoll. Gerade bei spitzwinklig aufeinandertreffenden Straßen.

Screenshot: Haltelinien und Fußgängerübergänge; zum Kartenausschnitt

Bäume

Tobias: Die Bäume sind mir auch aufgefallen. Du hast die transparent dargestellt und auch die Kronen in verschiedenen Durchmessern. Wie ist das gebaut?

Alex: Es gibt einzelne Bereiche in Neukölln, wo die Kronendurchmesser tatsächlich in den OSM-Daten stecken. Z.B. habe ich vor ein paar Jahren mal einen Abgleich mit den Baumkatasterdaten des Senats gemacht und in diesem Zuge den Kronendurchmesser auf Basis von belaubten Orthofotos für vierhundert Bäume eingetragen. Bei den meisten Bäumen kann man den Durchmesser aber nicht aus bestehenden Daten ableiten. Ich habe für die Darstellung daher einen durchschnittlichen Zufallswert als Durchmesser genommen. Ein Nebeneffekt dieser Technik ist, dass ein Baum auf verschiedenen Zoom-Stufen einen unterschiedlichen Kronendurchmesser haben kann – das ist noch nicht ganz perfekt.

Architektur-Karten

Aber trotz dieser kleinen Fehler passen die halbtransparenten und unterschiedlichen Bäume gut in den etwas verspielt-realistischen Stil der Karte. Ich habe mich dabei an Architektur-Karten orientiert, die ja auch mit so einem pseudo-realen Stil daherkommen. Daher sehen auch die Bänke ein bisschen aus wie Bänke.

Autofarbe

Tobias: Welche Bedeutung haben die Farben der Autos?

Alex: Die Farbe der Autos hat keine Bedeutung. Es gibt in der Parkraumkarte auch einen Layer, in dem sie nur als farbige Blöcke dargestellt sind. Für die Straßenraum-Karte haben sich die Autos aber harmonischer ins Bild gefügt, wenn es mehr als ein Modell gibt – ich wechsele drei Modelle ab – und auch die Farbe wechselt.

Gullideckel

Tobias: Welches anderes Detail der Karte möchtest du noch erwähnen?

Alex: Wenn du schon so fragst … – Es gibt Gullideckel. Beispielsweise in der Nähe von “Am Sudhaus”. Die fallen zwar gar nicht auf, und es gibt auch relativ wenige Gullideckel in OSM, aber sie werden tatsächlich auch gerendert. Die Textur ist genau dieselbe wie im Computerspiel Cyperpunk 2077 (dort gibt es sogar eine Petition dazu) – nur dass man das in dieser Größe in der Straßenraumkarte nicht erkennen kann ;-).

Screenshot: Vier Gullideckel als graue Flächen auf der Straße. Zum Kartenausschnitt, Beispiel OSM Node, Overpass Turbo für Gullideckel

Bordsteinkante

Tobias: Lass uns nochmal detaillierter über die Bordsteinkante sprechen. Sie umschießt in deiner Darstellung – je nach Sichtweise – entweder den Häuserblock oder die Fläche der Straße. Für mich ist das eines der wichtigsten Elemente der Karte.

Screenshot: Overpass Turbo für alle Flächen mit landuse-Wert, https://overpass-turbo.eu/s/14lo

In Berlin haben wir für so eine Darstellung schon gute Vorarbeit geleistet, da in einigen Bereichen die Bordsteinkante als Grenze für eine landuse=residential (…) Fläche verwendet wird. Diese Praxis hat aber auch Nachteile. Wie bist du vorgegangen?

Alex: Tatsächlich ist mein Ziel, die Bordsteindaten mittelfristig komplett auf OSM zu basieren. Zur Zeit sind diese Daten aber eine Mischung aus OSM und ALKIS-Daten aus dem Berliner Geoportal. Die ALKIS-Daten haben den Vorteil, dass sie sehr präzise und vollständig sind. Sie haben aber an einigen Stellen den Nachteil, dass sie weniger aktuell sind als OSM – und in QGIS bin ich bei ihnen auf sehr viele Geometriefehler gestoßen, die die Verarbeitung erschweren. Ich haben daher einen manuellen, “handkuratierten” Datensatz erstellt, bei dem ich ALKIS-Daten mit OSM-Daten angereichert, aktualisiert und korrigiert habe. Das zu bauen ist Handarbeit, und ich versuche es gerade parallel aktuell zu halten. Änderungen an den Bordsteinen pflege ich also zur Zeit in meinen Datensatz nach. Ideal wäre, wenn wir in Neukölln den Bordstein mit barrier=kerb erfassen würden. Dann könnte ich komplett auf ALKIS-Daten verzichten. Wenn wir das einmal umgesetzt hätten, könnten wir auch die Berliner Praxis, landuse=residential an der Bordsteinkante enden zu lassen, verabschieden. Für mich wäre ideal, wenn die landuse-Fläche auch dort endet, wo real das Grundstück endet – am Zaun oder an der Mauer. Der Bürgersteig ist dann gedanklich eine andere landuse-Fläche – wobei man das für meine Karte gar nicht einzeln erfassen muss. Überhaupt kommt die Darstellung vollkommen ohne das area:highway-Schema aus.

Wie die Autos ihre Parkposition finden …

Tobias: Lass uns nochmal auf die Autos schauen. Die Information, ob Autos in der Straße parken, bekommst du vom parking:lane Schema. Aber wie platzierst du die Autos richtig an der Bordsteinkante?

Alex: Die richtige Positionierung war tatsächlich die größte Arbeit. Ursprünglich hatte ich ja vor, diese Parkraumanalyse komplett mit generischen Daten zu machen. Beispielsweise 11m oder 15m Breite je nach Straßentyp anzunehmen. Aber: Wenn man das in einer hochaufgelösten Karte mit “echten” Fahrbahnflächen darstellt, stehen die Autos natürlich irgendwo chaotisch mitten auf der Straße oder halb auf dem Bordstein. Damit gehen visuelle Informationen wie die genaue Position der Autos, z.B. beim Parken auf (on_kerb) oder halb (half_on_kerb) auf dem Bordstein, verloren. Deswegen habe ich mir die Arbeit gemacht, die erzeugten Linienelemente an die Bordsteine zu snappen. Mit QGIS kann ich die Parkspuren über eine Snapfunktion an die nächstgelegene Bordsteinkante legen. Das funktioniert in den meisten Fällen sehr gut – und die Fehler und Sonderfälle musste ich manuell nachbearbeiten. Trotz dieser Hilfe von QGIS habe ich an diesem Feature bestimmt anderthalb Tage gesessen und stundenlang alles nachbearbeitet und geprüft. Ich könnte mir aber gut vorstellen, dass es für eine reine systemische Parkraumanalyse – bei der die Visualisierung nicht im Vordergrund steht – absolut ausreichend ist, solche Details wegzulassen.

Wie die Karte technisch generiert wird

Tobias: Wir haben eben schon kurz über die Technik gesprochen, die du zum generieren der Karte verwendest. Bitte fass uns nochmal zusammen, welche Schritte du durchläufst.

Alex: Ich muss gestehen, dass es technisch, glaube ich, relativ unausgereift ist, weil ich kein GIS-Profi bin, sondern im Prinzip mit der Parkraumanalyse in dieses ganze GIS-Umfeld reingewachsen bin. Deswegen ist das alles so nicht besonders elegant oder teils auch händisch gelöst – aber es funktioniert :-). Der erste Bestandteil ist der handkuratierte Bordstein-Layer, über den wir schon gesprochen haben. Dann hole ich mir zur Zeit noch über Overpass die aktuellsten OSM-Daten. Das müsste man eigentlich dringend auf eine PostGIS-Datenbank mit dem aktuellen OSM-Extract umstellen. Einzelne dieser Daten laufen dann durch ein Post-Processing-Script, um sie für die Karte aufzubereiten. Dazu gehören beispielsweise die Ausrichtung von Gehwegübergängen oder Zebrastreifen oder die Haltelinien. Dieses Script ermittelt beispielsweise den Winkel, in dem ich einen Zebrastreifen darstellen muss anhand des Straßenverlaufs. Ein weiteres Detail ist, dass ich Hausnummern etwas versetzen muss, damit sie gut lesbar bleiben. Oder ein Filter, der bestimmte building:part einschließt und weniger relevante verwirft. Daraus entstehen in QGIS jede Menge Layer von allen möglichen Objekten, die ich zur Anzeige des Kartenstils in QGIS verwende. Zum Schluss exportiere ich aus QGIS die Kartenkacheln und lade sie manuell auf meinen Server. Ich wäre sehr daran interessiert, das ganze stärker zu automatisieren …

Ein Kartenstil für ganz Deutschland?

Tobias: Das beantwortet auch meine nächste Frage, ob wir diesen Stil für ganz Berlin, Deutschland oder die Welt generieren können … – Nein, weil die Karte von Details lebt, die man so nicht mal eben aus OpenStreetMap rausziehen kann.

Alex: Genau. Erstens das, also es lebt von diesem hohen Mikromapping-Grad, den wir in Neukölln haben. Wir haben ja eine super aktive Community, die auch dank der externen Daten, die wir in Berlin haben, einen super Datensatz produziert hat. Aber es lebt eben auch von den Bordsteinkanten, die man erstmal erzeugen müsste. Für Berlin ist das vielleicht noch möglich, wenn man sich da mal eine Weile ransetzt … aber für Deutschland geht es das erstmal nicht.

Wunsch an Mapper*innen: Mikro-Mapping

Tobias: Zum Abschluss: Was wäre dein Wunsch an Mapper*innen? Was wünschst du dir für diese Karte; was soll noch erfasst werden?

Alex: Ich kann nur grundsätzlich zum Mikro-Mapping aufrufen. Damit meine ich jetzt nicht unbedingt, dass man seine Zeit damit verbringt, jede kleine Hecke zu kartieren, sondern auch die Tiefe der Daten an bestehenden Objekten erhöht. Zum Beispiel bei einer Sitzbank – da machen das die meisten auch – die Rücklehne und Ausrichtung mit erfassen. Das sind Dinge, die man auch in so einer Karte visualisieren kann – mal abgesehen davon, dass diese Informationen für einige Menschen natürlich einen ganz praktischen Nutzen haben können. Weitere Details, die sich gut visualisieren lassen, sind alle Objekte im Straßenraum wie Straßenlaternen, Fahrradständer, Poller, Schaltkästen…, aber auch Spielplatzgeräte oder eben Bäume mit ihrem Kronendurchmesser.

Tobias: Herzlichen Dank, Alex, für diese Einblicke und diesen sehr schönen und nützlichen Kartenstil.

Alex: Gerne.

Update

Es hat jetzt leider einige Monaten geduert, bis dieses Interview veröffentlicht wurde. Seit dem ist noch einiges passiert in der Straßenraumkarte. Hier ein Ausschnitt an Features, die jetzt ebenfalls visualisiert werden:

  • (Beta) Markierte Gehwegübergänge (Zebrastreifen, Ampelkreuzungen) sowie Haltelinien an Ampeln und Stoppschildern Beispiel
  • Querungsstellen mit randseitiger Schutz-Markierung und Sperrzonen auf der Fahrbahn sicht sichtbar Beispiel
  • Separat gemappte Gehwege werden als halbtransparente Linie dargestellt Beispiel
  • Schwebende Gebäudeteile/Gebäudegrundflächen ergänzen die bestehenden Gebäude-Geometrien Beispiel
  • Einzeln erfasste Parkplätze inkl. barrierefreien Stellplätzen werden dargestellt Beispiel

Weitere Features sind angedacht, wie Straßen- und Abbiegespurmarkierungen oder eine bessere Visualisierung von Radwegen, insbesondere geschützten Radwegen.

Location: Neukölln, Berlin, Deutschland

Ein Interview von Tobias @tordans mit Alex @Supaplex030.

Tobias: Hallo Alex, du arbeitest gerade an einem spannenden Projekt an der Schnittstelle von OSM und der Verkehrswende in Berlin, nämlich einer Parkraumanalyse für den Ortsteil Neukölln. Das ist sehr vielfältig – heute wollen wir uns ein Detail anschauen, bei dem es um OpenData und OpenStreetMap und die Verbindung von verschiedenen Datenquellen geht.

Anzahl angemeldeter Autos pro Haus

Eine Zielsetzung dabei ist, herauszufinden wie viele Autos in einem Häuserblock angemeldet sind. Dafür gibt es keine direkten Daten, aber es gibt Daten über die man Näherungswerte schaffen kann mit Hilfe von anderen OpenData-Quellen und OSM. Und diese Daten hast du dann später in der Auswertung verwendet, über die wir auch noch mal an anderer Stelle sprechen: Eine Karte, in der visualisiert wird, wie viele Parkplätze pro Auto es im Umkreis eines Ortes gibt: https://supaplexosm.github.io/strassenraumkarte-neukoelln/?map=parkingmap

Die Karte zeigt anhand der Daten, die wir hier besprechen, wie hoch der “Parkdruck” pro Fläche sein müsste, wenn man alle verfügbaren Parkplätze darstellt und die Autos der Anwohner einrechnet. Quelle Screenshot

Alex: Genau, ich habe eine Stellplatzdichte-Verteilung ermittelt. Wie du schon sagst: Dafür habe ich verschiedene Daten verwendet, die auf verschiedenen räumlichen Ebenen vorliegen. Einmal die von dir angesprochenen Kfz-Daten, die habe ich auf Anfrage vom Amt für Statistik Berlin-Brandenburg auf LOR-Ebene bekommen, da es leider keine aktuelle Veröffentlichung dazu gab. LOR steht in Berlin für “Lebensweltlich orientierte Räume”. LOR sind im Prinzip Kieze, also kleine Stadtviertel, da wohnen ungefähr 10.000 bis 20.000 Menschen pro LOR. Das ist – glaube ich – die kleinste Einheit, auf der man die Daten mal eben bekommen kann.

LOR-Daten zu Kfz-Anmeldungen

Tobias: Wie sehen die LOR-Daten aus, die uns zur Verfügung stehen?

Alex: Neben dem LOR-Namen, beispielweise “Schillerkiez”, enthalten die Daten verschiedene demografische Werte wie die Anzahl der Erwachsenen im Kiez und verschiedene Kfz-Zahlen. Vor allem die Gesamtzahl der zugelassenen Fahrzeuge, unterteilt in Pkw und sonstige Fahrzeuge – also gewerbliche Laster, Kleintransporter, Motorräder und ähnliches. Die Pkw machen ca. 80 Prozent aus, die sonstigen Fahrzeuge teilen sich zum größten Teil etwa gleich auf Kleintransporter und Motorräder auf. Nicht enthalten ist eine Unterscheidung in private und gewerblich genutzte Fahrzeuge, aber das brauche ich auch für meine Auswertung nicht, denn ich beziehe ja auch gewerblich genutzte Parkplätze mit ein. Die Daten sind übrigens von Juni 2020.

Zu den Daten: Melderechtlich registrierte Einwohnerinnen und Einwohner am Ort der Hauptwohnung in Berlin am 30.06.2020 nach Planungsräumen und KfZ-Bestand

Daten vom LOR auf einzelne Gebäude runterbrechen

Tobias: Wie hast du dann die Präzision der Daten vom Kiez auf Haus-Ebene erhöht?

Punktewolke zeigt Bewohner pro Haus – statistisch gesehen. Quelle OpenStreetMap Wiki

Alex: Richtig, wir starten zunächst groß auf Kiez-Ebene, für die wir die Kfz-Daten haben. Eine Ebene darunter gibt es – zumindest in Berlin – OpenData der Häuser-Block-Flächen. Sozusagen die Bereiche zwischen den Straßen, auf denen Häuser stehen. Zu diesen Blöcken gibt es Bevölkerungsdaten, die mir pro Block sagen, wie viele Menschen auf dieser Fläche wohnen. Aber das ist immer noch nicht klein genug für meine Auswertung, denn das ist immer noch ein großer Block mit vielen Häusern, dazwischen auch unbewohnte Gebiete wie z.B. Kleingärten. Dank OSM und anderen OpenData-Datensätzen in Berlin habe ich aber Informationen über die einzelnen Gebäude im Block. Über diesen Weg kann ich die Daten von den Blockflächen nochmal runterrechnen auf die einzelnen Gebäude. Dabei ist die Grundidee, dass man die statistisch gemeldeten Personen in einem Block auf die Gebäude verteilt, und zwar entsprechend ihrer Wohnfläche. Für jedes Gebäude kann ich anhand seiner Funktion, z.B. “Wohngebäude”, “Gewerbegebäude” oder eine Mischnutzung, und anhand seiner Stockwerkszahl ermitteln, wie viele Bewohner dort statistisch zu erwarten sind. Das ist also keine tatsächliche Zahl, die ich da vom Kingelschild abgelesen habe, sondern ich interpoliere das anhand der Gebäudedaten, die wir haben. Das gewünschte Ergebnis ist, dass ich für jeden Menschen im Gebäude einen Punkt habe. Und das entspricht mit einer relativ hohen Wahrscheinlichkeit dann der tatsächlichen Bevölkerungsdichte im Berliner Stadtraum.

Von den Menschen zu den Autos

Alex: Dieses Bevölkerungsmodell können wir jetzt nehmen und mit den Daten zu den angemeldeten Kfz kombinieren. Wenn ich weiß, wie viele Autos in einem Gebiet angemeldet sind, kann ich für jeden Menschen, also Punkt in unser Karte, angeben, mit welcher Wahrscheinlichkeit dieser Mensch ein Auto besitzt. Ich ordne jedem Menschen eine Zufallszahl von 1-100 zu und bei einer angenommenen Auto-Besitz-Quote von 20 Prozent ist dann jeder fünfte Punkt – statistisch gesehen – ein Autobesitzer.

Exkurs: Mit dieser Herangehensweise könnte man noch viele andere, spannende Auswertungen von demografischen Daten machen, vielleicht auch noch eine genauere Zuordnung. Beispielsweise gibt es Zensusdaten von 2011 im 100-Meter-Raster.

Tobias: Jetzt schauen wir gemeinsam das Ergebnis an: Auf einer OSM-Karte sehen wir Gebäude und Punkte. Dahinter steckt die Umrechnung vom Kiez auf den Häuserblock, dann auf das Gebäude unter der Berücksichtigung einer Wahrscheinlichkeit anhand der Stockwerkzahl, Grundfläche und Funktion des Gebäudes. Also eine Karte der Bevölkerungsdichte, bei der jeder Mensch mit einem statistischen Punkt repräsentiert wird.

OpenData in Berlin: ALKIS

Tobias: Welche Rolle spielten bei der Auswertung OpenData-Quellen des Berliner Senats?

Alex: Alles, was ich gemacht habe, wäre theoretisch mit OSM-Daten möglich gewesen. Aber da vor allem die Gebäudedetails in OSM nicht überall erfasst sind, habe ich für meine Auswertung Daten aus dem ALKIS der Stadt verwendet (Anmerkung: ALKIS: Amtliches Liegenschaftskatasterinformationssystem).

Für die Auswertung sind drei Faktoren entscheidend: Die Stockwerkzahl, die Funktion und die Grundfläche des Gebäudes.

In OSM – gerade in Neukölln – haben wir die Stockwerkzahl schon ziemlich gut erfasst. Auch die Grundfläche ist – auch hier dank der OpenData des Senats – sehr präzise erfasst. Aber gerade bei der Funktion erschienen mir die ALKIS-Daten vollständiger.

Ich habe daher die ALKIS-Daten als Basis genommen und an den Orten, von denen ich wusste, dass die OSM-Daten aktueller sind, die OSM-Grundrisse übernommen. Insbesondere bei Neubauten. Das ist nur möglich, weil die Daten in einer offenen Lizenz – auch OSM-kompatibel – vorliegen.

Datenquelle: ALKIS Berlin (Amtliches Liegenschaftskatasterinformationssystem)

Tobias: Welche Auswirkung hatte die Funktion eines Gebäudes für deine Auswertung?

Alex: Ich habe für die Berechnung nur Wohnflächen berücksichtigt. Auf der Karte sind daher überall dort Lücken, wo bspw, Kirchen, Schulen, etc. als Gebäudefunktion angegeben sind. Ebenso werden Hinterhöfe, Garagen, Gewerbegebäude, Kleingärten usw. ausgeschlossen. Bei reinen Wohngebäuden habe ich alle Obergeschosse des Gebäudes bei der Wohnfläche berücksichtigt. Bei der Kategorie “Wohngebäude mit Gewerbenutzung”, bei der typischerweise das Erdgeschoss gewerblich genutzt wird, habe ich entsprechend ein Stockwerk abgezogen. Bei der Kategorie “Gewerbegebäude mit Wohnnutzung” ist unklarer, wie viel davon bewohnt wird. Ich habe dann die Hälfte des Gebäudes angerechnet. Das war glücklicherweise nur ein kleiner Teil der Daten. Andere Kategorien, die eindeutig nicht als Wohnraum gedacht sind, habe ich ausgeschlossen.

Einen Teil der Kfz-Daten habe ich übrigens auf alle Gebäude verteilt, und nicht nur auf die Wohngebäude bzw. die Bewohner-Punkte, denn vor allem gewerblich angemeldete Fahrzeuge können ja auch einem unbewohnten Gebäude zugeordnet sein.

QGIS

Tobias: Mit welcher Software hast du gearbeitet?

Alex: Ich habe alles mit QGIS gemacht. QGIS ist ein Geoinformationssystem – Open Source und frei. Da habe ich die Block- und Gebäudedaten aus ALKIS und OSM eingeladen, verarbeitet und die Bevölkerungswerte daraus berechnet. Als Ergebnis bekomme ich dann eine Zahl pro Gebäude, wie viele Menschen hier statistisch zu erwarten sind. Am Ende kann man zufällig genau so viele Punkte über das Haus verteilen wie Menschen dort wohnen, um die Daten sozusagen auf die individuelle Ebene zu bringen.

Wohnen im Kleingarten oder Industriegebiet

Tobias: Was haben wir bisher vergessen?

Alex: Ein interessantes Detail ist, dass ich in einem Kontrollschritt festgestellt habe, dass ich 450 Menschen weniger hatte als tatsächlich in Neukölln leben. Dann ist mir aufgefallen, dass es Häuserblöcke gibt, in denen ich keine Wohngebäude identifiziert und berücksichtigt habe, aber wo tatsächlich Menschen gemeldet sind. Beispielsweise ein einem Kleingartenareal, wo ich erstmal keine Bevölkerung angenommen habe, da man dort meines Wissen nicht wohnen darf. Aber vermutlich haben einige Bewohner dort Bestandsschutz, so dass doch Menschen gemeldet sind. Die fehlenden Personen habe ich dann auf alle Gebäude verteilt.

Tobias: Vielen Dank, Alex, für diese interessanten Einblicke!

In einem nächsten Interview schauen wir auf ein Nebenprodukt deiner Auswertung, die Straßenraumkarte für Neukölln mit einem Schwerpunkt auf Micromapping und Karten-Rendering. Und beides zusammen kann man sich auch schon jetzt anschauen unter https://supaplexosm.github.io/strassenraumkarte-neukoelln/?map=parkingmap#15/52.4772/13.4393.

Location: Neukölln, Berlin, Deutschland

A year ago I started doing a lot of walking and cycling with my stroller. Naturally, I had to look for new ways to contribute to OSM. More on the go mapping – thank you GoMap! – and more passive contributions by providing street level images.

With this post, I want to share my prototype of a bike tripod to take great Mapillary images.

It looks like this:

Picture

Goals of my tripod prototype:

Goal 1: Elevation – Take pictures from as high up as possible

My goal is to create images that allow to map bicycle and pedestrian infrastructure. For Berlin, this requires the pictures to be taken either on the sidewalk itself or from high above on the lane. Otherwise, all you see are parked cars.

Goal 2: Field of view – Look ahead with privacy in mind

No 360°

From a mappers point of view 360° images are perfect. Which is also why Edoardo from Mapillary promoted the recently in https://blog.mapillary.com/update/2020/10/29/the-camera-landscape-2020.html. However, from a privacy point of the of the person taking the pictures, they are not an option for me. I don’t want to be in every picture myself, nor do I want the person next to me be there or my stroller. Mapillary’s face blurring is not enough to solve my privacy concerns; it would need a full body or area blur for that.

No facing backwards

A similar issues arises when facing the camera backwards. It would open up new possibilities to mount the cam; but it also means that potentially someones face and posture is stuck on each pictures, which I don’t want for anyone.

No helmet mount

Having the action cam glued to my helmet looked like a solution at first. But I never even used it as a prototype, since I want to be able to move my head freely without messing up the images or having privacy issues (see above).

My solution

This is why I decided to work with a forward facing GoPro Hero 7 Black.

It was just 230 € in eBay Kleinanzeigen, which is an OK price IMO.

Goal 3: Easy to mount

I wanted the tripod to be easy to mount on my bike and my regular stroller and my bicycle trailer which can be used as a stroller.

Ideally with one hand. Ideally with multiple height-settings. Ideally adjustable while riding the bike.

Not all of this came to live in this prototype :-).

Right now I only have a solution for my bike, which is OK for now. However, for the bicycle trailer in stroller-mode I did some experimentation as well which you can see below.

The current prototype status

What the tripod looks like

I used an extension that attaches to the bicycle handlebar as a base.

My local bike shop welded a metal guide piece on which I use to screw the square tube on.

I can adjust the height in 5 steps. But in reality I find I either use the lowest or highest – at least for now.

Picture

Picture

Picture

Picture

What the images look like

Picture

https://www.mapillary.com/app/?lat=52.476031599972224&lng=13.4394168&z=17&tab=uploads&pKey=lVCc83RmuV7CRyTeJ6zJca&focus=photo&username%5B%5D=tordans&dateFrom=2020-10-01

I took a sequence of Mapillary images of a typical street in all 5 positions. Starting at the handlebar mount and going up to the highest position on the tripod.

I picked this street because it shows quite well why a high viewpoint is important, if you want to see more of the infrastructure than just parked cars.

Failed iterations of this prototype

I did a lot of quick experiments to guide me in the right direction. Here are a few of those experiments. Some worked, some failed.

Experiment with wooden tripod

What the images looked like:

https://www.mapillary.com/app/user/tordans?lat=52.47137549999999&lng=13.451687799999945&z=17&tab=uploads&pKey=PUduyO4VUAOGGZi7vAVdcm&focus=photo

What the experiment looked like:

Picture

My take: Using the handlebar as a mount does work but the camera needs to be mounted higher.

Experiment: mounted to the luggage rack

What the experiment looked like:

Picture

What the images looked like:

Picture

My take: Good height, but bad field of view.

Experiment: mounted at the center of my handlepar

What the experiment looked like:

Picture

What the images look like:

Picture

https://www.mapillary.com/app/?lat=52.470781299972224&lng=13.444283699972223&z=17.161390534381525&focus=photo&tab=uploads&pKey=RoPocSkaob9W3z0ZmcCZuC

My take: The images are good but the mounting point is really bad. Its basically right in your face :-D. It is also more static than mounting the camera on the handlebar.

Experiment: mounted to the bicycle trailer

What the experiment looked like:

Picture

What the images look like:

Basically all images in Brandenburg an der Havel use this setup :-) https://www.mapillary.com/app/?lat=52.41002186112698&lng=12.560155037356026&z=15.042866673831352&focus=map&username%5B%5D=tordans

My take: Very easy to “build” and takes good pictures. The height is quite good for this mode of transport as well. I would have to improve the camera angle, however, so I may get full 5 quality score points (https://blog.mapillary.com/update/2020/11/05/introducing-the-quality-score.html) :-).

Assessment of this prototype

Great: Elevation (Goal 1) and Field of view (Goal 2). This turned out great. I really like how much I can see on the images. It makes mapping with those a lot easier. In most cases, it’s possible to see the sidewalk well enough to be used for mapping. It’s also easier to placing objects near the kerb on the map since context of the object to other objects is cleare

OK: Mounting (Goal 3). The mounting is OK, but the screws are not ideal. I would love to have a setup that allows to change the height with one hand more or less – ideally while moving. I like the construction detail (realised by a cable tie for now) that allows me keep the main “tube” in the guide piece without fixing the screws, yet.

Another improvement would be to be able to turn the field of view to the left/right. This would allow me to see just a bit more of the sidewalk and house entries whenever I take pictures from both sides of a street. That would make working with those images for mapping even easier.

Great: GPS. I am really pleased with the quality of GPS. It’s a lot better than that of my iPhone. A small disadvantage is, that it takes a while to connect. I need to remember not to start moving right away but wait a bit. Otherwise the images will have no GPS at all (not even a bad GPS) and the uploader will show an error and ignore the image.

I also noticed missing GPS below bridges which results in no images being uploaded. Which reminds me, that a while ago I suggested to add an interpolation feature for those cases (https://forum.mapillary.com/t/feature-request-continue-creating-pictures-even-if-gps-is-red/2805).

To test the quality of the GPS, the Deriviste app https://osm.cycle.travel/deriviste/ is a good indicator. In this test, it places the tree nearly at the right position. Which is a lot better than what I experienced in 2018 when I experimented with pictures taken from my iPhone (see https://github.com/mapillary/mapillary-js/issues/272).

Picture

Great: Vibration protection. I was really pleased with the vibration protection of the GoPro. We have a lot of cobblestone in my hood and the high mount makes vibrations an even bigger issue. However, looking at my images there are only a few that are blurry, which is great.

Speaking of cobblestone: I do, however, need to remember to really tighten the screws well. Especially in winter when the cold seems to make the plastic less forgiving. One session ended up looking like this for a few streets.

Picture

Problem: Height. The height is great. But I really need to pay attention to objects in front of me. Once a tree branch knocked my cam from the pole. And quite a few times I had to dodge traffic signs which protrude over the bike line (to make the car lane free ob object, of course). I some cases, I need to stop and adjust the height, which is annoying but OK. I will need to keep the bicycle handlebar extension a bit loose if I hit an object the whole think will gracefully bend and not break.

A few examples:

Annoying: No hand off cycling. With the new setup, the weight distribution does not allow to cycle hand free anymore.

OK: Uploading images. In my current setup I take a batch of pictures and have to review them manually at home before uploading. Especially, to remove those pics that show me mounting the cam and my house. But also to remove images of roads that I already uploaded – I don’t want to kill any more trees by uploading masses data if I can help it.

For apple users, I recommend to use the gallery-view in finder, not the preview. Its a faster by a lot so you can speed through images and shift-delete those that need to go. I then use the Mapillary desktop uploader to get the images online, which is a great tool for this job.

Annoying: Keeping track of what’s still to capture. I needed a super quick way to plan a route once I have a chance to get out with my setup. The Mapillary viewer with active filters felt too slow for this (and my devices are not that old …). Right now I manually document where I went whenever I check the images for upload. I use a uMap for this: https://umap.openstreetmap.de/de/map/mapillary-hohes-stativ_7207#14/52.4762/13.44

Annoying: Transfering images. Apparently the GoPro (or Apple?) does not allow to just connect the cam and copy images. I need to remove the card and plug it in manually. This is OK, but annoying.

Annoying: Hard to double check of the camera is running. I find myself wondering if the GoPro is running again and again. But thanks to the great height of the tripod, I would need to unscrew it all to check. Or to park the bike and climb up a bike stand. Both is pretty annoying. The GoPro App might be of help but I tested it once and it stopped the recording which I did not notice and thus lost images. I will need to tripple check the settings before mounting the camera, for now.

Annoying: Wrong direction arrows in Mapillary. ATM, Mapillary shows the wrong direction arrows on GoPro images. This is quite annoying when using the images in iD. Maybe one day there can be a choise in the uploader saying “Camera mounted in direction of travel” (or “to the left” …), so the processor can set and adjust the camery angle.

The cost of it

So what did this project cost?

  • GoPro Hero 7 Black – 230 € (second hand)

  • Square pole and U-Shaped pole-“wrapper” and screws – I think those were about 30 € in total at the hardware store

  • bicycle handlebar extension and welding – about 20-25 €

  • a bit of tape and cable ties

Next steps:

For now, I am done. The prototype works well enough to use it. I will need to replace some tape and cable ties with more permanent solutions at some point, but there is no hurry. I switched my focus on collecting images now.

Location: Neukölln, Berlin, Germany