Eintragung und Definition von Lawinenschranken bzw. Wintersperren

Hallo zusammen!

Vorab - ich bin neu hier und habe eine Frage bzgl. der Eintragung respektive dem Definieren von Lawinenschranken. Ich habe diesbezüglich auch schon den/der/die/das Wiki befragt, sowie im Forum gesucht - und keine befriedigende Antwort gefunden. Da ich gerade in meiner Region (Zillertal) einige Ergänzungen und Korrekturen vornehme, bin ich auf das Thema Wintersperren und Lawinenschranken gestoßen. Bei uns in der Region gibt es Lawinensperren die über den gesamten Winter gültig sind wie z.B. ins Stilluptal (ab Lacknerbrunn) oder zum Schlegeisspeicher (ab Breitlahner) und welche die temporär sind, beispielsweise ab einer gewissen Lawinenwarnstufe bzw. entsprechend der lokalen Situation. Da ich immer wieder von Touristen gefragt werde, ob man im Winter z.B. ab Lacknerbrunn ins Stilluptal gehen und über die Lawinenabsperrung einfach drübersteigen kann (*tief durchatmen :man_in_lotus_position: ) - ist es mir ein persönliches Anliegen, dass dies eingetragen wird - ganz davon abgesehen, dass Tourenplanungen via diverser App’s, die OSM als Grundlage verwenden, immer mehr zum Standard werden. Da dies scheinbar die Zukunft der Tourenplanung ist, möchte ich präventiv detaillierte Datensätze anlegen, um fatale bzw. letale Tourenplanungen zu minimieren, respektive im Idealfall ganz zu vermeiden.

Ist es irgendwie möglich temporäre bzw. situationsbezogene Sperren z.B. mit der Datenbank (RSS?) der LWDKIP zu verknüpfen bzw. bei saisonalen Sperren einen ungefähren Zeitraum angeben?

Danke für eure Mithilfe!
LG, Florian

Hallo Florian, ich hole ein wenig weiter aus:

openstreetmap ist eine Datenbank für Verortbares in die jede:r einpflegen kann, woran ein “persönliches Interesse” besteht und dafür frei ein Schema erfinden. Auf der andren Seite stehen die “Auswerter”, also z.B. Plattformen, die Touren anpreisen.

Momentan gibt es keine Möglichkeit automatisiert situationsbedingte Warnungen weiterzureichen. Ein GSOC Projekt hat eine Schnittstelle zum Thema die geeignet wäre so etwas wie die Warnungen in AV-Aktiv nachzubilden. @SimonPoole war da Mentor und hat auch im Österreichischen Topic Stunk gemacht, weil das hierzulande nur dann geht wenn man die GIP als Basis verwendet, wenn ich recht verstanden hab.

Für mehr regelmäßige Angelegenheiten gibts “conditionals”, z.B access:conditional=no @ (…) um generell den Zugang bedingt zu sperren (Ich denk Lawinen bedrohen nicht nur Autos). Meines Wissens gibt es Auswerter die das zumindest dann berücksichtigen, wenn man einen Termin eingibt. Ich glaub, von den Tourenportalen ist da keiner drunter.

1 Like

Danke für deine Antwort!

Wenn ich das in den letzten Tagen richtig mitkommen habe, greifen gewisse App’s bzw. Plattformen auf OSM zu, um z.B. eine Tourenplanung zu erstellen. Da sind mal Worte wie “Wegführung” oder “Rundwanderung”, also ein Weg ohne Unterbrechung gefallen. Der Grund meines Engagements ist kurz gesagt, der Vorfall am Harpfner vor ein paar Tagen. Wenn ich das richtig verstanden habe, hätte es da keine Tourenplanung gegeben, wenn dieser besagte “Steig” als “nicht durchgängig” eingetragen gewesen wäre… Die selbe Problematik sehe ich da z.B. im Winter bei diversen Lawinensperren!

Ich kenne mich leider (noch!) zu wenig mit den Grundlagen der ganzen App’s, Plattformen und OSM als Datenbank aus. Da ich allerdings in der rasanten Entwicklung und Verwendung solcher Applikationen ein potentielles Risiko sehe, dass man schnell verschlafen könnte - drängt sich in mir schon ein gewissen Handlungsbedarf auf…

LOL.

Ich könnt jetzt was dazu schreiben, lass es aber besser.

Grundsätzlich kann man mit der Platform Sperrungen erfassen, wo’s fehlt im Augenblick ist die Routerintegration, halt ein Huhn und Ei Problem.

Tendenziell würde ich regelmässige gleichbleibende Sperrungen die im vorneherein bekannt sind mit conditionals eintragen, die neue Platform closures.osm.ch ist eher für das Gegenteil gedacht.

2 Likes

Hallo Simon, danke für deine aufschlussreiche Antwort! Wenn ich das richtig verstehe, scheitert es an der Integration der in OSM eingebenen Daten, von Seite der angebotenen App’s?

Das Projekt closures.osm.ch habe ich mir kurz angesehen, ich muss mich da allerdings in den nächsten Tagen genauer einlesen. Schaut aber nach einem sehr tollen Projekt aus! Das Ding mit den Sperrungen ist, dass diese nicht mit einem bestimmten Tag beginnen bzw. enden. Es gibt bei den saisonalen Sperren schon grobe Zeiträume, umgesetzt werden diese allerdings situationsbedingt mal früher, mal später. Bei den temporären Lawinensperren, die oftmals nur einige Stunden oder Tage aufrecht sind, wäre die Sache einfach, wenn der zuständige Lawinenkommisionär diese einträgt bzw. wieder löscht - was allerdings nur Sinn machen würde, wenn die ganzen App’s wie Komoot, Strave, Alpenverein Aktiv usw. auf diese Daten zugreifen könnten und entsprechend in die Tourenplanung mit einfließen lassen würden…

Vielen Dank für die Ergänzung!

Am Besten nur einmal an einer Stelle und nicht für zwei, drei, vier Dienste separat? Ich denk, das ist es worums @SimonPoole am meisten geht.

PS: Die Bedingungen (für planbares) gehören an den Weg auch, nicht nur an den Schrankenknoten, wenn ich das richtig verstanden hab.

Man muss noch dazu sagen das conditionals vermutlich auch eher nicht unterstützt sind bei den Wander/Sportapps und dies alles so oder so wohl nur greifen könnte wenn man sich eine Route automatisch planen lässt (man könnte sich natürlich ein Overlay der aktuellen Sperrungsdaten machen, aber auch das bräuchte die Mitwirkung der Dienstleister für Endbenutzer).

Zumindest einige conditionals werden bspw. bei Komoot ausgewertet, indem ein Hinweis erscheint, dass ein Abschnitt mit zeitlich befristeter Zutrittsbeschränkung enthalten ist, oder bei mapy.com wird in dem Zeitraum nicht darüber geroutet bzw. die Sperre angezeigt, wenn man in den Bereich hinein routen möchte

Das Problem ist, dass man die Hürde - der Dienst hat genügend Daten und die Diensteanbieter wollen die auch benutzen - irgendwie überwinden muss. Dazu muss einerseits der Dienst ausgebaut und gefüllt werden, und anderseits der Dienst auch genutzt werden/brauchbar sein.

OSM hat den Schritt genau einmal in 20 Jahren geschafft.

Klar könnten wir für GSoC nächstes Jahr wieder etwas planen, aber dass ist eben nächstes Jahr nicht -jetzt-.

Danke an alle für die ganzen informativen Beiträge! :heart:
Irgendwie habe ich schon vermutet, dass die ganze Sache etwas komplizierter ist…

An dieser Stelle möchte ich kurz erwähnen, dass meine Ambition und der Gedanke, solche potentiellen Gefahrenpunkte (speziell im alpinen Bereich), einer breiten Masse zugänglich zu machen, nicht unbedingt neu ist. Mich beschäftigt die Thematik schon seit geraumer Zeit. Die vor kurzem erlangte Erkenntnis, dass OSM eine riesige Community basierte Plattform ist, in der sich jeder aktiv einbringen kann, ist für mich allerdings ein sogenannter “Game-Changer”. Ich bin ja ein großer Fan vom Open-Source und Community Gedanken :)

So richtig aktiv geworden, bin ich durch einen tödlichen Alpinunfall in meinem Heimatort vor wenigen Tagen. Auslöser dieses tragischen Unglücks war offenbar die Darstellung einer App, die diesen besagten Jägersteig (der aufgrund der Gefährlichkeit nicht mal mehr von Jägern genutzt wird) als “nette Rundwanderung” angezeigt hat. Über unumstößliche Grundsätze im Alpinismus wie Selbsteinschätzung, Eigenverantwortung oder der Fortbewegung “auf Sicht” im alpinem Gelände, brauchen wir hier nicht diskutieren und stehen für mich sowieso ausser Frage. Und selbst wenn ich mich als Alpinisten “der alten Schule” bezeichnen möchte, sehe ich den Sinn von digitalem Kartenmaterial und der Verwendung von App’s. alleine schon aufgrund der Möglichkeit einer Aktualität von Situationen und Gegebenheiten in (faktisch) Echtzeit.

Da sich im Bergsport die Routenplanung via diverser App’s immer mehr durchsetzt, sehe ich hier akuten Handlungsbedarf!

Mir ist bewusst, dass es ansatzweise schon Projekte und App’s diesbezüglich gibt. Ein Beispiel dafür sind die Projekte AV-GEO-CLIM oder AlpsWatch (Links am Ende des Posts). Diese sind allerdings wieder sehr spezifisch, bzw. ist die Erfassung dieser Gefahren einem kleinen Kreis vorbehalten, der sich wiederum nur in sehr speziellen Gebieten bewegt. Gefahrenbereiche zu definieren, obliegt hier ausschliesslich Bergführern, Geologen, Flug- und Bergrettern, was die Abdeckung m.M.n. extrem einschränkt, da z.B. Bergführer hauptsächlich auf Routen unterwegs sind, die kommerziell geführt werden. Damit scheidet ein ganz großer Teil im Wegenetz aus, der allerdings ebenso betroffen sein kann. Hier ist die Rede einer „high qualified crowd“. Sinnvoller wäre es allerdings, wenn jeder der sich im alpinen Raum bewegt, Meldungen machen und eintragen kann, die in gesonderten Fällen von dieser “hochqualifizierten Crowd” überprüft und als “vertrauenswürdige Warnung” eingestuft werden kann. Ganz davon abgesehen, dass bei den App’s bzw. Plattformen ausschließlich Ereignisse erfasst werden, wie Erdrutsche, Felsstürze oder Murgänge. Das Spektrum der alpinen Gefahren ist allerdings weit umfassender, wie z.B. temporäre Sperrungen durch Lawinengefahr oder Holzarbeiten, die entweder sehr oft gekonnt ignoriert werden, oder über sogenannte “Jägersteige” unwissentlich umgangen werden können, ohne dass man vorher durch Absperrungen oder Hinweisschilder gewarnt wurde. Hier wäre es z.B. sinnvoll Gefahrenzonen definieren zu können.

Da es sich bei OSM um eine große (wenn nicht sogar die größte) Community handelt, bei der jeder mitwirken kann, wäre das ja eine großartige Grundlagen-Plattform, um eine Lösung in Form einer eigenständigen App zu realisieren, die jedem die Möglichkeit gibt solche Gefahrenpunkte einzutragen und abzurufen. Im Idealfall in Zusammenarbeit mit anderen Plattformen, die diese Datenbank mit verwenden können und in ihre Tourenplanungen mit einfliessen lassen. Ich selbst habe zu wenig Knowledge in der Programmierung (ausser rudimentäre Kenntnisse in Python und ObjectiveC) um so etwas realisieren zu können - aber ich habe mitbekommen, dass hier schon sehr großartige Projekte realisiert wurden und in der Community sehr viel “WoMan-Power” steckt.

Mich würde interessieren was ihr davon halten :)

Beste Grüße aus Mayrhofen,
Flo

Ich seh da schwarz, wenn man sich als provider allein aufstellt, auch bei editor Integration (JOSM, iD nicht). Mehr Chancen seh ich, wenn man zusätzlich broker macht, aber das benötigt einen Standard für den Austausch.

So beobachtet: In OSM erscheint ein Hinweis: Weg durch Mur zerstört. Mir unglaubwürdig, kein schwieriges Gelände, lässt sich sicher leicht umgehen, ich mach nichts. Außerdem ist das Teil einer prominenten Route und das wird sicher bald behoben. Ein paar Tage drauf wird der Steig von jemandem auf “highway=construction” umgetaggt. Jemandem ohne lokales Wissen, aber bekannt dafür, Hinweise zu erledigen. Kleine Websuche ergibt: Die Notiz war am falschen Ort platziert. Die Störung betraf einen Steig nebenan. Zu dem Zeitpunkt die Störung schon wieder beseitigt. Also ja,

Nicht alle Meldungen dürfen wie die Bibel gelesen werden.

Die sollen ihre Erkenntnisse in einem Format abrufbar machen das dem entspricht, was in EU Richtlinien oder gar Verordnungen als interoperabel eingestuft wird. Dann kann ein broker die Einschnupfen. Zonen eher nicht, aber für Wege gibts Standards.

PS: Momentan kann nicht einmal der Radrouter Tirol auf Baustellen in Innsbruck zugreifen. Ich starte einen Versuchsballon, kann die Leitstelle das? @fs_LT Strecke Mühlauer Platzl zum Rechenhof zB.

Aus meiner Sicht lässt sich das halb-schön mit access:conditional=no @ winter lösen. “winter” ist jedoch kein wirklich definierbarer Begriff. Das erinnert mich etwas an Feature Proposal - RFC - Snow chains - auf der A14 in Vorarlberg gilt bspw. 80 km/h bei Schnee oder Eis. Teils auch 80 km/h bei Regen statt 130 km/h. Das kann man (und ist auch so) eingetragen mit maxspeed:conditional=80 @ ice;snow;wet oder ähnlich, aber das kann ja kein Navi so auswerten, weil das Navi nicht weiß ob gerade Schnee liegt oder nicht.

Wenn eine Sperre mit Datum vorliegt, geht das mit access:conditional=no @ (Dec 15 - Apr 15) natürlich deutlich genauer und wird auch immer häufiger unterstützt: Conditional restrictions - OpenStreetMap Wiki

Schwierig wird’s bei variablen / dynamischen Sperren, die einfach im Bedarf gelten. In meiner Gegend sind das bspw. einige Radwege am Rhein entlang (beidseitig in CH sowie AT) die bei Überflutung einfach abgesperrt werden. flood_prone=yes ist das eine, aber das Navi weiß nicht dass am Montag noch offen war und am Dienstag wegen Hochwasser gesperrt ist. Ident mit Passstraßen wie der Furkastraße. Sobald sich das Räumen mit Pflug mit Wintereinbruch nicht mehr lohnt, wird die Schranke auf beiden Seiten zugesperrt. An welchem Tag das immer ist, kommt auf den Winter an. Das in den OSM-Daten abzubilden ist aus meiner Sicht nicht möglich.

Komoot zeigt bei einem access:conditional zwar einen Text an mit “Enthält einen Abschnitt mit zeitlich befristeter Zutrittsbeschränkung. Informier dich vor einer Tour über eventuelle Sperrungen.” aber darin erfährt man nicht, von wann bis wann die Sperre ist (obwohl das Datum in OSM vorhanden wäre). Komoot weiß ja auch nicht, wann ich die Tour starte. Ich kann ja heute die Tour planen (Wintersperre nicht vorhanden), aber erst in 4 Monaten aufbrechen (Wintersperre aktiv).

Du hast da was missverstanden.

Die Platform soll einerseits eine Möglichkeit geben händisch eine Sperrung einzutragen, wie möglicherweise auch “offizielle” Daten einzulesen (deshalb gibt es auch einen Vertrauenswert den man abfragen kann), und dann eine einheitliche Schnittstelle anzubieten über die Applikationen die Daten abfragen kann (wir haben das absichtlich im Augenblick nicht Datex II konform gemacht, da das für praktisch alle Anwendungen viel zu kompliziert ist, könnt man aber natürlich auch noch machen). Wir haben auch im Augenblick nichts vorgesehen für Stau etc., da dass eher über Floating Car Data gemacht wird.

Es wird -nichts- in OSM eingetragen.

Aber wenn jemand Lust hat, es schwebt so eine Idee im Raum, in irgendeiner Form die Daten der Sperrungen zu nehmen und eine tägliche OSM Distribution zu machen bei denen die Tags entsprechend angepasst sind.

Ich hab das so verstanden, dass https://closures.osm.ch/ ein von openstreetmap unabhängiger Dienst ist, der es erlaubt Dinge zu erfassen, die für OSM nur Lärm sind (kurzfristige Wegsperren wegen Baustellen für die nächsten drei vier Wochen oder Lawinengefahr für die nächsten drei vier Tage).

Als mapper würde ich editor-integration gern nutzen: Derart betroffene Wege im Editor markieren und zB. über ein plug-in einen Eintrag in der closures Datenbank anlegen. VIEL besser als an OSM Daten herumzumurksen. Gerne auch auf Vertrauenswert -1. Als ich versucht hab eine Baustelle im Browser einzutragen bin ich aber dran gescheitert am Dienst mit oauth anzumelden…

Gibt es für Lawinensperrungen eine offizielle Quelle, oder muss man das teilweise vor Ort erkunden? Ich kenn die Lawinenvorhersage von der Europaregion Tirol Südtirol Trentino auf https://lawinen.report, aber daraus lassen sich auf den ersten Blick keine konkreten Sperrungen ableiten.

Soweit ich weiß ist das je nach Klassifikation der Straße in der Hand der Landesregierung bzw. bei Gemeindestraßen der Bürgermeister und bei Privatstraßen der Eigner. Eine Pflicht zur Veröffentlichung im Internet gibt es nicht, vorgeschrieben ist im jeweiligen Landesrecht meist nur die Verfügung durch sichtbare Tafeln mit der Aufschrift “Wintersperre”.

All diese Daten werden jedoch in der Regel von den Ländern in den EVIS-Datensatz gespielt, welche bspw. vom ÖAMTC abgerufen wird: ÖAMTC: Verkehrsservice

Beim ÖAMTC weitergeklickt und offensichtlich schaffen die hier ÖAMTC Routenplaner das, wovon hier Graphenintegrations-Plattform die Rede war, ob das geht: Nämlich zB EVIS Daten auf openstreetmap Daten abzubilden.

Ich hab’s nur kurz überflogen. Aber für https://closures.osm.ch gibt’s schon ein Issue um DATEX II Daten einzubinden. Wenn man den XML-Datensatz von EVIS in geojson umwandelt, dann könnte man die Verkehrsmeldungen aus Österreich auf einer OSM-Karte anzeigen lassen.

1 Like

Ausser etwas hat in den letzten Monaten geändert sind die EVIS Daten nur gegen Bezahlung erhältlich. Nichts gegen das, aber das schliesst aus, dass wir sie als Open Data weiterverbreiten.

3 Likes