als kleines Tribut an die fleißige Hamburger Community habe ich die Entwicklung der Maxheight Tags im Zeitraum Januar 2010 - Januar 2014 einmal auf der Maxheight Map dargestellt:
Die Daten für die Screenshots stammen direkt von der Overpass API mit Version 0.7.50. Dabei verwende ich allerdings eine lokale Testinstallation, die mit der Historie für Deutschland läuft.
Vielen Dank an Roland für das tolle neue Attic Feature in der Overpass API, ohne das diese Zeitreise auf der heutigen Maxheight Map nicht möglich wäre. Sobald die Datenbank für die offizielle Overpass API Instanz neu aufgebaut wurde, sollten Daten für vergleichende Auswertungen weltweit bis Sommer 2012 zur Verfügung stehen (momentan nur bis Juni 2014).
JOSM bemängelt ein maxheigt=none - (wird deshalb manchmal gelöscht) - weil kein Wert angegeben ist. Wie soll eine Straße unter einer Brücke ohne Beschränkung eingetragen werden - bitte auch im WIKI festlegen.
Daran bin ich auch brennend interessiert. Habe hier bei mir gleich mehrere Autobahnbrücken, die über ganze Täler gehen. Habe ja schon überlegt dort dann einfach geschätz irgendwas zwischen 60m und 100m einzutragen, damit der Hinweis/Fehler in der Map verschwindet … das kanns aber auch nicht sein.
Hat mich auch schon irritiert: User DD1GJ hat mich darauf hingewiesen, dass das verwendet wird, um einzutragen, dass auf “keine Beschränkung” überprüft wurde. Dient also zu einer Unterscheidung vom default “unknown” (der nicht eingetragen wird).
Vielleicht würde so was wie ein “maxheight=none (checked)” Löschungen vermeiden.
Dieses Tag maxheight=unsigned habe ich in Taginfo 69 mal, aber nicht im Wiki unter maxheight gefunden. Meine Übersetzung für *unsigned *bedeutet *Vorzeichenlos *- da tippe ich auf einen Tippfehler und der Autor meinte vielleicht unassigned (= kein Wert zegewiesen).
Möglicherweise sollte das Wort unsigned auch nicht ausgeschildert heißen. Aber wenn ich bei dict.leo.org nachsehe, ist mir not_signposted eine passendere Übersetzing dafür. Da aber maxheight=none am weitesten verbreitet ist, sollten wir dabei bleiben, damit der JOSM-Validator nicht ständig neue Worte lernen muss, die statt einem numerischen Wert auch ok sind.
So, da ich auch auf die Problematik gestoßen bin, würde ich gerne auch noch meine Meinung zu maxheight=none und Alternativen hier kund tun.
maxheight gibt das rechtliche Limit an Fahrzeughöhe für die jeweilge Stelle an. Von daher ist für mich der Wert none nicht korrekt, aber mit Sicherheit besser als kein Wert. Wie bereits zuvor angemerkt, ist die Sache bei maxspeed anders, da es tatsächlich keine feste Grenze vom Gesetz her gibt.
Die Alternative unsigned, die sich an mehreren Stellen im Wiki findet, ist sprachlich nicht haltbar. Eine kurze und sprachlich akzeptable Alternative für diesen Sachverhalt hätte ich aber auch nicht. Allerdings ist jeglicher Hinweis auf fehlende Schilder aber auch nur eine Symptombeschreibung. Was zum Ausdruck gebracht werden soll ist ja schließlich die Freigabe bis zur generellen Höchstgrenze, die wahrscheinlich in allen Ländern in irgendeiner Art existiert. Daher ist default ein besserer Wert. Eventuell könnte man auch max_legal oder ähnliches verwenden, da sollte man eventuell mal ähnliche Tag-Werte abgrasen.
Für die tatsächliche Durchfahrtshöhe existiert dann ja noch maxheight:physical, was sicherlich für alle Brückendurchfahrten mit maxheight=default zusätzlich sinnvoll wäre. Dazu muss die Brücke aber vermessen werden oder auf Katasterdaten zurückgegriffen werden können, das ist also nicht zu erzwingen. Für die Tourenplanung für LKWs ist es aber auch nicht zwingend erforderlich.
Eventuell könnte die Diskussion aus diesem Thread auch ins Wiki getragen werden, um einen Konsenz zu erreichen und die Situation engültig glatt zu ziehen?!
mir ist in letzter Zeit aufgefallen, dass einzelne Mapper (zu nennen wäre hier vor allem slhh) inzwischen auch auf Mapillary zur Ermittlung der maxheight-Tags zurückgreifen.
Diese Idee fand ich ganz interessant und möchte sie mit einem experimentellen Mapillary-Layer in der Maxheight Map etwas pushen.
Ein Klick auf einen der gelben Punkte zeigt links unten ein kleines Vorschaubild. Ein Klick auf das Bild zeigt eine grössere Version in einem eigenen Fenster.
Insgesamt hat Mapillary zur Erfassung der Brückenhöhen ein sehr großes Potential.
Es ist allerdings regional sehr unterschiedlich. Neben Städten/Regionen, die kaum Mapillary Bilder haben, gibt es auch Städte/Regionen, die zwar einiges an Bildern haben, wo aber die Ausbeute zur Brückenhöhenerfassung sehr bescheiden ist. Letzteres ist oft der Fall, wenn die Bilder dort im Wesentlichen von Radfahrern gemacht wurden, da diese die häufig von Brücken überspannten großen Straßen nicht befahren. In einigen Regionen sind die Bilder auch mit übermäßig großem zeitlichen Abstand bei der Fahrt aufgenommen, so dass man nur zufällig mal ein Bild in passender Entfernung zur Brücke findet.
Andererseits gibt es Städte/Regionen, wo das wirklich excellent funktioniert. Z.B. konnte ich in Jena die fehlenden Brückenhöhen fast komplett erfassen. Auch im Süden der Niederlande, wo vorher Brückenhöhen kaum erfasst waren, konnte ich eine sehr hohe Abdeckung erreichen.
Damit niemand beim Ausprobieren frustriert ist, möchte ich darauf hinweisen, dass ich in den letzten etwa 3 Monaten in D, A, CH, NL und in Malmö im Wesentlichen alles abgegrast habe, wo ich Potential gesehen habe. Sicherlich habe ich nicht hundertprozentig alles erwischt, aber an die 3000 neue Maxheight Tags dürfte es gebracht haben. Daher bitte nicht wundern, wenn regional nur für die verbleibenden Brücken ungeeignete Mapillary-Bilder gefunden werden. Ggf. muss man dann warten, bis neue Bilder hinzugekommen sind.
Einen Mapillary Layer wollte ich auch schon vorschlagen, allerdings hatte ich noch Bedenken bezüglich der Übersichtlichkeit der Darstellung. Durch die Punktdarstellung ist dies jedoch sehr gut gelungen. Zudem bringt die Punktdarstellung auch funktional einen Zusatznutzen.
Für die praktische Anwendung habe ich noch ein paar Verbesserungsvorschläge:
-Es feht eine Anzeige der Aufnahmerichtung, die zwar nicht immer korrekt ist, aber dennoch eine wertvolle Orientierungshilfe ist. Um die Karte nicht zu überladen, würde ich einen Richtungspfeil als Mouse-over Funktion anzeigen.
-Durch die Punktdarstellung ist der Verlauf des Mapillary Tracks nicht erkennbar. Diese Information ist aber wichtig, da die Fotoposition entlang des Tracks oft grob falsch ist. Da muss man dann einen Track finden, an dem man entlangwandern kann, um die Brücke zu finden. Gerade in Bereichen mit mehreren Brücken ist das Entlangwandern zur Identifizierung der richtigen Brücke essentiell. Darstellungsvorschlag wäre: Als Mouse-over Funktion und/oder bei Selektion des Punktes die anderen zum Track gehörenden Bildpunkte mit hervorzuheben und den Track als Linie darzustellen. Die Linie ist dabei wichtig, da ein Mapillary Track nicht selten mehrfach durch die gleiche Straße führt (insbesondere wenn ein Gebiet systematisch abgefahren wurde).
-Am Foto (auch dem großen) sollte es Vor- und Zurück-Buttons geben, um am Track entlangzuwandern. Dabei muss die aktuelle Position in der Karte dargestellt werden. Das Entlangwandern ist auch wichtig, um Schilder zu finden, die bereits weit vor der Brücke stehen. Dies kommt z.B. in den Niederlanden nicht selten ohne Erkennbarkeit an der Brücke vor.
-Am Foto (auch dem großen) sollte es Zoom-Buttons geben. Oft sind die Bilder so weit entfernt aufgenommen, dass man nur mit extremen Zoom die Schilder sieht.
-Es wäre wichtig, das große Foto permanent neben die Karte legen zu können. Dazu bräuchte man die (optionale?) Funktion, das große Foto immer wieder das gleiche Fenster überschreiben zu lassen. Vielleicht ist es dann sogar sinnvoll, optional immer gleich das große Bild zu laden, wenn der Kartenpunkt angeklickt wird.
-Oft werden einige Mapillary-Tracks erst mit großer Verzögerung angezeigt (das ist auf der Mapillary-Seite nicht anders). Daher wäre ein Status, wann alle Punkte geladen sind, hilfreich. Sonst kann man durchaus den Kartenausschnitt wieder verlassen haben, bevor die Punkte dargestellt werden.
Edit: Das Problem ist recht gut reproduzierbar, bei kleinem Browser-Fenster muss man aber ggf. etwas herauszoomen, damit es auftritt.
Es scheint mir daher eine Limitierung der angezeigten Aufnahmestandpunkte zu sein. In Städten mit hoher Mapillary-Abdeckung (Testbeispiele Jena und Malmö) wird es, abgesehen von extrem hohen Zoom-Stufen völlig unbrauchbar. Hauptproblem ist dabei, dass man nicht erkennt, dass es eine hohe Abdeckung gibt und man daher weiter heranzoomen müßte.
Wenn man das Problem nicht eliminieren kann, wäre es besser, die Mappilary-Anzeige zu unterdrücken und nur eine Aufforderung zum heranzoomen auszugeben, wenn das Limit erreicht wird.
Einige weitere Anregungen:
-Das Datum des Bildes sollte angezeigt werden.
-Es wäre auch ein Filter nützlich, der Aufnahmestandorte, die neuer als ein einstellbares Datum sind, in der Karte hervorhebt. Wenn man eine Stadt auf für unsere Zwecke verwendbare Mappillary-Bilder überprüft hat, möchte man wohl nicht einige Monate später wieder alle als ungeeignet erkannten Bilder erneut überprüfen, nur weil vielleicht einige neue Bilder hinzugekommen sind.
-Mapillary hat bereits eine eingebaute Verkehrszeichenerkennung (dazu gleich mehr). Es wäre daher nutzlich, die Bilder in der Karte hervorzuheben, wo Mapillary für die OSM Truck QA Map relevante Verkehrszeichen erkannt hat. Wenn möglich, wäre es sinvol,l auf niedrigem Zoomlevel, wo insgesamt zuviele Aufnahmestandorte vorhanden sind, exklusiv die Aufnahmestandorte mit diesen Verkehrszeichen zu laden.
Wie die Verkehrszeichenerkennung von Mapillary für unsere Zwecke eingesetzt werden kann, möchte ich an folgendem Beispiel darstellen: http://mapillary.com/map/im/Y0bgStlzoaFHrxVBWhPixQ
Dann unten links in der Karte “Filter” ausklappen und dort rechs unten “Traffic Signs” auswählen. Dann erscheint unter “Trafic Signs” “Filter Trafic Signs”. Dies öffnen und nur “Prohibition/Restictive” selektieren und auf Filter klicken. Dann werden die erkannten Verkehrszeichen in der Karte und unter dem Bild dargestellt.
Ich würden gern das Tagging für große Fahrzeuge etwas pushen (ja, auch aus Eigennutz). Am coolsten wäre wenn man in GraphHopper Maps
ein zusätzliches Overlay mit Markern via Overpass API hätte für normale hints wie access, barrier, ford etc und
dann noch ein zweites Overlay für LKW-spezifische Sachen (max height/weight/width)
Denn auf einigen Karten wird (1) nicht angezeigt bzw. auf keiner einzigen wird (2) angezeigt. Und das macht das Debugging fürs Routing von LKW-Profilen (noch alpha) sehr schwer. Manchmal hab ich da schon Overpass Turbo in nem separaten Tab geöffnet und dann via Tabs hin und her geswitcht ;), aber das ist natürlich keine tolle Lösung. Gerade Endanwender würde mit dem Layer (2) das LKW-Routing besser ‘verstehen’ können. Gerne würde ich auch die “OSM Truck QA Map” da als 3ten Layer mit reinbringen und auf mmd und/oder Github verlinken.
Eigentlich ist es ja jeweils nur eine Overpass-Abfrage (ich würde keine Optionen anbieten) und die Marker irgendwie effizient darstellen. Aber wahrscheinlich würde es bei mir bestimmt Tage dauern, das korrekt und schnell mit JS hinzubekommen ohne Overpass zu sehr zu strapazieren. (ich bin einer der “Wizard”-Nutzer von Overpass Turbo ;))
Evtl. hätte jemand Lust und Zeit mir bei solch einem Unterfangen zu helfen?
Klar, kein Problem. Die Sachen sind nur so alt, dass sie noch für OpenLayers gebaut wurden. Die Overpass Queries selbst kann man aber problemlos auch unter Leaflet einbinden.
