Ich habe höherwertige Straßen erstmal als highway = trunk, primary, secondary, tertiary, primary_link, secondary_link, tertiary_link und unclassified festgelegt. Wenn über eine solche Straße eine Brücke führt und keine Höhenangabe vorliegt, sollte ein Symbol unter Brücke über höherwertiger Straße angezeigt werden.
Alle Bugs teilen sich dann in jeweils genau eine der folgenden 4 Kategorien auf:
Tunnel: Blaue Symbole
Straße unter Eisenbahnbrücke: Rotes Symbol, Brücke mit railway=* getaggt
Brücke über niederwertiger Straße: Rotes Symbol, Brücke mit highway=* getaggt, allerdings nicht {trunk, primary, … unclassified}, siehe oben
Brücke über höherwertiger Straße: Rotes Symbol, Brücke mit highway={trunk, primary, …, unclassified} getaggt, siehe oben.
Sehr gut beobachtet, danke! Da fehlte noch die Berücksichtigung des layer=* Tags in der Auswertung.
Hallo mmd,
wenn ich das richtig verstehe, findet also kein Vergleich zwischen der Klassifizierung der unteren und oberen Straße statt.
Dies könnte dann klarer beschrieben werden, wenn “niederwertiger” und “höherwertiger” durch “niederwertige” und “hochwertige” ersetzt werden.
Die Eisenbahnbrücken scheinen bei 3. und 4. nicht enthalten zu sein. Wenn dies so beabsichtigt ist, sollte die Beschreibung “Sonstige Brücke über … Straße” lauten. Allerdings sehe ich keine reale Anwendung, dass man Eisenbahnbrücken komplett unterdrücken will. Also sollte die passenden Eisenbahnbrücken auch bei 3. und 4. mit aufgenommen werden.
Unclassified hätte ich eher bei den niederwertigen Straßen eingeordnet. Es könnte aber auch sinnvoll sein, Unclassified sowohl bei den niederwertigen als auch bei den hochwertigen darzustellen. Diese könnten einerseits ein lohnenswertes Ziel sein, um von einem Mapper gezielt erfasst zu werden, andererseits könnten manche Unclassifieds auch noch im Durchgangsverkehr nebenbei mit erfasst werden. Vielleicht sollte man sogar “tertiary” in beide Gruppen einordnen.
Bei den Tunneln wäre es noch hilfreich, wenn man highway=service einzeln unterdrücken könnte, da dies vermutlich primär Hofeinfahrten sind.
Noch eine unabhängige Anregung: Wenn man als Hintergrundkarte alternativ die Radfahrerkarte wählen könnte, wäre dies erstens vermutlich für einige Mapper hilfreich, die mit dem Rad unterwegs sind. Zweitens rendert Mapnik auf der normalen Karte leider bevorzugt Ref-Tags mitten auf die Brücke, so dass die genaue Situation im Kreuzungspunkt trotz des innen transparenten Fehlersymbols teilweise nicht erkennbar ist.
einen kleinen Fehler habe ich noch auf der Karte gesehen:
Wenn ich Deinen Link zur Karte aus obigen Forum-Beiträgen aufrufe, sehe ich den Stil “hihebike” aber nicht den rechts oben unter dem Pluszeichen markierten Mapnik-Stil - das sehe ich als Widerspruch.
Heute bin ich auch an einer Brücke über ein Gewässer vorbeigekommen, über die aber kein Verkehrsweg oder sonstige Rohre (z.B. Fernwärme) verlaufen, die aber trotzdem eine Höhenbeschränkung drangeschrieben hat. Im Netz habe ich ein Bild dieser Brücke gefunden - dann sieht man, was der Grund für die Höhenbeschränkung ist.
ich habe heute die Änderungswünsche von slhh umgesetzt und dabei noch ein paar neue Layer hinzugefügt. Dadurch hat sich auch der Parameter layers in der URL etwas geändert, womit OpenLayers offenbar einige Probleme hat. Das lässt sich aber recht leicht beheben, indem man den layers-Parameter aus der URL entfernt und einen neuen Permalink erzeugt.
Im zitierten Link habe ich noch einen kleinen Fehler korrigiert und mlat/mlon durch lat/lon ersetzt.
Die beiden Schlüssel maxheight:forward und maxheight:backward werden aktuell noch nicht ausgewertet, daher wird an der Stelle noch ein Fehler angezeigt. Kommt aber auf die Todo-Liste.
Edit: Es gibt bisher nur 11 Ways in DE, die überhaupt mit maxheight:forward oder maxheight:backward getaggt wurden:
Wie sollte die Auswertung der beiden Schlüssel aussehen? Reicht es aus, wenn wenigstens einer der beiden Schlüssel gesetzt wurde, unabhängig davon, ob ein maxheight=* existiert?
Hallo mmd,
die Änderungen sehen gut aus. Warum hast Du nicht “höher” durch “hoch” ersetzt? “Höher” impliziert doch irgendwie einen Vergleich.
Das reicht leider nicht. Wenn ein Mapper unsicher ist, ob eine Höhenbeschränkung in die andere Richtung gilt, wäre es korrekt, wenn er nur die eine Richtung einträgt. Habe ich auch schon gemacht, allerdings bisher nur bei baulich getrennten Fahrbahnen. Dann sollte die Brücke natürlich noch nicht aus deiner Karte verschwinden.
Wenn es so wenige Brücken mit maxheight:forward oder maxheight:backward sind, wird die Wahrscheinlichkeit gering sein, das Navis dies richtig auswerten.
Daher wäre es empfehlenswert, den kleineren Wert in maxheight einzutragen und für die Gegenrichtung diesen Wert durch maxheight:forward oder maxheight:backward zu überschreiben. Dann kann ausser einem Umweg zumindest nichts passieren, wenn das Navi nur maxheight auswertet.
Damit würden diese Brücken automatisch aus deiner Karte verschwinden.
Das entspricht dann leider nicht mehr der Realität.
An der einen Stelle, die ich kenne (3.5 forward und 4.0 backward), weichen die LKW gegebenenfalls auf die Gegenfahrbahn aus, wenn die 3.5 Meter nicht ausreichen.
Formal dürfte diese Vorgehensweise keine Änderung der Aussage der OSM Daten bewirken.
Wenn ein Navi dieses nicht richtig auswertet, hat es natürlich Daten, die nicht mehr der Realität entsprechen. Dann ist es es aber vermutlich besser, wenn diese Falschinformation wenigstens nicht zu einer Gefährdung führt.
Da muss man dann unterscheiden wie die Brücke beschildert ist.
Wenn die Brücke aus einer Richtung mit 3.5m beschildert ist, wäre das Verhalten des Lkw-Fahrers illegal, und wir bräuchten es nicht zu erfassen.
Wenn die Beschilderung sich nur auf die rechte Fahrbahnseite bezieht und der LKW tatsächlich auf die Gegenfahrspur ausweichen darf, so können wir dies ohnehin nicht mit maxheight:forward und maxheight:backward erfassen, da diese sich ja auf die Richtung und nicht die Position auf der Fahrbahn beziehen.
Allerhöchstens könnten wir dies über maxheight:lanes erfassen, aber auch dieses halte ich für problematisch.
Vielleicht sollten wir ein neues Tag für seitliche Höheneinschränkungen definieren. Dieses würde keine Verkehrsbeschränkung darstellen, aber ein Navi könnte es in eine Warnung umsetzen.
Da muss man nichts Neues erfinden.
Mit :lanes= gibt es bereits ein verabschiedetes Schema dafür: http://wiki.openstreetmap.org/wiki/Lanes
Zwar wird maxheight dort nicht explizit erwähnt, kann aber analog zu maxspeed/maxwidth:lanes=* verwendet werden.
Da lanes schema kenne ich natürlich und hatte deshalb auch maxheight:lanes erwähnt. Problematisch in diesem speziellen Fall wäre, dass dieses Schema die Verwendung der Gegenfahrbahn nicht berücksichtigt.
Der häufigere Fall einen seitlichen Höhenbeschränkung wäre eine zweispurige Straße, wo ein LKW in Fahrbahnmitte fahren muss. Ursache könnte eine Bogenbrücke, eine Gebäudedurchfahrt in Bogenform (z.B. Stadttor) oder auch Bäume sein. Hier hilft uns das lanes Schema überhaupt nicht mehr weiter. Daher sehe ich schon einen gewissen Bedarf, ein neues Tag zu erfinden.
Nun ja, irgendwann muss ein Fahrzeugführer sein eigenes Gehirn einschalten.
Die Entscheidung ob er die linke Fahrspur (= Gegenrichtung) benutzt, muss er/sie abhängig von der aktuellen Situation selber treffen (und ggfs. abwarten bis das gefahrlos möglich ist).
Was die Nutzung der Fahrbahn-Mitte (= beide Fahrspuren belegt) betrifft, gilt obiges, der Fahrzeugführer muss seine eigenen Entscheidungen treffen. In OSM gibt es bisher noch keine Möglichkeit diesen Sachverhalt angemessen darzustellen.
Sicher muss der Fahrer vor Ort Entscheidungen selber treffen. Wenn er nach Navi fährt, so muss das Navi aber zuvor auch die Entscheidung treffen, dass diese Straße genutzt werden kann.
Wenn wir jetzt beispielsweise maxheight:lanes=4|3.5 verwenden, so muss dass Navi auch erstmal entscheiden, dass der Fahrer hier die Gegenfahrbahn benutzen kann und somit die tatsächliche Höhenbeschränkung dieser Route nur 4m ist. Für diese Entscheidung bietet das Lanes Schema aber keine ausreichende Datengrundlage.
Dies ist richtig. Allerdings wäre es für den Fahrer schon hilfreich, wenn er durch eine Warnung darauf hingewiesen wird, dass er hier aktiv eine Entscheidung treffen muss und vorher die Umgebung (z.B. Beschilderung) aufmerksam zu beobachten hat, um eine passende Entscheidungsgrundlage zu haben.
Die Lkw-Unfälle unter Brücken zeigen doch, dass dies der Fahrer nicht immer automatisch macht.
Da wir bisher keine Möglichkeit haben, den Sachverhalt angemessen darzustellen, sollten wir diese schaffen.
Wenn wir exakt beschreiben wollten, wie die Höhenbeschränkung auftritt, wäre es unnötig kompliziert. Hier kann man sich tatsächlich auf die Entscheidung des Fahrers vor Ort verlassen. Wichtig wäre nur zu erfassen, dass eine teilweise Höhenbeschränkung vorliegt und ab welcher Höhe diese relevant ist. Damit wäre auch obiger Fall abzudecken, wo der Fahrer die Gegenspur wählen muss.
Ich schlage daher vor, ein Tag der Form maxheight:partial=3.5 zu verwenden. In Fällen, in denen keine konkrete Höhenangabe vorliegt, könnte man maxheight:partial=yes verwenden. Dies könnte zum Beispiel Bereiche abdecken, die mit dem Verkehrszeichen “Eingeschränktes Lichtraumprofil” gekennzeichnet sind.
Bei Bedarf könnte man maxheight:partial mit :forward und :backward kombinieren.
Für das Beispiel mit der einseitig nur 3.5 hohen Brücke könnte man somit folgendes taggen:
maxheight=4
maxheight:partial:forward=3.5
Dabei bin ich davon ausgegangen, dass im Brückenbereich Überholverbot sein wird und somit in backward Richtung die höheneingeschränkte Fahrbahn ohnehin nicht benutzbar sein wird. Daher braucht die backward Richtung auch kein maxheight:partial.
In meinem konkreten Fall gibt es keine Markierung der Straßenmitte und auch kein Überholverbot.
Da dort im Prinzip eine Sackgasse für Autos ist, wissen die wenigen, die dort hin müssen, von der unterschiedlichen Regelung bergauf/-ab und verhalten sich entsprechend.
Ich persönlich bin kein Fan vom Taggen von immer Ausnahme-Situationen.
Wenn es jedoch sein muss, dann ist maxheight:partial(:forward/backward) ein Weg für das man ein Proposal erstelen könnte.
Es gibt noch einige weitere Fälle, in denen Höhenbeschränkungen mit einer gewissen Wahrscheinlichkeit auftreten können. In diesem Post fange ich mit Tankstellen an.
Fast alle Tankstellen haben eine Überdachung und diese kann natürlich prinzipiell eine Höhenbeschränkung haben. Dabei kommen echte Höhenbeschränkungen nicht nur etwa bei uralten unbedeutenden Dorftankstellen vor. Ich habe gerade eine Höhenbeschränkung von 3.8m bei einer Tankstelle in der City-Nord an einer sechsspurigen Straße eingetragen. Dabei handelt es sich nocht nicht einmal um eine Tankstelle innerhalb eines Gebäudes (z.B. Parkhaus), wie dies im Ausland teilweise üblicher als bei uns zu sein scheint. An zwei weiteren Tankstellen hier in der Umgebung ist mir auch schon 4m Beschilderung aufgefallen.
Es stellt sich die Frage, wie häufig derartige Beschränkungen tatsächlich sind und ob sich eine systematische Erfassung lohnen würde. Vielleicht können die Lkw-Fahrer hier dazu Auskunft geben, ob dies ein tatsächliches Problem ist.
Wenn eine Tankstelle detailliert gemappt und richtig getagt ist, sollte man sie über covered=yes mit finden. Oft dürfte dies aber nicht der Fall sein. Vermutlich müßte man zur systematischen Erfassung auch nach amenity=fuel suchen, aber je nachdem, wie man maxheight für Tankstellen taggt, kann es dann kompliziert werden, auf vorhandene maxheight-Einträge zu prüfen.
Zunächst müßten wir aber klären, wie man maxheight überhaupt sinnvoll bei Tankstellen taggt. Sicherlich würde man ein maxheight an den Servicewegen eintragen. Ist dies aber ausreichend? Die sinnvollste Aufgabe wäre wohl, dass ein Navi gezieht für den jeweiligen Fahrzeugtyp geeignete Tankstellen anzeigen kann. Dabei wäre natürlich auch eine Tankstelle für LKWs geeignet, die nur an einigen Tanksäulen eine Höhenbeschränkung hat. Derartiges wäre kaum korrekt aus den Daten der Servicewege automatisch abzulesen.
Vermutlich wäre daher besser, auch das amenity=fuel Objekt mit einem maxheight Tag zu versehen. Dann wäre es aber auch einfach, eine Karte für die systematische Erfassung fehlender maxheight Tags zu erzeugen.
Der zweite Fall potentieller Höhenbeschränkungen sind obere Tragwerke von Brücken. Hier ist also nicht wie üblich der untere Weg sondern der obere Weg betroffen. Da es nun viel mehr Brücken gibt, bei denen eine Straße oben liegt, als es Brücken gibt, bei denen eine Straße unten liegt, ist es natürlich nicht sinnvoll, für alle diese auch eine maxheight Angabe systematisch zu erfassen.
Es wäre jedoch ein zweistufiges Vorgehen denkbar. Brücken mit oberen Tragwerken sind vergleichsweise selten und diese Eigenschaft ist in Luftbildern erkennbar. Zudem treten diese Brücken insbesondere in bestimmten Bereichen auf, wie z.B. in Hafengebieten oder über größeren Bahnanlagen oder Flüssen. Daher könnte man diese Brücken anhand von Luftbildern geeignet taggen, um sie anschließend in der Karte als fehlender Höhenbeschränkung auszuweisen.
Die Schwierigkeit dabei dürfte sein, dass es vermutlich bisher keine geeigneten Tags gibt, um ein oberes Tragwerk abzubilden. Daher müßten wir vermutlich eines erfinden.
Einen seltenen Sonderfall stellen überdachte Brücken dar. Hier könnte man covered=yes verwenden. Dies wird im deutschen Wiki auch schon als Beispiel für covered=yes genannt.
Eventuell könnte man in dem allgemeineren Fall eines oberen Tragwerks ein Tag in der Art covered=partial, covered=partially oder covered=partly verwenden. Diese drei Tags sind nach Taginfo bereits im Einsatz, aber jeweils nur 1-2 mal.
Der dritte Fall potentieller Höhenbeschränkungen sind Parkplätze aller Art (darunter auch Taxistände etc.). Relevante Objekte wären dabei amenity=parking, amenity=parking_space, amenity=parking_entrance, amenity=car_sharing und amenity=taxi.
Allerdings müßte noch ein geeigneter Indikator für eine mögliche Höhenbeschränkung hinzukommen. Als Indikatoren sehe ich:
Lage unter Brücke (Dies ist leider nur erkennbar, wenn das Objekt flächig dargestellt ist.)
covered=*
tunnel=*
parking=underground
parking=multi_storey
amenity=parking_entrance braucht keinen weiteren Indikator, da auf multi_storey und underground begrenzt.
Weitere Fälle potentieller Höhenbeschränkungen sind service=drive_through und auch amenity=car_wash.
Ebenso wie die Parkplätze sind diese Höhenbeschränkungen vermutlich eher für Nutzer hoher Pkw oder Lieferwagen interessant, als für große Lkw, da ein Lkw-Fahrer wohl kaum auf die Idee kommt, in Parkhäuser etc. hereinzufahren.
Dennoch sollte man auch diese Beschränkungen erfassen, zumal dies vielleicht auch weitere Mapper für das Thema der Höhenbeschränkungen interessiert.
Dagegen wieder für Lkw inneressant könnten Höhenbeschränkungen im Zusammenhang mit amenity=ferry_terminal sein, die durch die Schiffe bedingt sein können.
gestern habe ich auch eine Tankstelle mit 4.2 m Höhenbeschränkung und ein Abfertigungs-Terminal (Dach) des Zolls für den Hamburger Freihafen (Neuhöfer Damm) mit 4.4 m eingetragen.
Meine Frage ist eher: Wie soll ich die Höhe des Daches ausmessen, wenn, wie bei den meisten Tankstellen, kein Schild angebracht ist. Ich möcht nicht zu jeder Tankstelle in meiner Umgebung eine etwa 5 Meter lange Leiter schleppen, um dann mit dem Maßband an der niedrigsten Stelle des Daches die Höhe zu messen.
Gibt es unauffälligere Höhenmessungen mit in den meisten Haushalten üblicherweise vorhandenen Gegenständen - einen Sextanten haben die meisten Haushalte wohl nicht. Deshalb finde ich mehrere Fotos (2 bis 5) aus verschiedenen, bekannten Positionen als einfachste und unauffälligste Methode, die das selbe Ergebnis, wie die Winkelmessung mit dem Sextanten liefern sollte, denn Laser-Entfernungsmesser sind wohl viel seltener in Haushalten anzutreffen, als GPS-Empfänger (incl. die im Navi) und es scheint mir fraglich, ob man damit auch die Umlaufende Kante der Tankstellendächer von unten aus treffen kann, um die Höhe mit auf den Boden gestelltem Gerät zu messen.
Bei den Tankstellen kann man sich vermutlich wie bei den Brücken über öffentlichen Straßen darauf verlassen, dass keine Höhenbeschränkung vorhanden ist, wenn keine Beschilderung vorhanden ist. Für den Höhenbereich von genehmigungspflichtigen Sonderverkehr mag dies nicht ganz zutreffen, aber nsonsten sind sich die Tankstellenbetreiber vermutlich der Gefährdung bewust. Wenn hier eine nötige Beschilderung fehlt, dürfte es auch innerhalb kürzester Zeit zu einem Unfall kommen. Spätestens dann dürften auch die Behörden eine entsprechende Beschilderung durchsetzen.
Bei Hausdurchfahrten oder Brücken über private Wege liegt der Fall etwas anders. Hier wird die Nutzung häufig auf eine bestimmte Nutzergruppe oder auf eine bestimmte Art von Verkehr beschränkt sein. Hier mag der Besitzer davon ausgehen, dass überhaupt keine Gefährdung vorliegt, dass die Nutzer die Gefährdung kennen, oder dass die Gefährdung auch ohne Beschilderung ausreichend erkennbar ist. Wenn beispielsweise eine Durchfahrt nur 2.50m hoch ist, dürfte jedem Fahrer klar sein, dass hier eine Höhenbeschränkung vorliegt. All diese Gründe, die zu einer nicht vorhandenen Beschilderung führen können, treffen bei Tankstellen jedoch nicht zu.
In erster Linie ist die Seite ganze dazu gedacht, einen einfachen Überblick über Nodes und Ways mit Höhenangaben zu geben. Die erfaßte Höhe sieht man oben rechts auf der Karte, sobald man mit der Maus über einen Knoten/Weg fährt. Mittelfristig soll diese Karte als eigener Layer in die Maxheight Karte integriert werden. Die bekannten blauen und roten Fehlersymbole (die z.Zt. nur wöchentlich aufbereitet werden) lassen sich so leichter mit den Live-Daten aus der Overpass-API vergleichen.
Frage an der Stelle: wie sollte der neue Layer idealerweise aussehen, damit man gut damit arbeiten kann? Die Farbgebung habe ich aktuell noch komplett in rot gehalten, verschiedene Farben je nach Wert könnten möglicherweise verwirrend wirken.
BTW: Lässt sich das Overpass-Anfrage so anpassen, dass nur noch bestimmte Tags im Ergebnis übermittelt werden?
Ausdrücklicher Dank an dieser Stelle an Roland für die sehr leicht anpassbare Demo und die sehr guten Antwortzeiten
