Brückenhöhen eintragen in die OSM Karte

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)

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.

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.

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.

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.

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:

  1. Tunnel: Blaue Symbole
  2. Straße unter Eisenbahnbrücke: Rotes Symbol, Brücke mit railway=* getaggt
  3. Brücke über niederwertiger Straße: Rotes Symbol, Brücke mit highway=* getaggt, allerdings nicht {trunk, primary, … unclassified}, siehe oben
  4. 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.

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

Hallo Franz,

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

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

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.

Die Realität ist leider ziemlich kompliziert.

Edbert (EvanE)

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.

Edbert (EvanE)

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.

Edbert (EvanE)

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.

Edbert (EvanE)

In den Untiefen des Wikis habe ich einen Hinweis gefunden, dass man auch für Wege mit covered=yes ein maxheight pflegen kann.

Das Symbol ist noch dasselbe wie bei Tunneln.

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.