Brückenhöhen eintragen in die OSM Karte

slhh · 2012-11-03T16:05:20.000Z

mmd:

Ein grüner Hintergrund bedeutet hier, dass für dieses Paar in den bisher erfaßten Wegen mehr als 90% mit einer echten Höhenbeschränkung getaggt wurde. → Guter Kandidat!

Da bin ich anderer Meinung. Ich sehe dies eher als Anhaltspunkt, dass diese Paare bisher von denjenigen, die maxheight=none systematisch erfassen, noch wenig berücksichtigt wurde. Das kann an mangelndem Interesse liegen, aber insbesondere auch daran, dass einige Paare viel schleichter erreichbar sind und vor allem nicht mal eben nebenbei erkundet werden können. Beispielsweise sind Eisenbahnbrücken in Wohngebieten viel schwerer in großer Anzahl abzufahren als Brücken über einer Bundesstraße.

mmd:

Mein erster Eindruck ist, dass besonders Wege unter railway=* recht häufig eine echte Höhenbeschränkung tragen. Ebenso sind echte Höhenbeschränkungen auf highway=trunk Wegen eher selten.

Das ist ja auch logisch, da erstere Brücken in der Regel viel früher angelegt wurden, als man die Höhe noch nicht für so wichtig gehalten hat.
Außerdem wird natürlich eine Höhenbeschränkung auf höherwertigen Straßen weniger toleriert.

mmd:

Ich denke, es wäre sinnvoll, sich zunächst auf diese 6791 Fehler zu konzentrieren und diese in eine Aktion aufzunehmen.

Selbst wenn die Statistik aussagekräftig wäre, würde ich dies nicht für sinnvoll halten. Wenn man in einer Aktion gezielt Brücken erkundet, nimmt man sich besser gleich alle sinnvoll erreichbaren Brücken in einem Gebiet vor. Mit etwas historischer Ortskenntnis kann man auch sehr gut selbst entscheiden, welche Gebiete lohnenswert erscheinen. Dabei wird man dann wohl auch die Wichtigkeit einer korrekten Höhenangabe mit berücksichtigen.

Die größte Wahrscheinlichkeit echte Höhenbeschränkungen zu finden, dürften wir bei Parkhäusern und Hausdurchfahrten finden, wobei man sich zumindest bei letzteren nicht auf eine fehlende Beschilderung verlassen kann und selbst nachmessen muss. Ich bezweifle aber, dass dieses die höchste Priorität haben sollte.

mmd:

Die Analyse beruht natürlich auf Extrapolation, d.h. es wird angenommen, dass sich die verbleibenden Bugs ähnlich verhalten wie die schon erfaßten maxheight=*. Kommt ein Paar nur selten vor, ist das natürlich mit Vorsicht zu genießen. Aber auch sonst lässt sich der reale maxheight=none Anteil nur bedingt gut abschätzen, da maxheight= schon viel länger in Gebrauch ist und dadurch der maxheight=none Anteil tendenziell eher zu gering eingeschätzt wird.

Nach meinem Eindruck sind die echten Höhenbeschränkungen auf öffentlichen Straßen zwar nicht vollständig aber doch überwiegend erfasst.
Zur Einschätzung der Wahrscheinlichkeit, das eine nicht erkundete Brücke eine Höhenbeschränkung hat, eignet sich daher
Anzahl maxheight=Zahl zu Gesamtanzahl der Wege unter Brücken
besser als
Anzahl maxheight=Zahl zu Anzahl maxheight=*

Da das maxheight=none noch nicht so lange verwendet wird, bedeutet ein fehlendes maxheight aber nicht, dass die Brücke noch nie bezüglich maxheight erkundet wurde.
Eine gewisse Einschätzung der Wahrscheinlichkeit einer echten Höhenbeschränkung bei Brücken ohne Höhenangabe konnte man vielleicht tatsächlich aus der maxheight=none Anzahl ableiten, aber nur, wenn man diese ausschließlich mit maxheight=Zahl einträgen vergleicht, die von Usern stammen, die auch maxheight=none setzen. Besser wäre es auch noch, nur diejenigen maxheight=Zahl zu berücksichtigen, die der User gesetzt hat, nachdem er erstmals maxheight=none verwendet hat.

mmd · 2012-11-04T12:27:46.000Z

.

slhh · 2012-11-04T20:41:47.000Z

Hallo mmd,

bei dünner besiedelten Gebieten dürfte das wesentliche Problem sein, dass sich überhaupt ein Mapper aus der Region um maxheight kümmert.
Die Zahl der Brücken dürfte in diesen Regionen eher gering sein, so dass es für einen Mapper wahrscheinlich keine Überforderung ist.
Vieleicht wäre eine Karte sinnvoll, die Brückenanzahl pro Einwohner darstellt, um Abweichungen von dieser Annahme zu erkennen.
Auch eine Karte, die Anzahl maxheight=none zu Anzahl der Brücken darstellt, könnte helfen Gebiete zu indentifizieren, in denen die systematische Erfassung nur unzureichend erfolgt.

Für gezielt erkundende Mapper könnte man einige Regeln zusammenstellen, wie sie sinnvoll Prioritäten setzen können. Eine spezielle Karte, die diese Prioritäten vorgibt, halte ich aber nicht für nötig.

Allerdings könnte die Höhenangabe fehlt eine Hilfestellung liefern, indem sie drei verschiedene Symbole (z.B. Farben) für

Straßen unter Eisenbahnen
Höherwertige Straße über niederwertigere Straße
Niederwertigere Straße über höherwertige Straße

Für eine gezielte Erkundung z.B. per Fahrrad bieten sich eher die ersten beiden Fälle an, in denen man eine erhöhte Wahrscheinlichkeit für eine echte Höhenbeschränkung haben dürfte.

Den dritten Fall kann man eher mal nebenbei erkunden, wenn man zufällig auf der höherwertigen Straße fährt. Dass dies wahrscheinlich früher oder später ein Mapper mal machen wird, ist ein weiterer Grund, warum dieser Fall bei der gezielten Erkundung eher geringe Priorität haben sollte.

Die unterschiedliche Kennzeichnung hilft auch bei der Planung einer Erkundung, da man so erkennen kann, auf welchem Weg man sich der Brücke nähern muss, um die Beschilderung überhaupt sehen zu können. Abgesehen von sehr hohen Zoomstufen kann man dies meistens derzeit nicht mehr aus der Karte erkennen, weil der Kreuzungspunkt durch das Symbol verdeckt wird. Man müßte daher für jede einzelne Brücke erst zoomen, was die Planung einer sinnvollen Strecke zur Erkundung sehr zeitaufwendig macht, wenn man nicht entsprechende Ortskenntnis hat. Insbesondere mit einer ausgedruckten Karte kann man unterwegs kaum sinnvoll umplanen. Hier wäre zu bevorzugen, wenn die Symbole für 2. und 3. auch auf einem Schwarz-Weiß-Ausdruck noch unterscheidbar wären.

mmd · 2012-11-04T21:33:15.000Z

Hallo slhh,

ich greife mir einen Punkt aus deinem Posting heraus, der relativ einfach zu beheben war:

slhh:

Abgesehen von sehr hohen Zoomstufen kann man dies meistens derzeit nicht mehr aus der Karte erkennen, weil der Kreuzungspunkt durch das Symbol verdeckt wird. Man müßte daher für jede einzelne Brücke erst zoomen, was die Planung einer sinnvollen Strecke zur Erkundung sehr zeitaufwendig macht, wenn man nicht entsprechende Ortskenntnis hat.

Die Symbole habe ich jetzt innen auch transparent gehalten, so dass der Karten an dieser Stelle weiterhin sichtbar sein sollte. Einen Schwarz-Weiß-Ausdruck habe ich nicht ausprobiert, auf einem Screenshot in Graustufen waren die Symbole jedoch gut erkennbar (natürlich ohne Möglichkeit, Brücke von Tunnel zu unterscheiden, da sich beide nur über die Farbe unterscheiden).

Link: http://maxheight.bplaced.net

Die anderen Punkte muss ich mir erstmal näher ansehen, das lässt sich nicht in 5 Minuten beantworten.

Gruß,

pyram · 2012-11-12T23:28:02.000Z

Sorry, aber ich verstehe “maxheight=none” nicht. Jaja, wird oben erklärt mit “steht für…” aber: hier soll getaggt werden, dass es keinerlei Höhenbeschränkung gibt? In Wirklichkeit ist doch gemeint, dass vor der Brücke kein Verkehrsschild steht, weil der “normale” Verkehr mit 4 m durchpasst. Sinnvoller wäre doch sowas wie “maxheight:sign=none” oder “sign:maxhight=none” (oder eine andere Variante, die ausdrückt, dass da kein Schild steht). Oder maxhight=legally (weil es im Prinzip durch die StVO eine reale Höhenbeschränkung gibt).
Außerdem braucht man dann den way nicht zu teilen, weil auf der ganzen Länge kein solches Schild steht

EvanE · 2012-11-13T15:01:26.000Z

pyram:

Sorry, aber ich verstehe “maxheight=none” nicht. Jaja, wird oben erklärt mit “steht für…” aber: hier soll getaggt werden, dass es keinerlei Höhenbeschränkung gibt? In Wirklichkeit ist doch gemeint, dass vor der Brücke kein Verkehrsschild steht, weil der “normale” Verkehr mit 4 m durchpasst. Sinnvoller wäre doch sowas wie “maxheight:sign=none” oder “sign:maxhight=none” (oder eine andere Variante, die ausdrückt, dass da kein Schild steht). Oder maxhight=legally (weil es im Prinzip durch die StVO eine reale Höhenbeschränkung gibt).
Außerdem braucht man dann den way nicht zu teilen, weil auf der ganzen Länge kein solches Schild steht

maxheight=* ist per se eine (angeordnete) rechtliche Beschränkung und nicht eine physikalische.
maxheight=none heißt also es wird keine rechtliche Beschränkung über die StVO hinaus angeordnet.
Das entspricht der Verfahrensweise beim bereits länger etablierten maxspeed=none.

Du kannst mit maxheight:physical= die physikalische Höhe über einer Straße angeben.

Edbert (EvanE)

Oli-Wan · 2012-11-13T15:16:15.000Z

EvanE:

maxheight=none heißt also es wird keine rechtliche Beschränkung über die StVO hinaus angeordnet.
Das entspricht der Verfahrensweise beim bereits länger etablierten maxspeed=none.

Diese Argumentation ist nicht wirklich korrekt. Würde man maxspeed=none tatsächlich für “keine Beschränkung über die StVO hinaus” taggen, könnten die meisten innerörtlichen Straßen maxspeed=none erhalten, denn es gilt nur der StVO-Wert 50 (§3 (3) Nr. 1 StVO); und jene außerorts ebenfalls maxspeed=none statt 100 (§3 (3) Nr. 2 StVO).

Tatsächlich wird maxspeed=none verwendet, wenn keine explizite numerische Beschränkung existiert, wie auf den DE Autobahnen. Dort gilt bekanntlich nur die dehnbare Bedingung der “angepaßten Geschwindigkeit”.

Unter Brücken gilt dagegen sehr wohl auch ohne explizite Angabe durch Verkehrszeichen eine numerische Höhenbeschränkung, nämlich 4,00 Meter nach § 32 (2) StVZO wie auf allen Straßen auch ohne Brücken. (Strenggenommen sind das Anforderungen für die Zulassung, nicht für den Betrieb eines Kfz; in der Praxis läuft es natürlich auf dasselbe hinaus.)

Insofern halte ich die Wahl von maxheight=none für sehr unglücklich. Hier wurde irgendwann maxheight=unspecified vorgeschlagen. Das fand ich weitaus besser, aber der Zug ist wohl abgefahren.

EvanE · 2012-11-13T15:39:47.000Z

Oli-Wan:

EvanE:

maxheight=none heißt also es wird keine rechtliche Beschränkung über die StVO hinaus angeordnet.
Das entspricht der Verfahrensweise beim bereits länger etablierten maxspeed=none.

Diese Argumentation ist nicht wirklich korrekt. Würde man maxspeed=none tatsächlich für “keine Beschränkung über die StVO hinaus” taggen, könnten die meisten innerörtlichen Straßen maxspeed=none erhalten, denn es gilt nur der StVO-Wert 50 (§3 (3) Nr. 1 StVO); und jene außerorts ebenfalls maxspeed=none statt 100 (§3 (3) Nr. 2 StVO).

Tatsächlich wird maxspeed=none verwendet, wenn keine explizite numerische Beschränkung existiert, wie auf den DE Autobahnen. Dort gilt bekanntlich nur die dehnbare Bedingung der “angepaßten Geschwindigkeit”.

Unter Brücken gilt dagegen sehr wohl auch ohne explizite Angabe durch Verkehrszeichen eine numerische Höhenbeschränkung, nämlich 4,00 Meter nach § 32 (2) StVZO wie auf allen Straßen auch ohne Brücken. (Strenggenommen sind das Anforderungen für die Zulassung, nicht für den Betrieb eines Kfz; in der Praxis läuft es natürlich auf dasselbe hinaus.)

Insofern halte ich die Wahl von maxheight=none für sehr unglücklich. Hier wurde irgendwann maxheight=unspecified vorgeschlagen. Das fand ich weitaus besser, aber der Zug ist wohl abgefahren.

Das nennt man im Englischen wohl nitpicking.
Ich hätte wohl besser das “angeordnet” auch in fett gesetzt und statt StvO, StVZO geschrieben.

Aber wie du schon schriebst, ist der Zug bereits in Richtung maxheight=none abgefahren. Das jetzt nachträglich noch zu einer möglicherweise besseren Variante umbiegen zu wollen, ist wohl aussichtslos.

Edbert (EvanE)

Oli-Wan · 2012-11-13T16:57:54.000Z

EvanE:

Das nennt man im Englischen wohl nitpicking.

Wenn Du damit den Kommentar zu Zulassung vs. Betrieb meinst: damit wollte ich eigentlich genau dem zuvorkommen, daß einer einwendet, aus der StVZO ergäben sich nur die Anforderungen für die Zulassung und man könne daraus keine Aussagen über die Beschränkungen einer (bzw. jeder) Straße herleiten.
Bei max.*=none dagegen sehe ich schon einen wesentlichen Unterschied darin, ob es eine konkrete Obergrenze gibt (wie die 4,00 m) oder eben nicht (“angepaßt”). Daher halte ich die strukturelle Analogie zwischen maxspeed=none und maxheight=none für irreführend, und von einer tatsächlichen Entsprechung zwischen beiden Situationen kann m.E. keine Rede sein. Dies wäre der Fall, wenn in § 32 StVZO sinngemäß stünde: Die Höhe eines Fahrzeugs darf nur so groß sein, daß beim Unterqueren von Brücken etc. eine Kollision ausgeschlossen ist.

slhh · 2012-11-16T23:56:35.000Z

Bereits früher in diesem Thread hatte ich darauf hingewiesen, dass das Tag maxheight=none sehr unglücklich gewählt ist.
Die erneute Diskussion zeigt, dass man wohl besser jetzt noch was ändern sollte, als dauerhaft Probleme wegen unsauberer Definition zu haben.
Bisher wird maxheight=none nur ca. 1000 mal verwendet. Das sollte ein Bot doch wohl spielend leicht anpassen können, wenn man sich auf ein besseres Tag einigt. Selbst von Hand wäre das wohl gut machbar, insbesondere wenn man bedenkt, dass uns allein in Deutschland noch ca. 50000 Einträge fehlen.
Diese Tags sind vermutlich von deutlich weniger Usern gesetzt worden, von denen wahrscheinlich viele diesen Thread mitlesen.

EvanE:

maxheight=none heißt also es wird keine rechtliche Beschränkung über die StVO hinaus angeordnet.
Das entspricht der Verfahrensweise beim bereits länger etablierten maxspeed=none.

Bei einer normalen Landstraße gibt es über die StVO hinaus auch keine Geschwindigkeitsbeschränkung. Also mußte man nach dieser Logik hier Maxspeed=none verwenden, tatsächlich wird aber mit maxspeed=100 der von der StVO vorgegebene Wert verwendet.

Sofern diese 4m Höhenbeschränkung nicht in der StVO, sondern in der StVZO befindet, könnte man sich für Deutschland noch eine konsistente Definition von maxspeed=none und maxspeed=none basteln, indem man nur Beschränkungen nach StVO berücksichtigt, aber nicht welche nach StVZO.
Die Tags sollten aber nicht nur für Deutschland geeignet sein. Ob man nun weltweit eine gleichartige Verteilung der Vorschriften hat, möchte ich aber bezweifeln. Daher halte ich eine derartige Definition für ungeeignet.

Abgesehen von der Bennenung sehe ich aber auch noch Bedarf an einer Verfeinerung, um die Aussage des Tags nicht zu verwässern.
Zunächst einmal sollte das Tag maxheight=unspecified kennzeichnen, dass keine Beschilderung vorhanden ist, ohne eine Aussage über die tatsächlich zulässige Höhe zu machen.

Ist weiterhin sichergestellt, dass tatsächlich keine besondere Beschränkung der Höhe über die allgemeinen Straßenverkehrsvorschriften hinaus vorliegt, so sollte stattdessen maxheight=default verwendet werden. Zumindest bei öffentlichen Straßen sollte daher innerhalb der EU eigentlich immer maxheight=default verwendbar sein, wenn keine Beschilderung vorhanden ist. In anderen Ländern oder z.B. auch bei Hofzufahrten etc. müßte man erforderlichenfalls die tatsächliche Höhe messen oder zumindest abschätzen, um maxheight=default setzen zu können.

Wenn eine Brücke, Hausdurchfahrt etc. zwar unbeschildert ist, aber tatsächlich die Durchfahrtshöhe gegenüber den allgemeinen Straßenverkehrsvorschriften weiter einschränkt, sollte maxheight=physical anstatt von maxheight=unspecified gesetzt werden. Maxheight soll zwar nur legale Höhenbeschränkungen enthalten, aber aus der physikalischen Beschränkung wird sich wohl immer auch eine legale Beschränkung durch allgemeine Regeln (z.B. §1 StVO) ergeben. Wenn es sich beispielsweise um ein leichte Holzbrücke handelt und das Fahrzeug ist ein Bergepanzer, so dürfte es sich nicht wirklich mehr um eine physikalische Begrenzung handeln, aber die Straßenverkehrsvorschriften dürften dennoch die Durchfahrt mit Zerstörung der Brücke verbieten.

Eventuell dürfte es zumindest in Deutschland maxheight=physical formal nicht geben, da dann Beschilderung gefordert wäre. In der Realität dürfte dies aber insbesondere bei Hausdurchfahrten nicht selten sein. Ich habe aber auch schon eine Bahnbrücke gefunden, wo dies sehr wahrscheinlich der Fall ist. Letztere ist eine Zufahrt zu einem Kleingartengebiet, in OSM aber als highway=unclassified eingetragen.
Gerade solche Fälle können naturlich eine hohe Gefahr darstellen, so dass ich es für sinnvoll halte, dies durch ein Tag geeignet zu kennzeichnen.
Maxheight=physical hat dabei den Vorteil, dass man dies oft schon setzen kann, ohne einen exakten Wert zur Eintragung in maxheight:physical=* ausgemessen zu haben.

Alternativ kann man auch nur einen Wert maxheight=unspecified bei fehlender Beschilderung verwenden und
statt maxheight=physical dann maxheight:physical=restrictive verwenden, solange man keinen exakten Wert hat. Ebenso könnte maxheight=default durch maxheight:physical=nonrestrictive ersetzt werden.
In diesem Fall wäre unter Brücken immer zu fordern, dass sowohl maxheight=* als auch maxheight:physical=* gesetzt werden.

Wichtig wäre mir vor allem, dass wir die drei Fälle, für die ich maxheight=unspecified, default und physical angedacht habe, irgendwie sauber unterscheiden.
Eine Anpassung der Benennung wäre später immer noch durch einen Bot möglich, solange wir nicht verschiedenes vermischen.

slhh · 2012-11-23T00:08:22.000Z

Hallo mmd,

danke für die Verbesserungen.

Bei 3. und 4. scheint entweder die Datenbankabfrage oder die Beschreibung vertauscht zu sein.

Hier ist auch noch ein Fehler zu finden, der aber schon älter ist:
http://maxheight.bplaced.net/map.html?zoom=18&lat=53.61518&lon=10.01844&layers=B0FTT&scope=FFTT
Es dürfte keine fehlende Höhenangabe angezeigt werden, da die Fußgängerbrücke unter der Straßenbrücke ist.

mmd · 2012-11-23T21:39:04.000Z

slhh:

Bei 3. und 4. scheint entweder die Datenbankabfrage oder die Beschreibung vertauscht zu sein.

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.

Hier ist auch noch ein Fehler zu finden, der aber schon älter ist:
http://maxheight.bplaced.net/map.html?zoom=18&lat=53.61518&lon=10.01844&layers=B0FTT&scope=FFTT
Es dürfte keine fehlende Höhenangabe angezeigt werden, da die Fußgängerbrücke unter der Straßenbrücke ist.

Sehr gut beobachtet, danke! Da fehlte noch die Berücksichtigung des layer=* Tags in der Auswertung.

slhh · 2012-11-24T01:28:01.000Z

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.

FvGordon · 2012-11-24T17:21:00.000Z

Hallo,

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.

Zwei Brücken habe ich kürzlich besucht, bei denen nur auf einer Seite ein Verkehrszeichen zur Höhenbeschränkung angebracht war:
http://www.openstreetmap.org/browse/way/192428178 und http://www.openstreetmap.org/browse/way/188791146 .
Die habe ich mit maxheight:forward und maxheight:backward getagged - wird aber in der Karte als noch fehlend markiert:
http://maxheight.bplaced.net/map.html?zoom=18&mlat=53.53315&mlon=10.0272&layers=B0000000TTT&scope=TTTTT

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.

Grüße,
Franz

mmd · 2012-11-24T17:47:12.000Z

Hallo Franz,

FvGordon:

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.

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.

Der korrekte Link wäre aktuell: http://maxheight.bplaced.net/map.html?zoom=18&lat=53.61518&lon=10.01844&scope=FFFTT&layers=B0000000F

Zwei Brücken habe ich kürzlich besucht, bei denen nur auf einer Seite ein Verkehrszeichen zur Höhenbeschränkung angebracht war:
http://www.openstreetmap.org/browse/way/192428178 und http://www.openstreetmap.org/browse/way/188791146 .
Die habe ich mit maxheight:forward und maxheight:backward getagged - wird aber in der Karte als noch fehlend markiert:
http://maxheight.bplaced.net/map.html?zoom=18&lat=53.53315&lon=10.0272&layers=B0000000TTT&scope=TTTTT

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:


  osm_id   | maxheight | maxheight:forward | maxheight:backward 
-----------+-----------+-------------------+--------------------
 162359932 |           |                   | 3.5
 180785507 | none      | none              | 3
  24652904 | 3.8       | 3.5               | 3.8
   7995512 |           |                   | 4
   7995511 |           |                   | 4
 165349769 |           |                   | 4
 162604238 |           |                   | 4
 165349768 |           |                   | 4
 188791146 |           | none              | 4
 152793489 |           | 4                 | 
  48832126 |           | 4                 | 
(11 rows)

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?

Gruß,
mmd

slhh · 2012-11-25T02:14:04.000Z

Hallo mmd,
die Änderungen sehen gut aus. Warum hast Du nicht “höher” durch “hoch” ersetzt? “Höher” impliziert doch irgendwie einen Vergleich.

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?

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.

EvanE · 2012-11-25T04:01:27.000Z

slhh:

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.

Die Realität ist leider ziemlich kompliziert.

Edbert (EvanE)

slhh · 2012-11-25T14:54:08.000Z

slhh:

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.

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.

EvanE:

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.

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.

EvanE · 2012-11-25T15:10:25.000Z

slhh:

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.

Edbert (EvanE)

slhh · 2012-11-25T17:06:57.000Z

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.