Ich habe kürzlich frustriert festgestellt, dass Mecklenburg Vorpommern seine Luftbilder immer noch nicht frei (für OSM) zur Verfügung stellt. Das macht die Arbeit für dedizierte OSM Projekte wie den Radverkehrsatlas unnötig schwierig.

Jetzt frage ich mich: Wie ist das eigentlich in anderen deutschen Bundesländern?

• Sind die Luftbilder + Alkis öffentlich? Und für OSM nutzbar?
• Welche Lösung wurde für die Freigabe in OSM gewählt? In Berlin beispielweise gibt es dafür einen Brief, in Brandenburg eine Angabe in der AGB.

Ich habe eine Liste erstellt unter https://wiki.openstreetmap.org/wiki/DE:Luftbilder#%C3%9Cbersicht_Bundesl%C3%A4nder

Bitte helft mit, und tragt mit eurem lokalen Wissen ein, wie die Situation in eurem Bundesland ist.

---

Was machen wir mit diese Liste? Erstmal interessiert mich, wie der Stand der Dinge ist.

Es ist außerdem sehr hilfreich, die unterschiedlichen Lösungen für die Lizenzfreigabe aufzuführen als Inspiration für die Personen, die so eine Freigabe erteilen müssen.

Aber interessanter ist dann im Anschluss die Frage, wie man die jeweiligen Bundesländer (erneut) anspricht, um sie zu einer Freigabe der Daten zu bewegen…

Image Source: Jake Coppinger

Companies like Mapillary and Kartaview have played a significant role in advancing OpenStreetMap (OSM) and enabling detailed mapping efforts, particularly in urban areas. While 360° street-level images have been crucial for capturing high-quality data, there is a growing need for a scalable solution that leverages the power of aerial imagery to further enhance community mapping. In this blog post, we delve into the potential of aerial imaging and its implications for OSM mapping. Interestingly, emerging companies in the 360° imagery space, such as Mapillio (Commercial) and GeoViso (Open Source), may view this as an opportunity to add a unique selling point to their portfolio. The process of generating detailed aerial-like imagery for specific smaller areas not only benefits OSM mapping but also proves highly valuable for city planners involved in intersection redesigns or the addition of bike paths to streets.

The Power of Mapillary and Street-Level Mapping and the Need for Aarial Imagery

Mapillary, in particular, has been crucial for mapping efforts in cities. It allows the mapping of intricate details on sidewalks and bike lanes, empowering communities to collect data and map it later. Unlike professional street-level projects that primarily rely on car-based perspectives, Mapillary enables data collection from the viewpoint of pedestrians and cyclists. This perspective is essential in cities with numerous parked cars, as it offers better visibility of sidewalks.

However, despite the benefits of 360° images, placing objects accurately on the map remains a challenging and manual process. Mappers often rely on guesswork and visual alignment with other objects, making it time-consuming and prone to errors. This is where aerial images shine, as they simplify the process by allowing mappers to place objects directly on the image, eliminating the need for guesswork and enhancing accuracy.

Classic Aerial Images Are Great, but Imagine Creating Them Yourself

In Berlin, Germany, we are fortunate to have access to fresh aerial images every year, which greatly aids our OSM mapping efforts. You can check out an overview of these images here. This valuable resource allows us to create accurate and highly detailed maps of the city and its streets. However, many places around the world lack this kind of readily available data. Even in Berlin, there are streets that are constantly shrouded in shadows or obscured by angles, building shadows, and tree cover, making it challenging to accurately map the street space.

When it comes to mapping intersections in intricate detail, incorporating 360° images and local knowledge becomes essential to create a comprehensive map. However, this process can be time-consuming and reliant on on-site visits or contributions from local community members.

This is where the potential of self-created aerial imagery becomes truly exciting. Not only would it offer high accuracy in mapping, but it would also open up possibilities for remote mapping in areas where it was previously impossible. By generating aerial images on our own, we can overcome the limitations imposed by the availability and quality of existing aerial imagery, enabling us to map with precision and detail from anywhere in the world.

Drones: A Complex Solution

Traditionally, the community relied on drones to collect aerial images. However, drone operation is expensive, complex, and often requires permissions and road closures in urban areas. The high cost and logistical challenges associated with drones make them less accessible for community mapping purposes.

A Scalable Solution: Generating Aerial Imagery from 360° Images

A scalable solution that leverages existing 360° images or point clouds to generate aerial imagery would revolutionize community mapping. This approach offers several advantages, including lower costs compared to drones and greater accessibility, as 360° cameras are more affordable and can be used by almost anyone, anywhere. This makes it an ideal choice for mapping in low-income areas. It’s worth noting that Humanitarian OpenStreetMap Team (HOT) should be particularly interested in this type of processing, given its potential impact.

The Ideal Workflow: Uploading, Processing, and Geo-Referencing

In an ideal scenario, a website would facilitate the upload of 360° images, handle the processing, and provide tools for easy geo-referencing. Ideally, the geo-referencing process should be automated, with an option to make manual adjustments if needed. The end result would be a flat image that serves as a basemap for mapping purposes in tools like iD and JOSM.

Proof of Concept: Aerial Imaging with 360° Images

A proof of concept by Jake Coppinger demonstrated the feasibility of creating aerial imagery based on 360° camera footage. In his blog post, he outlined the technical steps involved in generating such imagery. Although the proof of concept showcases the potential, the current complexity of the process hinders immediate implementation. However, if a project dedicated to processing 360° images were to integrate this workflow, it could offer a seamless experience for contributors worldwide.

Image Source: Jake Coppinger

Lidar: An Even More Promising Technique?

While 360° images have shown promise, Lidar technology presents an even more compelling option. With modern phones equipped with Lidar sensors, such as the iPhone 12 Pro (2020) and iPhone 13 Pro (2021), one can skip a step in the processing pipeline. Again, Jake Coppinger documented a proof of concept in his blog post, showcasing the generation of aerial imagery using an iPhone’s Lidar sensor. However, several challenges, including device availability and issues in the Open Source Ecosystem, need to be addressed to make this process more accessible. Additionally, platforms like OpenAerialMap need further development to support this type of data. Nevertheless, integrating Lidar processing into existing 360° image platforms could streamline the workflow for contributors.

Image Source: Jake Coppinger

Evaluating 360° Images vs. Lidar

Ideally, processing pipelines should be compatible with both 360° images and Lidar data. Further experimentation and testing are required to evaluate which technique works best in different scenarios. Lidar offers the advantage of skipping a step in the process but has limitations in terms of device availability. On the other hand, 360° images are well-established and provide additional street-level information, but determining the optimal number of images for generating high-quality aerial imagery requires more investigation.

Exploring Future Possibilities

While Mapillary has experimented in this area, it is uncertain whether they will introduce a feature for aerial imaging in the near future. However, other players like Mapillio and GeoViso could potentially embrace this feature, differentiating themselves from existing platforms. For now, this blog post aims to inspire further experimentation in the field of aerial imaging for detailed OSM mapping. Share your findings and contribute to the advancement of community mapping efforts!

---

PS: ChatGPT assisted in writing this blog post. I initially created a hierarchical outline of rough notes, not focusing too much on grammar or typos. I then inputted this into ChatGPT to generate a first draft, which required some paragraph-by-paragraph adjustments. I used ChatGPT once again to fix any typos and grammar issues. You can read the whole Chat that created this post. Overall, it was a helpful process. While the tone of this post may not entirely reflect my own, the information is presented more effectively than I could have managed given the limited time I have available for writing such a post. — Update: It turns out, ChatGPT does not know how to type aerial imagery but instead applied a typo I had in my input notes.

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.

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.

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.

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:

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.

What the images look like

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.

• For comparison: GoPro mounted on my bicycle handlebars (Level 0) https://www.mapillary.com/app/user/tordans?lat=52.47692159997222&lng=13.4447665&z=17&tab=uploads&pKey=9tK7DQ5rXNF5CkPH1qgI6n&focus=photo
• Tripod Level 5 (Default, ~2,4m) https://www.mapillary.com/app/user/tordans?lat=52.4769203&lng=13.444762&z=17&tab=uploads&pKey=Vs3abhonNJqDXo1CfizINK&focus=photo
• Tripod Level 4 https://www.mapillary.com/app/user/tordans?lat=52.4769304&lng=13.444738499972223&z=17&tab=uploads&pKey=hQQgqgjx5S5JlSZBAMGGTR&focus=photo
• Tripod Level 3 https://www.mapillary.com/app/user/tordans?lat=52.4769123&lng=13.4447457&z=17&tab=uploads&pKey=HSM6qmWt4kMdWjTdPPMIJd&focus=photo
• Tripod Level 2 https://www.mapillary.com/app/user/tordans?lat=52.4769249&lng=13.444742599972223&z=17&tab=uploads&pKey=UnKymrNKs0Lry5JftLwoF9&focus=photo
• Tripod Level 1 https://www.mapillary.com/app/user/tordans?lat=52.476934499972224&lng=13.4447737&z=17&tab=uploads&pKey=1r2Uaq2prGrqEzPLsWuQ3f&focus=photo

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:

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:

What the images looked like:

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

Experiment: mounted at the center of my handlepar

What the experiment looked like:

What the images look like:

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:

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).

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.

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:

• A branch of a tree knocked the camera off https://www.mapillary.com/app/user/tordans?lat=52.4876087&lng=13.4496161&z=17&dateFrom=2020-10-01&tab=uploads&pKey=8cgTp8poLxqn7fu2CmUAQx&username%5B%5D=tordans&focus=photo
• I had to duck below a garland which was placed across the sidewalk https://www.mapillary.com/app/user/tordans?lat=52.48905719997222&lng=13.440967099972223&z=16.197209520297907&dateFrom=2020-10-01&tab=uploads&pKey=795qT9dr75mYvhI7i3rq9M&username%5B%5D=tordans&focus=photo
• This construction area required me to adjust the height https://www.mapillary.com/app/user/tordans?lat=52.47997329997222&lng=13.419761499972221&z=17&tab=uploads&pKey=LbYQMNRD7VqwygJY5LvbdG&username%5B%5D=tordans&focus=photo&dateFrom=2020-05-01 
• Quite a few big traffic signs are place above the bike lane to keep the car lane free of obstacles. My camera’s batteries ran out on this tour but those are two examples https://www.mapillary.com/app/user/tordans?lat=52.45383035396454&lng=13.459542179492729&z=17&tab=uploads&pKey=j204YsGQDlc2fe3At5G4wY&focus=photo and https://www.mapillary.com/app/user/tordans?lat=52.46344311845536&lng=13.44415168896694&z=18.183127396588947&tab=uploads&pKey=57p7TKMcc9HEL5HCWq3ILg&focus=photo and also this traffic light https://www.mapillary.com/app/user/tordans?lat=52.46327776324699&lng=13.444240626693272&z=17&tab=uploads&pKey=9O9F-vkXRLZzGC_4qzBGhA&focus=photo 
• And there is advertising too, of course https://www.mapillary.com/app/?lat=52.4653428&lng=13.452523699999999&z=15.679263692765229&tab=uploads&pKey=isemqOysjkCNLjHfubnWpT&focus=photo&username%5B%5D=tordans&dateFrom=2020-12-01

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.