Brückenhöhen eintragen in die OSM Karte

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

ist das jetzt ein “ich mappen Brückenhöhen”-Tagebuch?

42 ?

Ist dort wirklich keinerlei Objekt welches die Höhe beschränkt? Oder wird damit ausgedrückt, dass die ohne Sondergenehmigung zulässigen 4,xm durchgehen?

Hallo

Das none steht dafür das es keine Beschilderung an der Brückendurhfahrt gibt. Also die gesezlichen 4 m + Sicherheitsbereich sind dort möglich.

44611, allerdings Tendenz leicht ansteigend in den letzten zwei bis drei Wochen.

Ach ja damit ist die Zahl der Fehler auf der maxheight Karte gemeint.

Deutschland Überblick - je dunkler der Blauton, desto mehr fehlende maxheight-Tags unter Brücken. Maximale Zahl in Berlin mit 618. Hamburg fehlt (war nicht im Admin 6-Level Shapefile drin).

Hallo
Habe ich auch schon geplante Strecken /Brücken geteilt.
Ich teile die Straße unter der Brücke immer.

Das es nach meiner Meinung das vernüftigste ist?
Und ich entferne das maxheight auch wenn es auf der ganzen Straße liegt. (Wegen den Abzweigungen)

PS: Das letzte Posting war nur so gemeint das das mit dem Handy unterwegs für mich schwieriger ist.
Da lag da mit dem Garmin antippen 1 eingeben speichern besser.

Ich denke mal wir sind schon bei 57000 ?
Eventuell kann man ja in der Legende die aktuelle Zahl mit angeben, oder einen Zähzler der rückwärts geht, sofern das möglich ist?
Beste Grüße

Wenn Du das so machst, solltest Du aber auch gleich die physikalische Höhe mit ausmessen. :slight_smile:
Denn dann hat die Unterteilung wenigstens ihre Berechtigung, da maxheight:physical natürlich immer auf den Bereich unter der Brücke beschänkt sein sollte.

Wenn man jedoch den Weg unnötigerweise für ein maxheight=none teilt, schafft man sich nur Widerstand gegen dieses Tag. Wenn die Karte grob 50000 Fehler anzeigt, würde eine derartige Aufteilung 100000 neu Wege erfordern (meist wird einen Weg in drei Wege geteilt).

Und auch bei einer ausgeschilderten Höhenbegrenzung ist die Begrenzung auf den Bereich unter der Brücke manchmal falsch. Maxheight ist die gesetzliche Höhenbeschränkung und diese gilt doch in dem entsprechend beschilderten Bereich. Oft ist es nur ber Bereich unter der Brücke, aber teilweise ist dieser Bereich auch sehr weit ausgedehnt. Wenn natürlich mit einem Zusatzschild wie 100m die Höhenbeschränkung nur angekündigt wird, gehört dieser Bereich natürlich nicht dazu.

Aus diesen Gründen ist die Aufteillung vor der Erkundung nicht sinnvoll. Eine Ausnahme sind vielleicht Hausdurchfahrten, weil man hier schon für tunnel=building_passage teilen muß.

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.

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.

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.

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.