Brückenhöhen eintragen in die OSM Karte

Hallo

Ja das ist schon klar (aber man steht oft und da kann man die Gedanken schön notieren vom Tag )

Mit den Tunneln unter Häusern ist das auch wichtig

Ich war letztens z.B. in Kopenhagen (Postzentrum) 24ton Zeitschriften. Anlieferung im Keller des Gebäudes (einfahrt 4m )

Wenn eine Wohnungsgesellschaft oder der gleichen eine Durchfahrt anbietet müssen die die auch Beschildern wen die unter 4m sind.
So wie selbst bei uns
www.openstreetmap.org/?lat=51.756465&lon=11.962416&zoom=18
Historischen Bogen eingerissen mit LKW Bandhauer Straße (War kein Schild dran)
Kein Schild also maxheight=none
BesteGrüße

Hallo,

Eine Legende gibt es bisher nur in der Desktop-Version oben rechts in der Info-Box. Ruft man diese Seite allerdings per Smartphone auf, wird automatisch auf die Mobil-Seite (noch die ältere mobil.html) weitergeleitet.

Zum ersten Punkt: da war zuvor schon eine Höhenangabe unter der Brücke von Ebbe73 (Weg 24391477 in der Version 4 vom 28.05.09), nur hast Du den irgendwie gelöscht und neu angelegt. Kann man schön nachvollziehen, wenn man http://www.openstreetmap.org/?lat=52.38148&lon=9.6935&zoom=18&layers=M in JOSM öffnet und dann einen Revert von Changeset #13459320 im Editor durchspielt (Wichtig: Ergebnis bitte nicht hochladen!).

Bei der zweiten URL greift eine Optimierung: führen über einen OSM-Way mehrere Brücken in geringem Abstand wird stellvertretend für alle gefunden Brücken jeweils nur ein Symbol angezeigt. Damit werden z.B. hier nur 4 Symbole angezeigt.

Das ist korrekt beobachtet, maxheight:physical wird momentan noch nicht ausgewertet, steht aber schon auf der Todo-Liste.

Bin mir nicht sicher, ob dieser Fall wirklich häufig vorkommt und den Aufwand für eine eigene Lösung rechtfertigt. Abweichende Höhen pro Fahrtrichtung könnte man heute schon im Freitext beschreiben. Allerdings ist im Moment noch nicht klar, in welche Richtung sich die Fehlererfassung vor allem für die mobile Anwendung entwickeln soll. Der aktuelle Ansatz in der v2-Karte ist da sicher noch ausbaufähig (ist auch noch experimentell).

Gruß,

Hallo mmd,

das Symbol für die fehlende Höhenangabe sollte unterdrückt werden, wenn der untere Weg highway=platform ist.
Sonst gibt es diverse unsinnge Symbole bei U-Bahnstationen. Beispiel:
http://maxheight.bplaced.net/map.html?zoom=18&lat=53.57604&lon=9.95213&layers=B0

Wenn highway=platform der obere Weg ist, sollte natürlich weiterhin auf fehlende Höhenangabe geprüft werden.

Weiterhin habe ich festgestellt, dass in vielen Fällen die Symbole fehlen, wenn Straßen unter Gebäuden hindurchführen. Das wird vermutlich an falschem Tagging liegen. Jedoch wäre es vielleicht sinnvoll, auch alle Stellen, an denen Straße und Gebäude auf gleichem Layer liegen, geeignet zu kennzeichnen.
Beispiele in Hamburg: Mexikoring und Hudtwalckertwiete. Ersteren habe ich inzwischen geteilt und mit einer 3.9m Höhenbeschränkung versehen.

Wenn die Karte nicht sehr häufig aktualisiert wird, wäre ein Button gut, um den Eintrag als erledigt zu markieren, und damit bis zum nächsten Update zu unterdrücken. Ich bin inzwischen schon auf vom FVGordon mit maxheight getaggte Brücken getroffen und er wird sicher auch von mir getaggte Brücken vorfinden, wenn nicht schon geschehen. Ein Update der Karte wäre zumindest hier aus lokaler Sicht schon wünschenswert.

Gruß, slhh

Hallo mmd,

nun werden alle kreuzenden Wege an Brücken als “noch zu bearbeiten” angezeigt, auch wenn dort schon eine Höhenbeschränkung oder none eingetragen ist - nur maxheight:physical=* wird jetzt als “bearbeitet” ausgewertet.

@sihh: Ja, Du bist mir schon aufgefallen, dass Du auch Höhenbeschränkungen hier in der Stadt einträgst.

Grüße,
Franz

Hallo Franz,

das Problem ist mir gerade auch aufgefallen, als ich mir die Edits von slhh in der City Nord angesehen habe. Die korrigierte Version des Scripts lief so gegen 16:50. Hilft ein erneutes Laden der Seite, oder besteht das Problem aktuell immer noch?

Gruß,

Ja, neu Laden hat jetzt geholfen.

Danke,
Franz

Prima! Besten Dank für’s Testen.

Hallo,

den ersten Punkt hab ich über das Changeset auf openstreetmap.org nachvollziehen können, reverten in JOSM kann ich nicht.
Gelöscht habe ich es wahrscheinlich indem ich mehrere Teilstücke “combined” habe. Dann müsste doch eine ID auf der Liste mit den gelöschten Objekten auftauchen. Dabei hab ich dann wohl die existierende Höhenangabe übersehen. Ich glaube aber nicht, dass die Angabe auf allen Teilstücken unter allen Brücken vorhanden war.
Ist aber jetzt egal, jetzt passt es :D.

Das mit der Clusterung ist jetzt auch klar. Beim ersten Gebrauch war es für mich nicht ganz eingängig, weil ich manchmal mehrere Symbole sah, das war aber nur an Stellen, wo zwei Fahrbahnen unter den Brücken vorhanden sind.

Grüße,
Daniel

Hallo mmd,

Danke für die Aktualisierung und Verbesserungen. Dass einige von mir und FvGordan seit Freitag abend eingetragene Daten das Symbol noch nicht unterdrückt haben, wird vermutlich daran liegen, dass die Datenbasis minimal älter ist als angegeben.

Die Unterdrückung der Symbole durch maxheight:physical halte ich nur bedingt für gut:
Sofern es sich um einen highway=service handelt, der durch ein Gebäude führt, ist es wohl so sinnvoll, um auch diejenigen Hofeinfahrten abdecken zu können, die kein Schild haben aber ggf. eines haben müßten. Nach meinem Eindruck sind viele unbeschildert aber trotzdem weniger als 4m hoch.

In sonstigen Fällen kann wohl eine maxheight:physical mit einem Wert größer oder gleich 4.5 als ausreichender Ersatz für maxheight=none angesehen werden.
Ist hier die maxheight aber kleiner 4.5, so sollte in diesem Fall ein Fehlersymbol gesetzt werden, wenn maxheight nicht eingetragen ist. In diesem Fall muss das Schild zwingend vorhanden sein und wird dies bei einer öffentlichen Straße auch sein, so dass maxheight gesetzt sein müßte.

Gruß slhh

Hallo,

die Datenaufbereitung läuft mit dem germany.osm.pbf von Geofabrik, das immer recht früh am Morgen unter http://download.geofabrik.de/openstreetmap/europe/ zur Verfügung steht. Cut-off-Zeitpunkt für diesen Extrakt war 2012-10-12T18:47:54Z (lt. osmconvert germany.osm.pbf --out-statistics). Vielleicht baue ich mal diesen Zeitstempel in die Karte ein anstelle der doch eher ungenauen Information, von welchem Tag der Extrakt war.

maxheight:physical macht die ganze Sache doch etwas kompliziert, vor allem die Sache mit den Hofeinfahrten ist im Moment nicht zu lösen. Das hängt damit zusammen, dass aus Performancegründen nur highway=* und railway=* extrahiert werden ([1]). Mit den buildings würde zum einen das Datenvolumen massiv ansteigen und das Laden der DB auf der Mini-Cloud-Instanz wahrscheinlich gar nicht mehr funktioneren. Ebenfalls scheint mir das Ermitteln der Schnittpunkte zwischen Straßen und Gebäuden für ganz Deutschland extrem lange zu dauern. Falls jemand Erfahrung damit hat oder diesen Teil der Daten in endlicher Zeit aufbereiten kann oder eine passende Karte kennt, bitte gerne Feedback. Keep right! meldet für Straßen/Gebäude-Schnittpunkte leider auch keine Fehlermeldungen.

Geändert habe ich jetzt das Verhalten, wenn maxheight fehlt sowie

  1. maxheight:physical fehlt → Fehlersymbol wird angezeigt

  2. maxheight:physical zwar angegeben, aber der Wert ist nicht numerisch (Beispiel: “5,3m” anstelle “5.3”) → Fehlersymbol wird angezeigt. Ausnahme: maxheight:physical=none wird nicht als Fehler angezeigt

  3. maxheight:physical angegeben und numerisch, allerdings ist der Wert kleiner 4.5 → Fehlersymbol wird angezeigt

Mit dieser Änderung wird das Beispiel von Franz aus Post #584 wg. Punkt 3 wieder als Fehler dargestellt. highway=service, service=driverway auszuschließen wäre noch eine Option, allerdings ist das Ergebnis dann irgendwann gar nicht mehr nachvollziehbar. Wie gesagt, das Konzept “Hofeinfahrt” ist nur über Tags am Weg zu erkennen.

Gruß,

[1] Details zur Aufbereitung siehe Mini-Howo

Hallo mmd,

im Zusammenhang mit maxheight:physical halte ich das Erkennen von Hofeinfahrten für unproblematisch. Dabei geht es doch nur darum, die Fehlermeldung zu unterdrücken. Dafür kann man doch sinnvolles Tagging mit tunnel=building_passage voraussetzen.

Dennoch ist es schade, wenn man die Überlappung von Gebäuden und Straßen nicht berechnen kann, da man somit falsch getaggte Durchfahrten der maxheight Prüfung insgesamt nicht zugänglich machen kann. Siehe dazu die schon genannten Beispiele Mexikoring und Hudtwalckertwiete in Hamburg. Dies könnte z.B. auch Stadttore mit falsch getaggter Durchfahrt betreffen, die ja häufig eine Höhenbeschränkung haben.

Ich kann mir gut vorstellen, dass die Prüfung der Überlappung von Gebäuden und Straßen für ganz Deutschland sehr viel Zeit kostet (zumindest wenn man Datenbankabfragen und keine dafür speziell optimierte Software einsetzt). Wäre es da vielleicht ein Ansatz, abschnittsweise nach derartigen Überlappungen zu suchen und dann gleich einen OSB Eintrag dafür zu generieren? Zumindest braucht man dann die langwierigen Berechnungen nicht für jedes Kartenupdate zu wiederholen.
Falls keine maxheight Angabe vorhanden ist, kann der Bug-Eintrag natürlich auch gleich die Aufforderung enthalten, die maxheight mit einzutragen, falls das Objekt ohnehin zur Bugbearbeitung besichtigt wird. Man sollte hier die Besichtigung aber nicht erzwingen, da viele deratige Bugs auch mit den Bing Bildern abzuarbeiten sein dürften.

Gruß slhh

Soweit uns maxheight:physical keine Lösung für die unzureichend beschilderten Hofeinfahrten bietet, können wir auf die Auswertung dieses Tags wohl völlig verzichten.
Laut Taginfo gibt es ganze 3 Ways die mit einem Wert (größer oder) gleich 4.5 getaggt sind. Diese drei Ways können wir dann auch noch mit maxheight=none versehen.
Insgesamt ist maxheight:physical weniger als 200 mal verwendet.

Hallo,

Wie wolltest Du maxheight=* aus Bing-Bildern ablesen?

tunnel=building_passage wird laut Taginfo z.Z. 953 mal verwendet (1x Neuseeland, 5x USA, 3x Finnland, 1x Schweden, 3x England, 16x Italien, 2x Belgrad, 8x Frankreich, Rest: Österreich (wenige) und Deutschland) und tunnel=passage 136 mal (5x in den USA, 1x Madrid, 1x Malta, 6x Italien, 1x Dänemark, 1x Belgien, Rest: Österreich (wenige) und Deutschland).

Franz

Das geht natürlich gerade nicht. Dagegen kann der primäre Bug, dass der Weg mit einem Gebäude kollidiert, ohne mit tunnel=building_passage etc. getaggt zu sein, vermutlich oft auf Basis von Bing Bildern gelöst werden. Daher wollte ich erreichen, das jemand, der es so macht, den Bug ohne schlechtes Gewissen schließen kann, ohne die Stelle besichtigt zu haben, um auch noch maxheight einzutragen. Nachdem der primäre Bug dann beseitigt ist, meldet die maxheight Karte dann die fehlende Höhenangabe.
Wenn allerdings ohnehin jemand die Stelle für den primären Bug besichtigt, sollte er natürlich auch gleich die maxheight mit erkunden.

Da dachte ich: ‘Tu mal was für die LKW’s’ und habe maxheight=none an einige mir bekannte Stellen getaggt.
Aber OSMI gefällt das gar nicht :roll_eyes:
http://tools.geofabrik.de/osmi/?view=highways&lon=7.82049&lat=48.34095&zoom=14&opacity=0.55

Ich habe gerade Frederik informiert.

Hallo Michael

Wo ist das Problem?
OSMI (Highway-View) zeigt das als zusätzliche Attribute an.
OSMI kennt halt maxheight=none noch nicht.

Edbert (EvanE)

das Problem ist, dass irgendjemand durch OSMI meint, dieser “ungewöhnliche” tag müsste geändert oder gelöscht werden. Motto: “Der Inspektor hat immer recht.”

Hallo Michael

ACK, das kann in der Tat ein Problem sein.

Edbert (EvanE)

Hallo

Die KW 43 wieder mal abgegrätscht.
eine eingetragen 3.7 Oberaussen L 91
www.openstreetmap.org/?lat=50.98206&lon=6.67218&zoom=17

Hier sind es 4 m und einmal none
www.openstreetmap.org/?lat=51.52189&lon=6.99678&zoom=16
schon eingetragen.
Es geht voran denke ich ?

Gibt es mal wieder eine neue Zahl ?

Ich mach mir das jetzt noch einfacher:
Nüvi antippen 1 eingeben speichern fertig.

1 z.B für none
2 für 4 m
usw.
Zu Hause den Speicher auslesen und da hab ich alle Brücken.
In KW 44 hab ich 57 Stück angetippt wo ich alle übrprüfen will ob eingetragen.
Beste Grüße