Lärmlayer?

Moin,

tldr: Gibt es einen Layer, der Verkehrslärm darstellt?

Der Router brouter kann wirklich viel und wird ständig besser, aber ein wichtiger offener Punkt bei der Planung längerer Radreisen ist immer noch die Vermeidung von vielbefahrenen Straßen. Dabei macht es für mich praktisch keinen Unterschied, ob ich direkt auf einem hw=secondary radle oder auf einem Weg, der nurch durch einen sehr schmalen Grünstreifen davon getrennt verläuft. Bei viel Auto-Verkehr und insbesondere bei Regen ist beides gleich nervig. Die Sicherheit ist zwar gefühlt besser, aber wenn man sich den Weg mit entgegenkommenden Radlern teilt, dann relativiert sich das schnell wieder. Mal ganz abgesehen davon, dass die Wege oft in einem schlechteren Zustand sind (Baumwurzeln) als die Straße daneben. Leider sind genau diese Wege oft Teil von route=bicycle Relationen und damit vermeintlich “prima zum Radeln”. Die Geschmäcker sind halt verschieden…

Leider macht es OSM mir (bzw. brouter) hier nicht leicht. Es gibt -zig Möglichkeiten, diese Wege zu taggen, aber ohne Betrachtung der Umgebung ist es einem Datenauswerter kaum möglich, den straßenbegleitenden Radweg von einem anderen, vielleicht durch einen Park oder an einem Fluß oder mitten durch den Wald verlaufenden Weg zu unterscheiden.

Die Analyse in brouter zeigt mir schon recht schön, wo ich längere Zeit auf einem hw=primary oder hw=secondary unterwegs wäre, aber bei hw=cycleway hilft nur der Zoom, um herauszufinden, ob man da in einem Park oder auf einer stillgelegten Bahnstrecke unterwegs ist oder eben doch neben einer Bundesstraße. Bei hw=path ist es noch schlimmer, das kann praktisch alles sein.

Als Lösung dieses Problems schwebt mir eine Anzeige des “vermuteten” Verkehrslärms vor. Die Schätzung ist aber bestimmt nicht so einfach. Relevant sind offensichtlich Straßen in der Nähe, aber auch das Höhenprofil, Schallschutzwände, Gebäude, Wald…

Hat schon mal jemand versucht, sowas anhand der OSM Daten zu berechnen? Gibt es andere Quellen?

Es gibt ganz viele amtliche Quellen mit Verkehrszählungen (DTV / DTVw) und auch “Lärmaktionspläne”.

In Hamburg gibt’s eine Lärmkarte (dl-de/by-2-0).

Mit genug Aufwand könnte man die Daten sicherlich für OSM aufbereiten.

Hatte über soetwas auch schonmal nachgedacht,
die öffentlich verfügbaren DTV-Werte ließen sich taggingtechnisch durchaus an den OSM-highways erfassen, müssten aber alle paar Jahre ein update erfahren, und sind an “Sondertagen” wie dem Wochenende nur bedingt aussagefähig.

Lärmkarten basieren heute i.d.R. per Rechenmodell auf solchen Werten.

Das funktioniert aber nicht immer gut, beispielsweise sitze ich gerade in einem lt. amtlicher Lärmkartierung durch Eisenbahnlärm belasteten Gebiet (vielbefahrene Strecke in der nähe), dank günstiger Topographie kommt davon aber real rein gar nix an.

Kuzum, alles nicht so einfach…

Selbst wenn wir “Lärmpläne” bekommen würden, dann ist das etwas künstliches berechnetes, daß sich häufig und je nach Rechenmodell ändert…
… aber das ist dann halt absolut unvereinbar mit “on the ground”. Dann könnten wir nämlich auch gleich die SRTM-Höhenlinien importieren…

PS: In Brouter benutze ich eh immer “Sicherste Route”. Das ist dann eigentlich ganz OK. Ganz im Gegensatz zu “Rennrad”.

Es gäbe da noch den Schlüssel class:bicycle - https://wiki.openstreetmap.org/wiki/DE:Key:class:bicycle
Den könnte man doch dazu anpassen / modifizieren / erweitern.

Der Schlüssel ist halt sehr subjektiv. Ein Rennradler achtet auf andere Dinge als ein Tourenradler oder ein Pendler oder ein Wochenend/Schönwetterfahrer. Die Entfernung zur nächsten stark befahrenen Straße liesse sich halt berechnen und als Schätzwert für den Verkehrslärm verwenden.
Für mich ist dann auch noch interessant, ob es dabei bergab oder -auf geht. Fahre ich mit dem Treckingrad und Gepäck einen Berg rauf, dann meide ich stark befahrene Straßen wie die Pest, da rumpel ich viel lieber irgendeinen Waldweg hoch. Umgekehrt, wenn es recht steil bergab geht. Da ist die Fahrt auf der gut ausgebauten Straße der größere Spaß, und Autos stören da auch nicht so, weil man ja in etwa gleich schnell ist.

nein, das wäre wohl kein zielführender Ansatz,
der wäre IMHO die in D flächendeckend behördlich erfasste Verkehrsstärke (in Hessen bis hinunter zu Kreisstraßen) an der Lärm-Quelle als einen Tag wie
DTV=16500
an diesem Straßenabschnitt in OSM zu übernehmen, dies sind nämlich potentiell hochinteressante Informationen in einer “StreetMap”-Datenbank.
Probleme:

  • Lizenz
  • manpower

Daraus könnte dann in einem 2. Schritt über die in OSM erfassten/bekannten Parameter
max_speed am Quell-highway und Abstand zum Ziel-highway die dortige Imission berechnet bzw. zumindest grob geschätzt werden.
Könnte…

Hier gibt es die diesbezüglichen Verkehrsmengen-Karten beispielsweise für Hessen zum reinschauen mit den DTV-Angaben (Durchschnittliche tägliche Verkehrsstärke)
https://mobil.hessen.de/%C3%BCber-uns/downloads-formulare/stra%C3%9Fenverkehrsz%C3%A4hlung-2015

Noch viel Spaß beim Radeln, aber beim Wandern meide ich die Umgebung vielbefahrener Straßen auch gern …

Vielleicht ist das dazu interessant:
http://k1z.blog.uni-heidelberg.de/2020/07/15/quiet-route-planning-for-pedestrians-in-traffic-noise-polluted-environments/

gefunden in https://blog.openstreetmap.de/blog/2020/07/wochennotiz-nr-522/

Na ja, letzlich wird man damit wohl häufiger auf hw=track oder hw=path geschickt. Bei > 8% Gefälle finde ich diese Wege aber bestimmt nicht sicherer als einen hw=secondary. Noch schlimmer ist aus meiner Sicht eine steile Gefällestrecke durch Tempo-30-Zonen. Da blutet mir das Herz, wenn all die potentielle Energie, die ich bergauf gesammelt habe, nicht mit einem Geschwindigkeitsrausch belohnt wird, sondern mit verschlissenen Bremsen bestraft.
Was ich bräuchte, wäre eine Mischung aus “Sicherste Route” wenn bergauf, “Rennrad” wenn bergab, sonst “Treckingrad” mit Häkchen bei “stick_to_cycleroutes”. Im Moment bastel ich da halt noch immer ein paar Tage lang rum bis ich zufrieden bin.

Falls jemand von brouter Entwicklern mitliest: In der Analyse werden ja, wenn ich z.B. den Mauszeiger auf “secondary” bewege, sehr schön die entsprechenden Streckenabschnitte gelb eingefärbt. Wäre toll, wenn das auch beim Höhenprofil passieren würde. Umgekehrt könnte man beim Bewegen des Mauszeigers im Höhenprofil nicht nur einen Marker auf der Strecke bewegen, sondern auch die jeweils passenden Einträge bei der Analyse markieren.

@Jo Cassel: Ich will damit nur sagen, daß ich einen Import in OSM für unrealistisch halte. Nicht mehr.

Ist aber auch nie im Gespräch gewesen. Es geht um die Erstellung eines Lärmlayers bzw. um die Möglichkeit, den Routern eine Datenbasis für die Berechnung des zu erwartenden Lärms auf einer beliebigen Straße zu geben. Für meinen Zweck würde schon die Betrachtung der Hauptstraßen (also secondary oder mehr) reichen. Die Links in #8 treffen es recht gut, wenn auch nur für Fußgänger

…hier mal eine kleine Übericht, was ich auf die Schnelle an Landesdaten Brandenburgs zu dem Thema gefunden habe: https://www.umweltdaten.brandenburg.de/immissionsschutz-klima und https://www.umweltdaten.brandenburg.de/immissionsschutz/klima#dateiliste-navigation.
Ich befürchte, daß es nicht großartig verwendungsfähig im Sinne der Grundidee sein wird… Eventuell kann man unter https://geoportal.brandenburg.de/geodaten/suche-nach-geodaten/ noch suchen…

Sven

Wie andere auch schon, hätte ich eine Lärmkarte bei den Landesvermessungsämtern vermutet und hier für BW auch gefunden:
https://www.lubw.baden-wuerttemberg.de/laerm-und-erschuetterungen/laermkarten

Da gibt es auch einen WMS Dienst, aber leider kann BRouter-Web derzeit nur WMTS Layer mit kompatiblem Tile-Format dynamisch einbinden.

Es gibt auch noch das Pseudotag estimated_traffic_class, das man auch als Lärmindikator sehen könnte. Dazu gibt es auch Bilder, für die ich mal eine separate Karte (Klick lädt Bild) gebastelt hatte.

Genau dazu habe ich kürzlich ein Issue (brouter#258) und eine Link-Sammlung zum Thema erstellt. Die Idee ist, durch räumliche Analyse gewünschte Eigenschaften von umgebenden Objekten - oder auch externen Daten wie Lärmwerten - als Pseudotag bei der Vorverarbeitung hinzuzufügen. Das würde mich zwar sehr interessieren, wäre aber etwas aufwändiger und im Moment habe ich keine konkreten Pläne dazu.

Ja, eine weitere Synchronisation zwischen den einzelnen Komponenten wäre noch wünschenswert. Noch praktischer wäre vermutlich die angedachte Erweiterung der Routenfärbung um weitere Eigenschaften wie den highway Typ oder eben die estimated_traffic_class (#242) und/oder die Farbcodierung verschiedener Eigenschaften im Höhenprofil (#310).

Hallo ikonor,

danke für die Links. Ich sehe, ich renne offene Türen ein :slight_smile:
Die Visualisierung eines berechneten Lärmlayers wäre wahrscheinlich wenig sinnvoll für die Lösung der beschriebenen Probleme. Letzlich braucht man ja “nur” eine Gewichtung pro Weg, die angibt, wieviel Lärm man auf den zurückgelegten Metern so “einsammelt”.

Zur Visualisierung in brouter-web:
Bei der Analyse fehlt mir wie oben beschrieben eine Unterscheidung nach Steigung/Gefälle/flach. Jetzt wäre es wohl wenig sinnvoll, immer mehr Tabellen anzuzeigen. Mir würde helfen, wenn ich im Höhenprofil einen Abschnitt markiere und dann nur die Auswertung für diesen Abschnitt erhalte. Wie oben beschrieben sind mir die “großen” Straßen bergab durchaus willkommen. Im Flachen lassen sie sich fast immer vermeiden, bergauf nur manchmal. Störend wird es aber auch erst, wenn die Strecke kilometerlang entlang solcher Straßen führt.

Ich habe im letzten Jahr mal versucht, mir ein entsprechendes Profil zu basteln. Hab ich aber nicht “mal eben so” hinbekommen.
Ich vermute mal, das brouter die Straßen in seiner internen Datenstruktur nicht auf Basis des Höhenprofils weiter auftrennt.

Das wäre die noch anspruchsvollere Variante der Synchronisation, aber sicher auch wünschenswert. Ich persönlich würde da die Priorität bei den oben genannten Issues sehen.

Nein, und soweit ich weiß, kann man die downhillcost und uphillcost Parameter auch nur im globalen Kontext setzen und nicht pro Way.