Brückenhöhen eintragen in die OSM Karte

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)

Super, vielen Dank für’s Testen. Weil man nicht mit zuvielen offenen Sachen ins neue Jahr starten soll, gibt jetzt noch den JOSM Edit Link links unten. Klickt man auf einen Way oder Knoten, wird ein Popup mit weiteren Details sowie einem zweiten JOSM Edit Link angezeigt (beide Features habe ich übrigens bei SunCobalt und misterboo geklaut, danke!).

Brücken mit unterschiedlichem Layer haben jetzt eigene Farben (kompliziertes Beispiel hier - kann bis zu 10 Sekunden dauern, also Geduld). Über den Parameter lang=en werden die Texte in englisch angezeigt, wie beim komplizierten Beispiel zu sehen.

Wünsche ebenfalls einen guten Rutsch :slight_smile:

  • Beide Link-Varianten und das Popup funktionieren (wie nicht anders erwartet).
  • Die verschiedenen Farben je nach Layer sind erst einmal ungewohnt aber nützlich.
    Dein Beispiel ging übrigens flott (wenige Sekunden). Verwendet du einen Cache?
  • Der Sprachumschalter funktioniert ebenfalls.
    Keine Angabe → deutsch Angabe =/= de|en → englisch.
    Sind weitere Sprachen geplant?

Jetzt noch eine wichtige Frage:
An diesem Autobahnkreuz sind alle motorway(_link) als Straße unter einer Brücke nicht markiert. Ist das Absicht, weil das (mindestens in DE) nicht kleiner 4m sein darf, oder ist das ein Versehen. Im ersten Fall, muss bei Erweiterung auf andere Länder geprüft werden, ob dort die Vorschriften (und die Realität) auch so strikt sind.

Edbert (EvanE)

:slight_smile:

sehr praktisch! :wink:

Wir [http://wiki.openstreetmap.org/wiki/Comenius_OSM_and_Tourism] haben in unserem Projekt u. a. den OSM QA Editor http://editor.osmsurround.org/ in verschiedene Sprachen TR, PT, RO und SL übersetzt.
Adrian hat die Anzeige der jeweiligen Sprache über die Einstellungen des Brausers gelöst.

Guten Rutsch haben wir hinter uns, :slight_smile:
deshalb Dir und allen ein “Gutes Neues”

Die Daten werden inzwischen ausschließlich von der Overpass API bereitgestellt und waren wahrscheinlich noch vom Overpass Server selbst gecached. Für die neue Karte benötige ich keine eigene Datenbank mehr, dein Browser redet direkt mit der Overpass API.

Wenn die Oberfläche mal einigermaßen fertig ist, spricht eigentlich nichts dagegen, auch noch weitere Sprachen anzubieten. Wie das geht, sieht man ganz gut hier in der i18n.js Datei am Beispiel deutsch/englisch.

Ja, das ist so gewollt, Bisher wurden motorway und motorway_link nicht berücksichtigt. Darin unterscheidet sich die neue Auswertung auch nicht von der alten. Falls es Länder geben sollte, in denen die false positive-Rate (also Falschmeldungen) nicht zu hoch ist, könnte man ggfs. nochmal überlegen, diesen Fall ebenfalls zu betrachten. Für Deutschland sehe ich bisher diese Notwendigkeit nicht.

Noch zwei andere Punkte:

  1. Beachtung von maxheight nodes, die in der Nähe einer Brückenkreuzung bzw. im Tunnel liegen: im Laufe des Threads gab es abweichende Meinungen dazu, ob Straßen in mehrere Abschnitte aufgeteilt werden sollen oder ob ein Knoten auch schon ausreicht. Ich habe in England in der Stadt Rugby ein maxheight-Tagging gefunden, bei dem das maxheight-Tag nicht am Weg, sondern an einem einzelnen Knoten dieses Weges gesetzt wurde. Dabei befindet sich dieser Knoten in der Nähe der zugehörigen Brücke. Diese Konstellation wird jetzt auch im Overpass API Prototyp berücksichtigt!

Am Beispiel der Crick Road (A428) sieht man, dass an einer Eisenbahnbrücke mit maxheight-Knoten in der Nähe kein Fehler markiert wird, etwas weiter Richtung Nord-Ost wird dagegen ein Fehler markiert, da der maxheight-Knoten zu weit weg liegt. Fehler bedeutet in diesem Falle, dass die Bahnbrücke blau markiert ist, während der Weg darunter rot markiert ist. An diesem Schnittpunkt kann es also zu Problemen kommen. Auf der Karte werden immer die kompletten OSM-Ways angezeigt, die auch mal einen Kilometer oder länger sein können - also immer auf den Schnittpunkt achten. Für Wege mit tunnel=* gilt: ist einer der Knoten dieses Weges mit maxheight getaggt, so wird ebenfalls kein Fehler mehr gemeldet.

Die jeweiligen Werte zu den roten maxheight-Punkten sieht man übrigens, wenn man unten links auf den Knopf “Label ein/aus” klickt.

Ob user:Win32netsky diese maxheight-Knoten auch so in seiner LKW-Karte berücksichtigt, kann ich nicht sagen. Laut seiner Benutzer-Seite im Wiki spricht aber einiges dafür.

  1. Übernahme fehlender Features in neue Karte:

Bisher wurden schon einige Features der alten Karte in die neue, Overpass API basierte Karte übernommen. Was noch fehlt sind:

Suche
Aktuellen Kartenausschnitt und selektierte Layer merken (mit Cookies)
Aktuelle Geoposition ermitteln und Karte entsprechend ausrichten
OpenStreetBug-Integration: Anzeige von Fehlern mit “#maxheight” bzw. Erfassung neuer Fehler direkt aus der Karte heraus
Möglichkeit, die Fehlerstellen als GPX zu exportieren, z.B. für Garmin unterwegs
Mobile Version

Bitte gebt mir kurz Rückmeldung, welche dieser Features mit in die neue Karte überführt werden sollten, oder was eher verzichtbar ist.

Gruß,
mmd

Ah ja, Absicht weil <4m auf Autobahnen nicht zulässig ist.
Das ist bei Eisenbahnen im Grunde genau so. Durch das Lichtraumprofil ist eine Mindesthöhe für Brücken über eine Eisenbahnstrecke klar festgelegt.

Hmmh, gefällt mir nicht, da maxheight eigentlich eine Eigenschaft des Weges/Wegstückes ist.
Aber es ist Sache der Auswerter, ob sie das zulassen wollen oder nicht.

In einer Situation jedoch verwende ich das selber und zwar wenn ein Parkplatz/Parkhaus/Tiefgarage als ein Punkt erfasst ist. Dann erfasse ich die Einschränkungen (maxheight/-speed/-weight) an dem entsprechenden Knoten. Gerade Tiefgaragen kann man ja kaum in ihren Abmessungen erfassen. Es bleibt also bei einem Knoten an der Ein-/Ausfahrt mit allen für die Tiefgarage erkennbaren Einschränkungen.

  • Suche halte ich für wichtig.
  • Ebenso ist das Merken des Kartenausschnitts sinnvoll.
  • OpenStreetBug-Integration: Wenn es nicht zuviel Arbeit macht!
    Die Karte zeigt eigentlich alles in diesem Zusammenhang wichtige.
  • GPX Exportieren: Nett, für mich nicht wichtig.
  • Eine Mobile Version ist mir nicht wichtig. Für andere mag das einen wichtigen Schritt darstellen.

Edbert (EvanE)

  • Suche und Kartenausschnitt merken sind für die Benutzbarkeit wichtig. Insbesondere reduziert dies auch die Belastung der API.

  • Mobil-Version und Geoposition ermitteln brauche ich selbst nicht, sehe aber schon einen Nutzen für andere Mapper.

  • Den GPX Export habe ich bisher nicht getestet. Die Daten auf dem Garmin zu haben, wäre schon hilfreich, wenn man längere Touren macht. Dann braucht man aber auch eine Exportmöglichkeit für einen großen Bereich. Das wird dann wahrscheinlich für die API problematisch. Für einen kleinen Ausschnitt würde ich die Karte eher ausdrucken. Da kann man sich dann auch gleich passend Notizen zu den erkundeten Höhen machen. Gute Druckbarkeit auch in Schwarzweiß wäre mir daher wichtig.

  • OSB-Integration habe ich bisher nicht genutzt. Beim Editieren habe ich auch oft festgestellt, dass ich mit einem OSB-Eintrag, so wie ich ihn selbst geschrieben hätte, nicht zurechtgekommen wäre oder sogar fehlerhafte Eintragungen gemacht hätte. Häufig sah die Situation im Editor anders aus, als ich sie auf der Maxheight-Karte interpretiert hatte. Bei einer echten Höhenbeschränkung dürfte es auch schwerfallen, die korrekte Ausdehnung der Höhenbeschränkung in OSB eindeutig zu beschreiben. Daher halte ich die OSB-Integration für wenig hilfreich, zumal Einträge von Personen, die die Karte nicht selbst editieren können, vermutlich noch weniger eindeutig formuliert sein dürften.

Zu den Features schliesse ich mich an, aber zusätzlich fehlt die Legende noch.

Aus Bugfixing- bzw. aus Mapper-sicht wäre noch ein “Grau-weiss”-Layer ganz vernünftig, die Markierungen sind bei mittelgrossem Zoom teilweise recht schwer zu erkennen. (Die Kreise aus der alten Version wären hier vielleicht auch hilfreich)

label an/aus mit im Permalink “speichern” würde ich mir noch wünschen.

Hier habe ich ein Problem mit der Farbgebung entdeckt, die ich mir nicht erklären kann:
http://maxheight.bplaced.net/overpass/prototyp.html?zoom=15&lat=50.94656&lon=11.27559&layers=B0000000TTFFFFFFTTTTTT
Rechts (links neben Abfahrt Weimar), rot markiert → korrekte Höhe,
links (links unterhalb Obergrunstedt) rot markiert → keine Höhe vergeben.
Hab ich ein Brett vorm Kopf, oder is da was kaputt?

fehlt vielleicht maxheight=none (kein Verkehrszeichen vorhanden)

ja sicher, ich verstehe nur nicht, warum ein ungetaggtes Objekt eine rote Linie hat und ein (korrekt) getaggtes auch.

P.s. none schreib ich da btw erst dran, wenn ich mir das angeschaut hab.

Vermutung meinerseits:

Dick rot: für LKW (siehe Titel der Karte) nicht geeignet oder unter 4 m
Dünn rot: Vorsicht - keine genaue Angabe vorhanden.

Hallo,

erstmal vielen Dank für eure zahlreichen Rückmeldungen! Bisher habe ich die beiden Themen ‘Suche’ und ‘Kartenausschnitt merken’ in Angriff genommen und Dank großzügiger Unterstützung von misterboo eine neue Oberfläche umgesetzt.

Für mich etwas überraschend waren die Rückmeldungen zur OSB-Integration und dem GPX-Export - da hätte ich gehofft, dass man damit in der Praxis auch arbeiten kann. Vor allem den Punkt “Häufig sah die Situation im Editor anders aus, als ich sie auf der Maxheight-Karte interpretiert hatte.” von slhh fand ich aufschlußreich. Hier würde mich interessieren, ob sich das auf die alte (mit Symbolen) oder neue Karte (mit Linien) bezieht. Beide Punkte habe ich auf jeden Fall recht weit nach hinten auf die Liste gesetzt, es ist fraglich ob es die beiden nochmal auf die neue Karte schaffen.

Mit der neuen Oberfläche kann man sich die Karte zumindest rudimentär auf mobilen Geräten ansehen, mal sehen, ob ich da noch weitermache.

Zur besseren Druckbarkeit der Karte vor allem in Schwarz/Weiß: ich denke, mit den beiden Layern bw-mapnik und bw-noicons ist immerhin der Hintergrund s/w, allerdings dürfte der Kontrast zu den bunten Linien beim s/w-Ausdruck nicht sonderlich gut sein. Eine einfache Option wäre, die Mapnik-Karte blasser darzustellen, am besten über einen Schieberegler. Prinzipiell könnte ich auch die Symbole aus der alten Karte nochmal erzeugen, da die Schnittpunkte sowieso ermittelt werden.

“label an/aus mit im Permalink “speichern” würde ich mir noch wünschen.” → sollte kein Problem sein, notiert.

Das hängt damit zusammen, dass es für die Karte noch kein fertiges Farbkonzept gibt, also die Farbe rot zum einen für bestehende und zum anderen für fehlende maxheight=* Tags verwendet wird. Ist sicherlich noch nicht optimal, daran wird noch gefeilt. Im Moment gibt es nur die Unterscheidung in der Liniendicke wie von geri-oc richtig bemerkt.

Natürlich fehlt im linken aufklappbaren Bereich auch noch eine Legende, die folgt demnächst noch.

Gruß,
mmd

Hallo,

die Transparenz der Karte lässt sich jetzt über einen Schieberegler in der linken “Sidebar” nach eigenem Wunsch anpassen. Die Karte kann so blasser dargestellt werden, die farbigen Linien sind dadurch besser erkennbar. Bitte probiert mal aus, ob das beim Schwarz-Weiß-Druck weiterhilft.

Beispiel: http://maxheight.bplaced.net/overpass/prototyp.html?zoom=15&lat=50.71359&lon=7.12858&layers=B0000000TFFFFFFFFFFFTT&label=T&opacity=18

Gruß,

Ganz grosses Damentennis, danke.

Dass bezog sich auf die alte Karte. Mit der neuen Karte sollte einem Mapper, der sich auch mit deiner Karte etwas auskennt, vielfach möglich sein, die tatsächliche Situation besser zu interpretieren. Ob dies allerdings jemanden, der nicht in der Lage ist, diese einfache Änderung in OSM selbst vorzunehmen, damit in die Lage versetzt wird, einen OSB Eintrag so eindeutig zu formulieren, dass ihn hinterher ein Mapper ohne Ortskenntnis korrekt umsetzen kann, möchte ich bezweifeln. Weiterhin sollte man eine echte Höhenbeschränkung auch in der Ausdehnung eintragen, in der sie gültig ist. Hier wird eine unmissverständliche Beschreibung OSB auch schwierig.

Vielleicht wäre es hilfreich eine abgespeckte OSM Einführung zu für genau derartige Bearbeitungen zu schreiben und diese in der Karte zu verlinken, um potentiellen Informationslieferanten den direkten Einstieg bei OSM zu ermöglichen.

Funktioniert prinzipiell gut und hilft nicht nur beim Drucken. Müßte dann mit dem fertigen Farbkonzept überprüft werden. Eventuell benötigt man da ein spezielles Farbkonzept für die Druckausgabe.

Als Default-Einstellung sollte man einen Wert von 70-80% verwenden, da die Karte dann noch gut erkennbar ist, die Linien aber auch am Bildschirm deutlich hervortreten.

Optionale Symboldarstellung halte ich für sinnvoll.

Die Umstellung der Maxheight Karte auf die Overpass API ist soweit abgeschlossen. Alle bisherigen Links werden automatisch auf die neue Version umgeleitet, die alte Version wird nicht weiter gepflegt.

Bis auf die OpenStreetBug-Integration haben die meisten Funktionen überlebt, es gibt also wieder optional die roten Symbole für Wege unter Brücken und auch den GPX-Export, den ich persönlich ganz praktisch fand. Der GPX-Export läuft aktuell allerdings nur in Firefox und Chrome, nicht aber IE. Alle anderen Funktionen sollten aber auch in IE8+ klappen.

Eher als Spielerei gedacht ist ein Simulationsmodus, mit dem man maxheight und maxweight über einen Schieberegler variieren kann. Dort kann man Höhe/Gewicht eines Fahrzeugs einstellen und sieht dann auf der Karte, wo es Probleme gibt (rot) oder alles gut ist (blau). Grün bedeutet: dort hat jemand maxheight=none eingetragen (auch alles gut).

Sowohl GPX-Export als auch der Simulationsmodus sind über die linke Sidebar erreichbar. Auch die Darstellung der Schnittpunkte (als rotes Symbol oder Linie) lässt sich dort einstellen.

Übrigens: Über die Tastenkürzel Strg-Cursor Link/Hoch/Rechts lassen sich die einzelnen Panels ein/ausklappen → mehr Platz zum Ausdrucken.

Link zur Testen

Link zur Dokumentation Mapheight Map im Wiki

Gruß,
mmd

Die neue Karte hat natürlich einige Vorteile gegenüber der alten Karte, dennoch bietet sie leider keinen hinreichenden Ersatz, da die nötige Übersicht, wo noch Höhenangaben fehlen, auf gröberen Zoom-Stufen nicht mehr bieten kann.
Eine Kombination aus beiden Karten, wobei die alte Karte bei den gröberen Zoom-Stufen eingesetzt wird, wäre für die Anwendung ideal.

Natürlich habe ich auch Verständnis, dass du dir die Aktualisierung der Daten der alten Karte ersparen willst. Wenn man für die feinen Zoomstufen aktuelle Daten aus der Overpass-API verwendet, kann die Update-Rate für die gröberen Zoomstufen jedoch deutlich reduziert werden. Es wäre auch denkbar, deine Datenbank nur einmalig aus der OSM-Datenbank zu füllen und dann immer wenn jemand einen Ausschnitt auf feiner Zoom-Stufe betrachtet und somit die passenden Overpass-Anfragen erfolgen, die Ergebnisse dieser Anfragen zur Aktualisierung des entsprechenden Ausschnitts deiner Datenbank zu verwenden. Vermutlich wäre es dazu sinnvoll, die Overpass-Anfragen über deinen Datenbankserver umzuleiten.

Ein Fehler bei der Anzeige der vorhandenen Höhenbeschränkungen, der mir beim Test aufgefallen ist: Es kann passieren, dass nur die punktförmigen Höhenbeschränkungen angezeigt werden. Vermutlich wird dabei eine Overpass-Anfrage gescheitert sein, aber man sieht der Statuszeile nicht an, dass dies der Fall ist.

Weitere Verbesserungsvorschäge:
*Die JOSM Edit-Links sind schon praktisch. Sollte man aber nicht besser auch Potlatch 2 unterstützen, zumal P2 für das Eintragen der Höhenbeschränkungen absolut ausreichend ist. Entweder sollte dazu der Editor im Sidebar wählbar sein, oder der Edit Link prüft ob JOSM oder ein anderer Editor über das Fernsteuerinterface erreichbar ist und startet andernfalls P2.
*Die Sidebars sollten im eingeklappten Zustand beschriftet sein. Dies gilt insbesondere für den linken, wenn dieser anfänglich eingeklappt ist.
*Der Titelblock sollte auch intuitiv mit der Maus abschaltbar sein und nicht nur mit Ctrl-Up.

Ich habe gerade nochmal in der alten Karte nachgeschaut: dort wurden die Symbole erst ab Zoom-Level 12 angezeigt - das ist in der neuen Karte unverändert, bis auf die beiden Layer für Wege unter (Eisenbahn-)Brücken. Aus Performancegründen sind diese aktuell noch auf Level 13 und mit einem Timeout von 10 Sekunden beschränkt. Das führt in dicht besiedelten Gebieten dazu, dass man näher ranzoomen muss, bevor die Daten angezeigt werden. => Erledigt, Zoomlevel ist jetzt auch für Wege unter (Eisenbahn-)brücken auf 12 gesetzt, Timeout bleibt bei 10 Sekunden.

Natürlich könnte man jetzt einfach den Timeout höher setzen und die Funktionalität wäre wie früher, wenn auch etwas langsamer. Solange Roland den around Call noch nicht weiter optimiert hat, werde ich die Vorgehensweise nicht näher beschreiben, um den Server nicht unnötig zu belasten. => Erledigt, Overpass API Version 0.7.2 hat das Around-Statement signifikant verbessert. Großer Dank dafür an Roland!