Solche Dinge wie die Maxheight-Map, der OSM-Inspektor, KeepRight und einige andere sind immer ein Ansporn, zu sehen, was sich noch verbessern lässt. Meist lassen sich ja mehrere Aktionen wie Maxheight mit dem Ergänzen fehlender Ref-Taggs an Autobahnabfahrten kombinieren. Und ein Blick auf den JOSM-Validator gehört natürlich auch zum Programm.
So habe ich am Wochende einigen alten OSM-Bugs bezüglich fehlender Stücke der D4 Radroute nachgespürt. Es war zwar alles schon von anderen vor mir richtig eingetragen worden, aber wenn ich schon die Bugs schließe, will ich mich wenigstens selber überzeugen.
Wie auch immer, OSM bringt einen dazu, aus dem Haus zu gehen, was in sich schon einmal positiv ist.
Im Wiki gibt’s das Bild noch in Originalgröße in 585 × 810, was ich aber aus naheliegenden Gründen hier nicht direkt als Bild eingebunden habe. Ist das groß genug? Das Bild kann man bei Bedarf übrigens im Browser noch weiter heranzoomen (Firefox: Ansicht → Zoom → Vergrößern).
Heatmaps sind schon ganz nett, vor allem sieht man recht schnell, wo Fehler gehäuft auftreten, ohne jeden einzelnen Fehler wirklich anzeigen zu müssen. Auf einer Karte mit Zehntausenden von Punkten verliert man dagegen bekanntermaßen recht schnell den Überblick.
Spannend wäre sicherlich noch eine Heatmap für Europa oder den ganzen Planet, als Kür das ganze noch im zeitlichen Ablauf. Leider fehlt mir dafür die passende Hardware.
Jein. Die Originalgrafik habe ich schon gesehen und die ist nicht wirklich zu klein, ich hätte aber trotzdem gern eine grössere. Mit einer grösseren kann man nicht wirklich mehr anfangen, wäre aber ein schönes Gimmick. Zoom-funktionen sind mir bekannt, aber durch die Auflösung der Grafik ist das kein Ersatz.
Gut, muss ich nicht alles verstehen, aber ich frage trotzdem mal nach, wie groß nun ‘groß’ sein soll. Dann schauen wir mal, ob das mit der Hardware drin ist
So, wieder etwas gebastelt. Herausgekommen ist eine Heatmap mit 4960x7015 Pixel (Dateigröße 5,5 MB). Die Datei bleibt wahrscheinlich nur eine gewisse Zeit online, bei Interesse also am besten eine lokale Kopie anlegen.
Noch eine Bitte an die Tagging-Experten: In Finnland scheint es noch Fragen zur Verwendung des maxheight:physical zu geben in Bezug auf die wirklich gemessene Höhe vs. den Wert auf dem Schild. Ich würde ja den Wert auf dem Schild eher in maxheight packen und einen möglicherweise selbst gemessenen Wert in maxheight:physical (ggfs. noch Toleranz einbauen?). Allerdings ist mir die Semantik des Schilds in Finnland nicht wirklich klar. Weiß da jemand mehr dazu und kann weiterhelfen? Link: http://wiki.openstreetmap.org/wiki/Talk:Key:maxheight:physical
Hier in Finnland haben wir zwei (oder vier) verschiedene maxheight Schildarter. Ein für maximale zulässige Fahrzeughöhe (runder Schild 342), und ein (wie auf der wiki Seite oben) für die “freie Höhe” [822] (rechteckige, normalerweise ein Zusatzschild, z.B. mit ein “andere Gefahr” Schild, oder allein direkt auf die Brücke montiert). Die letzte zwei sind auch rechteckige Schilder und Varianten von die zweite Schild: ein für “sichere freie Höhe unter einem Stromleitung” (z.B. Strassenbahnleitungen) [823].
Die letzte Variant ist kein “normaler” Strassenschild, aber “andere Schild”, und wird benutzt wenn die freie Höhe auf ein Teil der Strasse grösser ist, als was auf die zulässige Fahrzeughöhe Schild steht, oder wo die freie Höhe auf alle Fahrspuren nicht das gleiche ist. Z.B. eine Brücke wo die drei Fahrspuren unter der Brücke 4.6 m - 4.5 m - 4.4 m freie Höhe haben. Oder einige alte rundförmige Unterführungen, wo die normale Fahrspure nur 2.9 m höhe Verkehr durchlassen können, aber wo in die Mitte der Strasse z.B. 4.0 m frei ist - dann werden Busse warten und auf die Mittelstreifen fahren. (Das Höhe soll immer auf ein Zusatzschild unter der zulässige Fahrzeughöhe Schild erlaubt sein). Es gibt vielleicht nur zehn solche Unterführungen in die ganze Land, auf Strassen mit wenig Verkehr - ich kann nur ein Fall erinnern.
Das Wert auf alle diese Schilder ist immer mit ein Sicherheitsabstand gewählt; normalerweise 0.10 - 0.19 m, manchmal mehr.
Ich bin sicher dass sie können auch in Deutschland die Regeln für das benutzen den Verkehrsschildern finden, und da gibt es die Regeln, wie man das Wert von die Messungen bekommen soll.
IMO es wäre sinnvoll auch alle unbeschilderte Höhenbeschränkungen als maxheight taggen (mit auch maxheight:physical); man darf ja nicht gegen den Gebäudewand aufprallen, wenn die Zufahrt zu niedrig ist.
Ich wünsche mir eine weitere Aus(/ab-)wahlmöglichkeit in “fehlende Maxheight-tags” für den Tag tunnel=building_passage.
Ist das möglich? Spricht etwas dagegen?
Das ist aber auch eine blöde Stelle.
Den Deich kann/will man nicht absenken, die Brücke kann man mit vertretbarem Aufwand nicht höher setzen. ALs einziger Ausweg bleibt nur noch den Radweg im Bereich der Brücke runter vom Deich zu nehmen. Ob das wegen der Besitzverhältnisse überhaupt geht (und bezahlbar wäre), bliebe noch zu klären.
In Summe ist das Warnschild deutlich günstiger zu realisieren.
10m vor der Gefahrenstelle und frei schwingend, wären die Folgen einer Kollision wahrscheinlich weit weniger schwerwiegend. Dass es immer mal wieder jemand gibt, dem das passiert, scheint mir unvermeidlich.
Als technische Lösung sollte eigentlich ein leichtes Abtragen der Deichkrone, wobei diese automatisch verbreitert wird, ein Verschieben des Radweg auf dieser landeinwärts und Setzen einer Mauer wasserseitig neben dem Radweg möglich sein.
Eine Alternative wäre den Radweg abgetreppt an der Deichflanke leicht unterhalb der Krone zu führen, was aber vermutlich eine Deichverbreiterung erfordert.
Radfahrer vom Deich abschnittsweise herunterzuhohlen, ist aufgrund der nötigen Steigungen schon sehr Radfahrer-unfreundlich. Da der Innradweg, zumindest nach den OSM Daten, diese Unterführung nicht nutzt, sondern über Innstraße und untere Römerstraße verläuft, ist die Bedeutung der Unterführung für Radfahrer wohl eher gering, so dass eine solche kostengünstige Lösung aber wohl akzeptabel ist.
Wenn der Weg auf der Deichkrone jetzt für Radfahrer gesperrt ist, ist dieser falsch getaggt. Auch die Absperrbalken habe ich in den OSM-Daten nicht gefunden.
nach längerer Zeit möchte ich den Thread wieder nach oben ziehen. Anlass ist eine überarbeitete Fehlerprüfung in JOSM, die alle nicht-numerischen Werte für eine Vielzahl an Schlüsseln (layer, level, height, (max)height*, minclearance, …) mit einer Warnung beim Speichern quittiert. Dokumentiert ist die Änderung in JOSM Ticket 8687. Diese Änderung scheint nun schon einige Zeit produktiv zu sein und verleitet wohl auch schon einzelne Mapper dazu, **existierende maxheight=none Tags zu entfernen ** -vermutlich weil sie nicht genau wissen, wozu das Tag gut sein soll und JOSM mit der Warnung wohl recht hat. Mit dieser Meldung unterläuft JOSM in gewisser Weise die bisherigen Bemühungen, maxheight Tags zu sammeln und einen Überblick über den Fortschritt zu ermöglichen.
Im Trac Ticket habe ich daraufhin gebeten, die Warnung für maxheight=none zu entfernen und ihn auf die ausführlichen Diskussionen hier im Forum (und auch eine kritische Betrachtung von maxheight=none) verwiesen. Ein Entwickler (skyper) hat daraufhin geantwortet, dass er maxheight=none für falsch hält und hat ein alternatives Mapping vorgeschlagen.
Auch habe ich im Ticket angemerkt, dass ich gerne das Thema erneut ins Forum tragen möchte, da ich das selbst nicht entscheiden kann/will. Skyper hatte sich dazu allerdings noch nicht wieder geäußert.
