Verkehrswende-Meetup/Ideenliste-Analysen

From OpenStreetMap Wiki
Jump to navigation Jump to search

Ziel dieser Seite

Eine offene Sammlung an Ideen für Analysen und Projekte im Bereiche Verkehrswende <> OSM.

Kopfsteinpflaster-Straßen im Radverkehrsnetz als Kandidaten für Schleif-Technik

Problem:

Wir haben viel Kopfsteinpflaster in Berlin. Dort, wo Radverkehr auf der Straße geführt ist, stört der besonders. Es gibt Versuche, mit Schleifmaschienen das Pflaster zu schleifen. Das ist schneller und billiger als andere Lösungen.

Links zur Schleif-Technik:

Ziel:

Eine Analyse die die Straßen in Berlin zeigt, die gute Kandidaten für diese Schleif-Technik wären. Kandidaten sind vor allem Wege im Radverkehrsnetz des Senats, denn dort gibt es einen gewissen Druck aktiv zu werden.

In TILDA Radverkehr kann man sich die relevanten Daten einzeln anschauen: Schlechte Oberflächen von Straßen; Das Radverkehrsnetz. Wenn man den Radnetz-Layer an/abschaltet kann man sehen, wo solchen Kandidaten wären. Ein Beispiel ist dieser Abschnitt der Emser Straße.

Ideales Ergebnis:

  • Ein Prozess, der die relevanten OSM Daten nimmt … und die Daten des Senats zum Radnetz. Und diese Daten verschneidet, um Kandidaten zu ermitteln.
  • Diese Daten können wir dann auf osm-verkehrswende auf einer Unterseite darstellen, für die es einen Text braucht.

Straßenbegleitende Wege / Kanten-Knoten-Modell aus OSM / "Linienbündel"

Problem:

Ein ungelöstes Problem in OSM ist, wie man die getrennten Geometrien (Fußweg, Radweg, Centerline) wieder zusamemnführt für Routing-, Map-Matching- oder Prozessierungs-Arbeiten. Es gibt bereits verschiedene Ansätze dazu, aber noch kein Setup das sich gut ausrollen lässt auf Deutschland oder in ein osm2pgsql-Workflow integrieren lässt.

Ziel:

Eine skalierbare Lösung, die getrennte Geometrien aus OSM zusammenführt.

Weitere führende Links:

Komplexität: Sehr hoch

Straßenbegleitende Wege in Postgis erkennen

Problem:

Wir wollen das Projekt https://www.osm-verkehrswende.org/cqi/ skalieren auf ganz Deutschland. Dafür muss die Prozessierung stark verbessert werden. Ideal wäre, wenn sie komplett auf ein osm2pgsql und SQL (PostGIS) Setup umgestellt werden könnte.

Siehe auch https://github.com/FixMyBerlin/atlas-app/issues/87

Was aktuell fehlt ist vor allem eine Lösung, um in SQL eine Information zu straßenbegleitenden Wegen abzuleiten.

Ziel:

  • Eine Lösung, um Straßenbegleitende Wege von separat geführten Wegen zu unterscheiden.
  • Es reicht eine Schätzung, es muss nicht super genau und super richtig sein.

Ansätze:

  • Im CQI macht Alex in Python mehrere Buffer um den Weg, prüft dann ob es eine Straße gibt und leitet daraus ein Attribut ab (Code ist auf Github)
  • Laurenz hat ein Setup exploriert das Buffer auf Straßen legt und abließt wie lang der Weg sich schneidet (Code ist AFAIK noch nicht veröffentlicht)

Ideals Ergebnis:

Komplexität: Mittel

Mapillary: Straßen, die seit <Datum> keine Fotos bekommen haben

Problem:

Wer Foto-Touren plant um für Mapillary eine gute Abdeckung mit aktuellen Fotos zu erreichen, hat zur Zeit wenige Tools um schnell die relevanten Wege zu finden. Aktuell geht es nur über die Mapillary Website mit eigenen Filtern und dann rein visuell.

Siehe auch https://github.com/osmberlin/mapillary-missing-streets/issues/1

Ziel:

  • Wir wollen es Radfahrer:innen, die Fotos für Mapillary machen einfacher machen (siehe auch Kameraverleih), die Straßen zu finden, die frische (oder überhaupt) Fotos brauchen.
  • Kampagnen wie auf radinfra.de sollen gefiltert werden können anhand der Angabe, ob sie frische 360° Fotos haben, so dass man sie von zu Hause bearbeiten kann

Ansätze:

Ideales Ergebnis:

  • Ein Tooling das wir auf einem Server laufen lassen können, das Mapillary Daten einmal die Woche aktualisiert und mit OSM Daten verschneidet um dann die OSM Geometrien mit der Information zu Mapillary zurück zu geben.
  • Diese Daten könnten in tilda-geo.de eingebaut werden, um sie dort für Radinfra- und Straßen-Daten als Vector tiles auszugeben

Komplexität: Mittel

Datenabgleich: Schulen aus OpenData mit OSM abgleichen

Problem:

Daten zu Schulen sind in OSM nicht qualitätsgesichert. Somit ist unklar, wie aktuell sie sind und wie vollständig. Für Datenanalysen bspw. für Rad- und Fußverkehrsplanung sind diese Daten aber sehr wichtig.

Ziel:

Ideales Ergebnis:

  • Etwas wie ein Jupyter Notebook das die Daten zieht, vergleich und den Ergebnis-Datensatz erzeugt

Komplexität: Gering

Abdeckung mit Fahrradständern im Vergleich zu Einwohnern

Problem:

Verwaltungen brauchen Daten über die sie herausfinden können, in welchen Wohngebieten mehr Fahrradständer nötig sind.

Ziel:

Ansätze:

  • Aktuell wissen wir, dass das ein Mitarbeiter in einem Bezirk in Berlin in QGIS für seinen Bezirk gebaut hat.

"Gradlinigkeit" von Radverkehrsanlagen (RVA) vs. Auto

Beobachtung:

Die Fahrbahn für Autos ist im Normalfall eine gerade "Linie" mit nur wenigen Kurven und Verschwenkungen.

Die Fahrbahn für Fahrräder dagegen weißt häufig Verschwenkungen auf, mit denen die RVA um Straßenpumpen, Bäume, Straßenlaternen, Schilder, … geführt wird oder aber um die RVA an Kreuzungen in Richtung Kreuzungsmitte (oder umgekehrt) zu lenken.

Ziel:

Eine Auswertung, die für ausgewählte Straßen (oder ganze Gebiete) zeigt, wie viele Verschwenkungen mehr/weniger die Infrastruktur des Radverkehrs gegenüber Autoverkehr aufweist. Auf dieser Basis können vielleicht außerdem analysiert werden, welche Auswirkungen auf die Reisegeschwindigkeit diese Verwenkungen haben. Bspw. "Jede Verschwenkung von mehr als 10° erfordert eine Verlangsamung auf ca. 15 km/h. Daraus ergibt sich …"

Voraussetzung:

Die RVA müssen separat in OSM erfasst sein und ihre Geometrie im Detail der Führung vor Ort entsprechen.

Geschwindigkeitsangaben an Straßen rund um Schulen und Kitas

Problem:

Rund um Schulen und Kitas gibt es rechtlich mehr Möglichkeiten Tempo 30 anzuordnen oder andere Maßnahmen zu ergreifen. Dafür fehlt der Zivilgesellschaft eine gute Datengrundlage.

Mehr siehe https://github.com/FixMyBerlin/radinfra.de/issues/3

Ziel:

  • Ein Tooling, dass die Daten auswertet, so dass wir auf osm-verkehrswende eine Seite dazu erstellen können mit Karte und Erklärung

Ideales Ergebnis:

  • Ein Jupyter Notebook das Daten produziert die wir als pmtiles ausliefern können und ein paar Statisitk-Daten / Listen
  • Oder eine Integration in die Prozessierung von https://github.com/FixMyBerlin/atlas-app, so dass es direkt auf radinfra.de verwendet werden kann als Datenquelle für Kampagnen und Visualisierung

Komplexität: Gering

Gehwegübergänge: Datenabgleich Straßenbefahrung 2014

Dieses Thema ist verschoben nach https://github.com/tordans/parkraum.osm-verkehrswende.org/issues/8

Gehwegübergänge: Analyse Distanz zum nächsten Übergang

Ziel:

Im Norden von Neukölln wurde in einem großen Gebiet ein detailliertes Fußwege-Netz erfasst mit Bürgersteig-Wegen und Querungen. Damit ist es möglich darzustellen, wie weit eine Fußgänger:in laufen muss, um eine Straße zu queren. Es ist außerdem möglich zu zeigen, das an T-Kreuzungen die Querungen häufig durch Parkspuren auf der Gegenseite erschwert sind. Eine Auswertung kann bspw. zeigen, wo der Fußverkehr weiter als 100m laufen muss bevor die nächste Querung kommt.

Beispiel:

Karte aus Neukölln mit Fußgängerübergängen. Rot sind fehlende Übergänge (blockiert durch parkende Autos), Gelb sind Einfahrten die, wenn sie gerade frei sind, als Übergang genutzt werden können. Grün ist geschützte Infrastruktur die einen Übergang (im Normalfall) ermöglicht. — Quelle: https://supaplexosm.github.io/strassenraumkarte-neukoelln/?map=micromap#18/52.47180/13.44448

Auswertung:

Verschiedene Ansätze sind denkbar.

Ausgabe & Verwendung:

Verschiedene Ansätze sind denkbar.

Ausblick:

Die Ergebnisse der Auswertung können für den Dialog mit Fußverkehrsplanern im Bezirk und Zivilgesellschaftlichen Gruppen genutzt werden.

Bestehende Arbeiten:

Retrieved from "https://wiki.openstreetmap.org/w/index.php?title=Verkehrswende-Meetup/Ideenliste-Analysen&oldid=2839479"