Brückenhöhen eintragen in die OSM Karte

Da lanes schema kenne ich natürlich und hatte deshalb auch maxheight:lanes erwähnt. Problematisch in diesem speziellen Fall wäre, dass dieses Schema die Verwendung der Gegenfahrbahn nicht berücksichtigt.

Der häufigere Fall einen seitlichen Höhenbeschränkung wäre eine zweispurige Straße, wo ein LKW in Fahrbahnmitte fahren muss. Ursache könnte eine Bogenbrücke, eine Gebäudedurchfahrt in Bogenform (z.B. Stadttor) oder auch Bäume sein. Hier hilft uns das lanes Schema überhaupt nicht mehr weiter. Daher sehe ich schon einen gewissen Bedarf, ein neues Tag zu erfinden.

Nun ja, irgendwann muss ein Fahrzeugführer sein eigenes Gehirn einschalten.
Die Entscheidung ob er die linke Fahrspur (= Gegenrichtung) benutzt, muss er/sie abhängig von der aktuellen Situation selber treffen (und ggfs. abwarten bis das gefahrlos möglich ist).

Was die Nutzung der Fahrbahn-Mitte (= beide Fahrspuren belegt) betrifft, gilt obiges, der Fahrzeugführer muss seine eigenen Entscheidungen treffen. In OSM gibt es bisher noch keine Möglichkeit diesen Sachverhalt angemessen darzustellen.

Edbert (EvanE)

Sicher muss der Fahrer vor Ort Entscheidungen selber treffen. Wenn er nach Navi fährt, so muss das Navi aber zuvor auch die Entscheidung treffen, dass diese Straße genutzt werden kann.
Wenn wir jetzt beispielsweise maxheight:lanes=4|3.5 verwenden, so muss dass Navi auch erstmal entscheiden, dass der Fahrer hier die Gegenfahrbahn benutzen kann und somit die tatsächliche Höhenbeschränkung dieser Route nur 4m ist. Für diese Entscheidung bietet das Lanes Schema aber keine ausreichende Datengrundlage.

Dies ist richtig. Allerdings wäre es für den Fahrer schon hilfreich, wenn er durch eine Warnung darauf hingewiesen wird, dass er hier aktiv eine Entscheidung treffen muss und vorher die Umgebung (z.B. Beschilderung) aufmerksam zu beobachten hat, um eine passende Entscheidungsgrundlage zu haben.
Die Lkw-Unfälle unter Brücken zeigen doch, dass dies der Fahrer nicht immer automatisch macht.

Da wir bisher keine Möglichkeit haben, den Sachverhalt angemessen darzustellen, sollten wir diese schaffen.
Wenn wir exakt beschreiben wollten, wie die Höhenbeschränkung auftritt, wäre es unnötig kompliziert. Hier kann man sich tatsächlich auf die Entscheidung des Fahrers vor Ort verlassen. Wichtig wäre nur zu erfassen, dass eine teilweise Höhenbeschränkung vorliegt und ab welcher Höhe diese relevant ist. Damit wäre auch obiger Fall abzudecken, wo der Fahrer die Gegenspur wählen muss.

Ich schlage daher vor, ein Tag der Form maxheight:partial=3.5 zu verwenden. In Fällen, in denen keine konkrete Höhenangabe vorliegt, könnte man maxheight:partial=yes verwenden. Dies könnte zum Beispiel Bereiche abdecken, die mit dem Verkehrszeichen “Eingeschränktes Lichtraumprofil” gekennzeichnet sind.

Bei Bedarf könnte man maxheight:partial mit :forward und :backward kombinieren.

Für das Beispiel mit der einseitig nur 3.5 hohen Brücke könnte man somit folgendes taggen:

maxheight=4
maxheight:partial:forward=3.5

Dabei bin ich davon ausgegangen, dass im Brückenbereich Überholverbot sein wird und somit in backward Richtung die höheneingeschränkte Fahrbahn ohnehin nicht benutzbar sein wird. Daher braucht die backward Richtung auch kein maxheight:partial.

In meinem konkreten Fall gibt es keine Markierung der Straßenmitte und auch kein Überholverbot.
Da dort im Prinzip eine Sackgasse für Autos ist, wissen die wenigen, die dort hin müssen, von der unterschiedlichen Regelung bergauf/-ab und verhalten sich entsprechend.

Ich persönlich bin kein Fan vom Taggen von immer Ausnahme-Situationen.
Wenn es jedoch sein muss, dann ist maxheight:partial(:forward/backward) ein Weg für das man ein Proposal erstelen könnte.

Edbert (EvanE)

In den Untiefen des Wikis habe ich einen Hinweis gefunden, dass man auch für Wege mit covered=yes ein maxheight pflegen kann.

Das Symbol ist noch dasselbe wie bei Tunneln.

Es gibt noch einige weitere Fälle, in denen Höhenbeschränkungen mit einer gewissen Wahrscheinlichkeit auftreten können. In diesem Post fange ich mit Tankstellen an.

Fast alle Tankstellen haben eine Überdachung und diese kann natürlich prinzipiell eine Höhenbeschränkung haben. Dabei kommen echte Höhenbeschränkungen nicht nur etwa bei uralten unbedeutenden Dorftankstellen vor. Ich habe gerade eine Höhenbeschränkung von 3.8m bei einer Tankstelle in der City-Nord an einer sechsspurigen Straße eingetragen. Dabei handelt es sich nocht nicht einmal um eine Tankstelle innerhalb eines Gebäudes (z.B. Parkhaus), wie dies im Ausland teilweise üblicher als bei uns zu sein scheint. An zwei weiteren Tankstellen hier in der Umgebung ist mir auch schon 4m Beschilderung aufgefallen.

Es stellt sich die Frage, wie häufig derartige Beschränkungen tatsächlich sind und ob sich eine systematische Erfassung lohnen würde. Vielleicht können die Lkw-Fahrer hier dazu Auskunft geben, ob dies ein tatsächliches Problem ist.

Wenn eine Tankstelle detailliert gemappt und richtig getagt ist, sollte man sie über covered=yes mit finden. Oft dürfte dies aber nicht der Fall sein. Vermutlich müßte man zur systematischen Erfassung auch nach amenity=fuel suchen, aber je nachdem, wie man maxheight für Tankstellen taggt, kann es dann kompliziert werden, auf vorhandene maxheight-Einträge zu prüfen.

Zunächst müßten wir aber klären, wie man maxheight überhaupt sinnvoll bei Tankstellen taggt. Sicherlich würde man ein maxheight an den Servicewegen eintragen. Ist dies aber ausreichend? Die sinnvollste Aufgabe wäre wohl, dass ein Navi gezieht für den jeweiligen Fahrzeugtyp geeignete Tankstellen anzeigen kann. Dabei wäre natürlich auch eine Tankstelle für LKWs geeignet, die nur an einigen Tanksäulen eine Höhenbeschränkung hat. Derartiges wäre kaum korrekt aus den Daten der Servicewege automatisch abzulesen.

Vermutlich wäre daher besser, auch das amenity=fuel Objekt mit einem maxheight Tag zu versehen. Dann wäre es aber auch einfach, eine Karte für die systematische Erfassung fehlender maxheight Tags zu erzeugen.

Der zweite Fall potentieller Höhenbeschränkungen sind obere Tragwerke von Brücken. Hier ist also nicht wie üblich der untere Weg sondern der obere Weg betroffen. Da es nun viel mehr Brücken gibt, bei denen eine Straße oben liegt, als es Brücken gibt, bei denen eine Straße unten liegt, ist es natürlich nicht sinnvoll, für alle diese auch eine maxheight Angabe systematisch zu erfassen.

Es wäre jedoch ein zweistufiges Vorgehen denkbar. Brücken mit oberen Tragwerken sind vergleichsweise selten und diese Eigenschaft ist in Luftbildern erkennbar. Zudem treten diese Brücken insbesondere in bestimmten Bereichen auf, wie z.B. in Hafengebieten oder über größeren Bahnanlagen oder Flüssen. Daher könnte man diese Brücken anhand von Luftbildern geeignet taggen, um sie anschließend in der Karte als fehlender Höhenbeschränkung auszuweisen.

Die Schwierigkeit dabei dürfte sein, dass es vermutlich bisher keine geeigneten Tags gibt, um ein oberes Tragwerk abzubilden. Daher müßten wir vermutlich eines erfinden.

Einen seltenen Sonderfall stellen überdachte Brücken dar. Hier könnte man covered=yes verwenden. Dies wird im deutschen Wiki auch schon als Beispiel für covered=yes genannt.

Eventuell könnte man in dem allgemeineren Fall eines oberen Tragwerks ein Tag in der Art covered=partial, covered=partially oder covered=partly verwenden. Diese drei Tags sind nach Taginfo bereits im Einsatz, aber jeweils nur 1-2 mal.

Der dritte Fall potentieller Höhenbeschränkungen sind Parkplätze aller Art (darunter auch Taxistände etc.). Relevante Objekte wären dabei amenity=parking, amenity=parking_space, amenity=parking_entrance, amenity=car_sharing und amenity=taxi.
Allerdings müßte noch ein geeigneter Indikator für eine mögliche Höhenbeschränkung hinzukommen. Als Indikatoren sehe ich:

  • Lage unter Brücke (Dies ist leider nur erkennbar, wenn das Objekt flächig dargestellt ist.)
  • covered=*
  • tunnel=*
  • parking=underground
  • parking=multi_storey
  • amenity=parking_entrance braucht keinen weiteren Indikator, da auf multi_storey und underground begrenzt.

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.