Brückenhöhen eintragen in die OSM Karte

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.

Hallo,

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.

Fragende Grüße,
Franz

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.

Bisher erfaßte maxheight= mit Overpass API anzeigen*

Hallo,

auf Basis von Rolands Overpass Multilayer Demo gibt es jetzt einen Prototyp für bereits erfaßte maxheight=* und maxheight:physical=*. Getestet in Firefox und Chrome, IE geht leider noch nicht.

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 :slight_smile:

Gruß,

Da es ja wohl in erster Linie eine Unterstützung zum Mappen ist, würde ich nur maxheight=none farblich anders darstellen, zumal dieses auch weit ausgedehnt werden kann (ohne den Weg zu zerteilen).

Wenn Du eine Karte machen wolltest, die beim Fahren helfen soll, wäre es sinnvoll, die Fahrzeughöhe eingeben zu können, und dann Höhen größer oder kleiner als diese Höhe farblich zu unterscheiden.

Ich bin mir nicht sicher, ob ein numerischer Vergleich der Werte gehen würde, ansonsten sollte es aber möglich sein:
Falls es dir gelungen sein sollte, die Demo ohne Lesen der Doku anzupassen, könnte dies helfen:
http://wiki.openstreetmap.org/wiki/Overpass_API
http://wiki.openstreetmap.org/wiki/Overpass_API/Language_Guide

Vielleicht ist es auch sinnvoll maxheight>=5 anders darzustellen. Ich hatte hier den Fall maxheight=12, gemeint ist aber maxweight=12. Die Stelle kenne ich und konnte es deshalb leicht korrigieren.Ich habe da noch zwei Verdachtsfälle.Da habe ich aber keine Ortskenntnis und muss deshalb den Urheber mal anschreiben.

http://www.openstreetmap.org/browse/way/27064539
http://www.openstreetmap.org/browse/way/87402571

Ich habe keine Vorstellung wie häufig so etwas ist und bei Verwechlungen im Bereich von 0-5 würde es nichts nützen, aber vielleicht könnte man dadurch doch einige Fehler finden.

Gruß Norbert

Hallo Norbert, mmd

Ich stelle mir eine Unterteilung nach Wert ist numerisch, falsch numerisch (Komma statt Punkt), zu groß (>=5), none und unbekannt vor.

Edit: @mmd: Deine Demo-Karte ist gut. Und maxheight=none wird schon andersfarbig dargestellt.

Edbert (EvanE)

Meine zwei Cent: Da in der Nachbarstadt etliche Bahnunterführungen einen halbrundne Querschnitt haben und beispielsweise (links/mitte/rechts) so beschildert sind:
maxheight 3,40 maxheight 3,90 maxheight 3,30,
habe ich die Straße mit maxheight:left=3.40 maxheight=3.90 maxheight:right:3.30 getaggt.

Hallo,

in den Layer “Bereits eingetragene maxheight Tags” habe ich mal eine kleine Fallunterscheidnug eingebaut wie von Edbert vorgeschlagen. Leider gibt es im Moment keine Beispiele in .de für einen falschen Dezimaltrenner, sonst würde das gelb erscheinen. maxheight >= 5 wird blau dargestellt, maxheight=none in grün, gültige maxheight-Werte in rot und ungültige Werte in pink/türkis oder wie immer die Farbe #FF00FF auch heißen mag.

Mit dem Prototyp will auch die Möglichkeiten ausloten, die bisherige Karte komplett auf Overpass API umzustellen. Darin sehe ich gleich mehrere Vorteile:

  • Die Karte ist immer aktuell
  • Karte ist nicht mehr auf Deutschland beschränkt, sondern funktioniert weltweit (ok, da fehlt noch die Übersetzung)
  • Für kleine Änderungen sind keine aufwändigen Anpassungen an der Toolchain notwendig, sondern bestenfalls nur etwas Javascript.
  • Keine regelmäßigen Updates der lokalen Datenbank mehr notwendig

Bisher umgesetzt mit Overpass API:

  • Klon des ito hgv routing layer (hgv=* und hazmat=* farbig darstellen), siehe http://www.itoworld.com/map/160 für die Legende
  • highway mit covered=* ohne entsprechende maxheight=* Angabe
  • tunnel=yes/building_passage ohne entsprechende maxheight=* Angabe

Erst ziemlich eingeschränkt funktionsfähig sind die folgenden beiden Layer:

  • Wege unter Eisenbahnbrücken ohne maxheight=*
  • Unterführungen ohne maxheight=*

Hier vermisse ich die st_crosses Funktion aus postgis. Etwas ähnliches versuche ich mit around aus der Overpass API und nachträglicher Ermittlung der Schnittmenge im Browser. Leider funktioniert auch die geometry.intersects Funktion aus OpenLayers anders als st_crosses. Während st_crosses nur innere Punkte analysiert scheint OpenLayers auch die Anfangs-/Endpunkte mit zu betrachten. Das führt noch zu recht wirren Ergebnissen.

Die Darstellung sieht jetzt auch anders aus. Am Beispiel “Eisenbahnbrücken ohne maxheight” sind die Wege ohne maxheight nun gelb markiert, während die zugehörigen Eisenbahnbrücken blau markiert sind.

Auch von der Performanceseite ist für die letzten beiden Auswertungen noch Luft drin. Ich fürchte, dass ich hier ohne Overpass API-Guru Unterstützung nicht wirklich weiterkomme.

Im Moment würde ich zum Rumspielen mit dem Prototyp (siehe Post #646) empfehlen, die Overlays zu deselektieren, bevor es in eine weiter entfernte Stadt geht - sonst werden zu viele Overpass API-Abfragen abgesetzt. Wenn die Karte nicht mehr geht, könnte ein http://overpass-api.de/api/kill_my_queries weiterhelfen. Damit werden alle zu lange laufenden Anfragen (“runaway queries”) abgeschossen.

Auf jeden Fall sehr positiv ist, dass man viele Karten der Art “maxspeed, maxwidth, maxheight,…” mit Overpass API extrem schnell bauen kann: für den hgv routing layer Klon war das keine halbe Stunde. Wenn man sich nicht gleich ein ganzes Bundesland anschauen möchte, ist das Ergebnis sogar recht performant.

tl;dr

  • Neuer Prototyp: Viele Funktionen aus aktueller Karte als Prototyp mit Overpass API umgesetzt, neue Funktion: aktuell bereits mit maxheight getaggte Wege anzeigen
  • maxheight Karte wie gehabt verfügbar

Für solche Fälle hatte ich hier den Key maxheight:partial vorgeschlagen. Für deinen Fall dann:
maxheight=3.9
maxheight:partial=3.3

Ich denke, die wichtige Information ist, wie hoch ein Fahrzeug maximal sein darf, um die Brücke zu unterqueren und ab welcher Höhe des Fahrzeugs der Fahrer auf Lichtraumprofileinschränkungen achten muss.

Ich denke bei maxheight:partial wäre die Wahrscheinlichkeit höher, dass dies auch jemand auswertet, da es auch auf unspezifischer beschilderte Fälle wie z.B. Lichtraumprofileinschränkung durch Bäume anwendbar ist (maxheight:partial=yes). Auch für Plätze und Parkhäusr wäre der Key geeignet.

Bei left und right sehe ich auch ein gewisses Problem mit dem Vertauschen von links und rechts bezuüglich der Gegenrichtung. Insbesondere wenn dann auch noch unterschiedliche Beschilderungen in den beiden Fahrtrichtungen auftreten, wird es kompliziert.
Bei maxheight:left:backward müßte man wohl immer erst im Wiki nachlesen, ob sich left dann immer noch auf die Richtung des OSM Weges oder die Gegenfahrtrichtung bezieht.

Den Nutzen der Zusatzinformation, die die Unterscheidung von left und right bringt, würde ich für gering halten, da ja auch die Information fehlen würde, wie weit diese Beschränkung ausgedehnt ist.

Ich unterstelle mal: Unterführung == Weg unter einer Brücke.
In der Tat gibt es noch seltsame Ergebnisse. Siehe z.B. bei diese und diese Brücken in Bonn. (Links zu OSM.org, da die Demo noch keinen Permalink hat.)

Du wirst das schon hinbekommen.

Das scheint ein echter Vorteil der (fast Live) Overpass-API zu sein. Zur Perfomance könnte man einen minimalen Zoomlevel festlegen. Der Rhein-Sieg-Kreis mit ein wenig drumherum und Bonn eingeschlossen dauert schon einige Minuten (Eingetragen+Unterführung).

Edit: Ohne Unterführungen/Eisenbahnbrücken ist das eine Sache von Sekunden.

Edbert (EvanE)

Gerade für die falschen Dezimaltrenner sollte man nicht die gleiche Farbe wie für die fehlenden Einträge verwenden, da niemand dazu gebracht werden sollte, eine Brücke nur wegen falschem Dezimaltrenner zu erkunden. Ich denke ohnehin, man sollte das Problem der falschen Dezimaltrenner OSMI oder besser gleich einem Bot überlassen. Dann sollte man den falschen Dezimaltrenner hier einfach als gültige Altenative betrachten. Ebenso sollte eine nachfolgende Einheit “m” mit oder Leerzeichen akzeptiert werden. Wenn du weltweiten Einsatz anstrebst, müssen auch Angaben in Fuß mit akzeptiert werden.
Wenn maxheight >= 5 notfalls schwer von fehlenden Einträgen unterscheidbar wäre, wäre dies nicht so schlimm, da man die Stelle wohl ohnehin aufsuchen muss.

Die Vorteile kann ich nachvollziehen, aber gibt das keine zu hohe Belastung für die Server der Overpass-API? Insbesondere beim weltweiten Einsatz. Derzeit dürfte deine Karte ja noch recht unbekannt sein, so dass dies noch wohl kein Problem ist. Die meisten Mapper dürften schon längst aufgegeben haben, diesen langen Thread mitzulesen.

Einerseits ist diese Darstellung sehr hilfreich, andererseits gibt es auch Probleme:

Sehr zur kurze Wege sind kaum sichtbar. Hier halte ich es (abschaltbar) für sinnvoll, zusätzlich einen Kreis in der entsprechenden Farbe um diesen kurzen Weg zu zeichnen. Wenn oberer und unterer Weg kurz sind, sollte die Farbe es unteren für einen gemeinsamen Kreis gewählt werden.

Die Farben (insbesondere das Gelb) können auch bei langen Wegen Monitor-abhängig erstaunlich gut in der farbigen Mapnikkarte getarnt sein. Dass die Linien natürlich auch Straßenverläufe sind und somit von Position und Lage in die Mapnik-Karte passen, perfektioniert die Tarnung. Ich habe bei mir festgestellt, dass man die gelben Linien von dem von Mapnik für gewisse Straßen verwendeten Gelb in Abhängigkeit vom Betrachtungswinkel mal sehr gut und mal fast nicht unterscheiden kann. Der problematische Betrachtungswinkel ist dabei einer mit sehr kräftigem Bild. Am besten funktioniert die Unterscheidung komischerweise in einem Betrachtungswinkel, wo das Monitorbild schon richtig ausgeblichen ist.

Daher sollte man wohl besser bw-Mapnik als default wählen.
Für farbige Hintergrundkarten wäre wohl eine einstellbare Farbintensität wie bei OSMI hilfreich.

Gegenwärtig gibt es maxheight:left/right viermal öfter als maxheight:partial*…

Wie meinst du das?
Hier ein (leidr symmetrisches) Beispiel:

Du brauchst nur die 5 von dir getaggten Unterführungen anzupassen, dann ist maxheight:partial der einzige verwendete Key. :slight_smile:

Der Key maxheight:partial ist auch noch kein eingeführter Key. Wir haben nur hier darüber diskutiert, das dies eine Lösung für derartige Fälle sein könnte, wobei aber teilweise die Auffassung vertreten wurde, dass es überhaupt nicht erforderlich ist, diese seitlichen Höhenbeschränkungen zu erfassen.

Sieh dir mal auf http://www.drehscheibe-foren.de/foren/read.php?17,4937131
die Brücke auf den Bildern 020 bis 022 an. Da wird es dann schon schwerer mit dem Taggen.
Man könnte in diesem Fall man wohl noch mit dem einfachen left und right arbeiten, aber manche Mapper würden vermutlich anfangen, kompliziertere Konstruktionen mit forward und backward zu bauen, da die seitlichen Höhenbeschränkungen dort formal nur in eine Richtung gelten.
Dann kommt die Definitionsfrage, ob man nun
maxheight:right:forward + maxheight:left:backward
oder
maxheight:right:forward + maxheight:right:backward
oder
maxheight:forward:right + maxheight:backward:right
oder
maxheight:forward:right + maxheight:backward:left
verwenden muss.

Man kann zwar nicht erkennen, was auf den Schildern steht, aber dass die Schilder nur in Fahrtrichtung montiert sind dürfte eher an Gründen der Sparsamkeit als an den Gegebenheiten vor Ort liegen. Ich bezweifle, dass die Höhenbeschränkung aufgehört hat zu existieren, wenn man rückwärts durch die gerade vorwärts befahrenen Brücke fährt.

Man kann Sachen auch unnötig verkomplizieren.

In meinem Fall habe ich das Naheliegendste genommen, um die einmal erfassten Gegebenheiten zu mappen und nicht ein jahrelanges Proponieren abzuwarten.

Ich denke auch, dass :right und :left sinnvoller ist. forward/backward in Kombination mit left/right ist auf jeden Fall doppelt gemoppelt. Wie malenki schon sagt ändert sich ja die Höhe nicht, wenn ich vorwärts oder rückwärts durch den Tunnel fahre.

Hallo,

leider habe ich wegen der Weihnachtstage nicht ganz so schnell antworten können.

Die verwendeten Queries sind bereits die richtigen. Man könnte höchstens überlegen, alle Wege abzufragen und den Schnitttest im Browser zu machen. Es könnte dann aber noch langsamer sein.

Andererseits ist die “around”-Klausel für Wege bisher nur sehr provisorisch umgesetzt und sehr langsam. Da das Feature vorher noch niemand benutzt hat, habe ich es nie optimiert; es testet intern alle Wege der Ausgangsmenge gegen alle Wege in der Bounding Box. Jetzt mit der Karte gibt es aber eine Motivation und vor allem sinnvolle Testqueries, das effizienter zu implementieren. Ich setze mich mal dran, es kann aber ein wenig dauern.

Die Verwendung als Schnitttest ist sehr pfiffig und konsequent. Ich denke, dass das dann als Semantik für “around:0” reinkommt - das vermeidet ein zusätzlichen Syntaxelement, da “around” sowieso einen Schnittest ausführen muss.

Ja, der Hinweis ist angemessen. Generell ließen sich noch die “timeouts” etwas kürzer stellen, dann ist ein solcher Ausfall nicht mehr so wahrscheinlich.

Die Gesamtzahl der Queries ist übrigens nicht entscheidend, sondern die Anzahl der parallel ausgeführten Queries. Nach 1 unmittelbar nach der Versionsumstellung ist aktuell 2 parallele Abfragen die Grenze. Die Serverlast ist durch die Maßnahme so deutlich gesenkt worden, dass es nun wieder reichlich Kapazität zur Verfügung steht. Insofern überlege ich ohnehin, ob nicht eine mildere Beschränkung ausreicht.

Viele Grüße,

Roland

Hallo Roland,

das sind ja ausgezeichnete Neuigkeiten so kurz nach Weihnachten! Ich hatte am Anfang schon Bedenken, dass sich die Schnittoperation gar nicht abbilden lässt und damit wesentliche Teile der bisherigen Karte nicht zur Overpass API gerettet werden können. Die Arbeitsweise von ‘Around’ war mir für Ways nicht unmittelbar klar, ein kurzer Test und Blick in around.cc hatten dann recht schnell zum Ziel geführt.

Die Sache mit den inneren Punkten habe ich in Javascript nachgebildet, so dass die Effekte, die Edbert bereits weiter oben in Post #653 beschrieben hatte, nicht mehr auftreten sollten. Zur Erinnerung: Wege die direkt mit einer Brücke verbunden waren, wurden da noch mitselektiert. Es gibt bestimmt noch einige Ausnahmefälle, in denen das nicht perfekt funktioniert. Kreisverkehre, die mit Brücken verbunden sind, könnten beispielsweise noch Probleme machen.

Ansonsten habe ich den Prototyp noch etwas für IE angepaßt, genauer: Overpass API aufrufen ohne Proxy. Bisher gab es da nur ein “Access is denied” (siehe OpenLayers Bug 719). Die Mapper in “users: Netherlands” scheinen wohl dasselbe Problem zu haben und testen den Workaround in der Zwischenzeit…

@alle: Weiterhin gibt’s ein paar neue Layer, allerdings noch nicht mit sinnvoll ausgearbeitetem Farbschema. Die jeweiligen Werte aus OSM werden zur Kontrolle auch unten links mit angezeigt.

  • Höchstzulässige Breite
  • … Länge
  • … Gewicht
  • … Achsgewicht
  • Höchstgeschwindigkeit für LKW
  • Maut (toll + toll:N3)

Damit sollten die meisten Tags, die sich in irgendeiner Weise auf LKW-Routing auswirken könnten, auf der Karte angezeigt werden.

Maxheight versteht inzwischen auch Angaben in Feet und Inch und ist toleranter gegenüber angehängtem “m”. Ebenso sollten gemischte Angaben (metrisch + englisch) mit Semikolon getrennt erkannt werden.

Viel Spaß beim Testen

Das sieht schon mal deutlich besser aus. Meine beiden Beispiele snd jetzt so wie sie sein sollen. Auch das nähere Umfeld (Anschluss der A 562 an die A 59) sieht vernünftig aus, auch wenn da noch vieles einzutragen ist.

Eine kleinere Ungereimtheit ist mit noch aufgefallen.
An dieser Stelle liegt eine Brücke (layer=2, Rad-/Fußweg) über der Autobahnbrücke (layer=1). Alle drei Brücken sind blau markiert, jedoch keine fehlenden Höhenangaben (die hatte ich letzte Woche ergänzt).
Das ist zwar etwas irritierend, aber sicher nicht dringend.

Die meisten dieser Angaben waren ja in der lange eingestellten Maxspeed-Karte bereits als Layer vorhanden und wurden durchaus vermisst. Insoweit kann ich das nur begrüßen. Fehler sind mir keine aufgefallen.

Nun einige allgemeine Anmerkungen:

  • Ein Permalink kann jetzt gesetzt werden. Prima!

  • Hast du jetzt eine Zeitbeschränkung (ca. 15 Sekunden) drin?

  • Wenn man ein Overlay abschaltet, wird die Anzeige der gefundenen
    Elemente nicht aktualisiert. (Nicht wichtig aber irritierend)

  • Wenn man ein Overlay abschaltet, werden die Daten neu geladen.
    Das scheint mir auf Dauer überflüssig. Auch werden die Zahlen
    des ausgeschalteten Overlays angezeigt.

  • Wenn man Overlays ein-/ausschaltet, zeigt die Anzeige der
    gefundenen Elemente nur die Zahl der letzten Abfrage und nicht
    die Gesamtzahl der Elemente aller eingeschalten Overlays.

  • Die Anzeige der Werte eines Elementes (unten links) beim Hoover ist sehr nützlich.

  • Bei den beiden Brücken-Overlays erfolgt keine Anzeige unten links.
    Vielleicht kann man einfach generisch “(Eisenbahn-)Brücke” respektive
    Weg ohne Höhenangabe” verwenden. Hat man mehrere Overlays
    eingeschaltet, ist es irritierend wenn gelegentlich keine Angabe erfolgt.

Was ich mir für die Zukunft noch wünsche, sind Editor-Links für den Kartenausschnitt oder auch (später) für einzelne angezeigte Elemente.

Ansonsten ist deine Demo-Karte schon weitgehend rund. Sie kann bald in den Echtbetrieb gehen.

Edbert (EvanE)

Wow, gestern Nacht geschrieben, heute Nacht funktioniert es.

Und noch einmal Wow, auch diese Anregungen sind bereits in einem Tag realisert.

Einen guten Rutsch wünscht
Edbert (EvanE)