Hallo,
bei kleineren Höhenzügen bekommt man zwar den höchsten Hügel angezeigt, aber leider kennen den ja wirklich nur ein paar lokale Menschen. Dafür ist der Name des Höhenzuges leider nicht sichtbar. Beispiele sind Oder, Asse, Elm, Huy.
Wie kann man hier das Mapping optimieren?
Gruß
Mecki
Der Elm ist ja kein Höhenzug, sondern ein Wald 
Richtig gemappt wäre ein offener Way entlang der groben Kammlinie mit natural=ridge und name=*. Wird von der OTM auch schon gerendert (heißen Dank dafür!).
–ks
Selbst das passt dann nicht immer: Auch in flachen Gegenden kann mal eine kleine lokale Besonderheit auftreten (Schutthügel, Erdfall, Toteisloch, …).
In der Fotobearbeitung würde man zuerst weichzeichnen und dann zur Kantenhervorhebung unscharf maskieren.
Höhere Auflösung und Genauigkeit wäre natürlich noch besser 
.
Der Stil ist ja sehr zurückhaltend mit Flächenbeschriftungen für Wiesen, Wälder und Gebirge. Da wird sich derzeit durch anderes/besseres Mappen nichts optimieren lassen. Aber da kann man auch ändern und taggen kann man natürlich trotzdem: Falls der Elm (auch) ein Wald ist, ist er sowieso korrekt eingetragen. Für Gebirge bietet sich region:type=mountain_area an. Wird jedenfalls in dem einen oder anderen Gebirge verwendet.
Für kleinere Gebilde (ein paar Hügel mit einem gemeinsamen Namen als Gruppe) wüsste ich auch kein passendes Tag. Manchmal sieht man dafür place=locality (dafür gibts in OTM auch schon einen Vorschlag), aber mir ist place=locality beim Auswerten irgendwie unheimlich, da weiss man nie was man bekommt: Ein Gebirge, einen Ozean oder den Namen einer Weggabelung 
Grüße
Max
Danke, für den Tipp. Der Elm ist aber wirklich ein 323,3 m ü. NHN hoher und bewaldeter Mittelgebirgszug: https://de.wikipedia.org/wiki/Elm_(Höhenzug), aber es gab halt keine Tags dafür, da blieb nur Wald.
Ich würde gerade von einer topographischen Karte solche Angaben wie Alpen, Mittelmeer, usw. erwarten.
Gruß
Mecki
Edit: Wäre das nicht über die Auswertung der Fläche von Relationen machbar? Solche großen Objekte sollten doch schnell auffindbar sein.
Interessehalber eine Frage zur Dominanz: berechnet ihr die Dominanz anhand der Höhe von Gipfel zu Gipfel oder von Gipfel zu Höhenlinie?
Erst von Gipfel zu Gipfel. Dann wird der nächstgelegene höhere Punkt in den Höhendaten gesucht, aber nur im Umkreis der vorher mit den Gipfeln ermittelt wurde. Die Höhendatensuche ist langwierig und es muss da was kleineres als der nächste Gipfel rauskommen, sonst stimmt irgendwas anderes nicht, also spart man sich die Suche in grösserem Umkreis. Da ist dann auch sowas wie eine Notbremse: Wenn wenigstens eines stimmt (Höhendaten oder ele=*) begrenzt das die Dominanz.
Sportplätze mit Laufbahn werden nun mit Doppellinie dargestellt:
Max hat die SQL-Funktion entsprechend erweitert. Diese wird während des Renderns live ausgeführt.
Keiner Darstellungsfehler: Bei geplanten Einbahnstraßen hier: Autobahnauffahrt werden die Richtungspfeile angezeigt, die geplante Straße nicht. Wenn also Pfeile, dann auch den dazugehörigen Weg. Danke an das Team für OTM
Kurze Zwischenfrage, keine vernichtende Kritik: Wie ist der Status von Höhenlinien auf/unter Wasserflächen? Hier lässt die OTM den Main über eine mindestens 20 Meter hohe Kuppe fließen.
–ks
ja, und 20km weiter ist der Frankfurter Flughafen FRA eine echte Rumpelpiste
Falls also das Glätten/Ausblenden der Höhenlinien im Wasserbereich implementiert wird, bitte die Flughäfen mit in Betracht ziehen!
Es gibt aber Flughäfen da ist Anfang und Ende der Bahn auf einer deutlich anderen Höhe.
Zum Beispiel Funchal, http://www.airport-data.com/airport/photo/020950L.html
oder Courchevel mit 18% https://de.wikipedia.org/wiki/Flugplatz_Courchevel
Es gibt aber noch mehr mit deutlichen Höhenunterschieden.
Am Höhenmodell und an den Höhenlinien haben wir derzeit nicht vor etwas zu verändern. Der Aufwand ist immens. Lieber warten wir noch paar Jahre auf bessere Höhenmodelle, z.B. NASADEM.
Kleine Anmerkung, auf die vielleicht schon wo anders hingewiesen wurde: Waterways, wie diese Hafenbecken sollten keinen dunkelblauen Rand innerhalb der Wasserflächen haben.
@cepesko: Danke für den Hinweis. Damit’s nicht in Vergessenheit gerät (wir arbeiten ja nicht ständig den langen OTM-Thread hier im Forum nach unerledigten Fehlern durch…), habe ich das Problem auf Github dokumentiert.
PS: Wer sich’s zutraut, darf gerne gleich dort Fehlermeldungen erstellen. 
Als Nichtprogrammierer stelle ich mir die Lösung recht einfach vor, kann man nicht einfach 'ne Regel erstellen, die die outline von wasser an wasser schlicht hellblau färbt?
Der Renderer (*) “weiss” nicht, was daneben, drüber oder drunter liegt, wenn er eine Fläche pinselt. Er malt einfach einen Rand aussen rum, wenn das im Stil verlangt wird. Wer dunkelblaue Ränder zwischen Wasser und Wiese haben will, muss die gleichen Ränder zwischen Wasser und Wasser hinnehmen oder irgendwas kompliziertes (**) anstellen.
Grüße
Max
(*) zumindest Mapnik und Mapserver, andere kenne ich nicht
(**) keine Ahnung, was. Vor allem wenns auch noch in akzeptabler Zeit stattfinden soll. Aber mal sehn… vielleicht eine zweite hellblaue Linie drüber oder so…
Ich halte das eher für eine Feature und nicht für einen Bug. Die Flächen sind so “sauber” voneinander abgegrenzt. Siehe auch hier: http://blog.imagico.de/wasser-drunter-und-druber/
Jo, ein schwieriges Thema. Bei Umrissen von Wäldern kommt die Frage auch gelegentlich auf. Der eine will keine Striche durch gleichartige Flächen, der andere will deutlich sehen, dass die eine Fläche irgendwie was anders ist oder anders heisst als die daneben.
Naja, eine einfache Möglichkeit gibt es natürlich, die allerdings auch einen Nachteil hat:
Erst alle Umrisse zeichnen, dann die Decker darüber. Straßen sind zwar Linienelemente, dort tun wir das aber bereits. Der Nachteil ist, dass die Linienbreite des Umrisses dadurch halbiert wird, weil die Linie mittig gezeichnet wird und der Decker die innere Hälfte verdeckt. Natürlich könnte man die Umrisse entsprechend doppelt so stark zeichnen. Dadurch vergrößert sich das Polygon aber. Besonders bei eng nebeneinander liegenden Seen sähe das schlecht aus. Die Linienbreite wurde damals anhand der Karpfenteiche westlich von Erlangen optimiert: https://opentopomap.org/#marker=11/49.6716/10.8222
Das Problem der Umrandungen hat man bei Wäldern: Beispiel
Entweder weil die Polygone aus gewissen Gründen zusammengesetzt wurden, oder weil ein Nadelwald und ein Laubwald direkt aneinander grenzen.