OpenTopoMap

Der Wert passt schon (47km bis zu diesem Hang), darum wird der Punkt ab Z10 beschriftet. Ein zu niedriges Höhenmodell würde auch zu einer zu hohen Dominanz führen. Die Gipfelhöhe stammt nicht aus dem DEM, sondern aus OSM, sofern ele=* eine Zahl enthält.

Irgendwas verhindert die Labels beim Rendern… nur was?

Ich hätte den Verdacht, dass sich der Aufwand für bessere Renderregeln mehr lohnen würde als der für immer ausgefeiltere Dominanzalgorithmen. Ist aber ein Klagen auf hohem Niveau :).

Man muss sich die Frage stellen, ob die Verdrängung von Labeln wirklich in allen Fällen sinnvoll ist. Für wichtige Objekte sollte/könnte man die Verdrängung ausschalten, denn der Betrachter zieht auch aus sich überlappenden Beschriftungen wertvolle Informationen.

Hatten wir ja auch schon mal… Das Problem ist: Wenn man ein neues Spielzeug hat, beschäftigt man sich 2 Wochen nur damit, hält es für ganz wichtig und will eigentlich nur noch das rendern. Irgendwann befreit man sich aus dieser Fixierung und dann schlägts ins Gegenteil um. Kompromisse werden erst später möglich…

Mehr feedback:
Den Auswahl-Algorithmus der Berge in den Mittelgebirgen finde ich recht gelungen. Kompliment!
Der Katzenbuckel, höchste Erhebung im Odenwald wird bereits ab z9 mit Namen solitär dargestellt, verschwindet aber leider nochmal bei z11.
Der Kalmit, höchster Berg des Pfälzer Waldes, ist ab z10 ebenfalls solitär, aber bleibt in allen weiteren Stufen erhalten. Sehr schön!
Interessant ist der Große Feldberg, höchster Berg des Taunus: Bereits in z8 (!) benannt.
Der Vulkankegel Taufstein des Mittelgebirges Vogelsberg erscheint ab z10, zwar in z11 ohne Namen, aber dann wieder dabei.
Cepesko

Ja, das Szenario ist mir nicht unbekannt. Das Feature an dem man gerade arbeitet, wird bewußt oder unterbewußt zum wichtigsten Feature überhaupt. Und genau das schlägt sich dann in der Darstellung nieder. War da kürzlich nicht was bezüglich der Aussichtspunkte? Wie auch immer: Das Wissen um diesen Sachverhalt ist aber schon die halbe Lösung. Den Rest erledigt dann der Faktor “zeitlicher Abstand” …

Vielen lieben Dank übrigens dafür, dass Ihr in letzter Zeit wieder recht regelmäßig die Datengrundlage der OTM aktualisiert! Die OTM ist für mich persönlich auch ein wichtiges „Kontrollinstrument“; gerade um nicht versehentlich doch für einen Renderer zu mappen, sehe ich mir die von mir zuletzt bearbeiteten Gebiete gerne regelmäßig in verschiedenen Darstellungen an, insbesondere in der OTM. Daher ist es für mich sehr vorteilhaft, dass die OTM zur Zeit recht regelmäßig aktualisierte Daten verwendet … das muss nicht täglich oder wöchentlich sein, monatliche oder vierteljährliche Aktualisierungen sind aber „very much appreciated“!

Also in Berlin sind alle wichtigen Gipfel korrekt lesbar :smiley:

Frage: Gibt es einen Grund, warum OTM markante Bäume nicht rendert? Gerade im Flachland sind das wichtigere Orientierungspunkte als “Gipfel” :wink:

Hm, also meine mit denotation=natural_monument oder denotation=landmark getaggten „Lieblingsbäume“ werden immer noch gerendert. Alle gemappten Bäume zu rendern, wäre wahrscheinlich Unsinn … schließlich wird natural=tree heute mehr und mehr für alle möglichen Einzelnbäume verwendet, nicht mehr nur für markante Bäume.

Die Regel für Bäume ist "name= oder denotation=landmark oder denotation=natural_monument"*. Gibts noch mehr Möglichkeiten, markante Bäume von Stassenrandbegrünung zu unterscheiden?

Der Müggelberg bleibt! Der darf auf keiner topographischen Karte fehlen :wink:

Danke. “denotation” hinzugefügt

Andere Frage (bezieht sich genau genommen sicherlich nicht nur auf OTM, ist mir hier aber besonders aufgefallen):
Berechnet ihr die Höhenlinien selbst oder holt ihr euch den Layer irgendwo extern?

Ich habe gerade im Flachland das Problem, dass die Höhenlinien für meine Begriffe “viel zu exakt” sind, also durch eine extrem feingranulare Kurvenform eine Präzision vorgaukeln, die so mit Sicherheit nicht stimmen kann (Allein bezüglich Messungen mit und ohne Bäume, etc.). Durch die vielen Kurven wird zudem (mit in dieser Granularität vermutlich nicht einmal stimmigen Daten) die Karte sehr überladen mit Kringeln und Kreisen.

Kann man diese Scheingenauigkeit nicht abmildern bzw. damit die Übersichtlichkeit der Karte fördern, wenn man eine Art Kantenglättung bei den Höhenlinien durchführt, vielleicht so, dass “Schlaufen” und “Kreise” mit weniger als… (jetzt völlig aus dem Hut gegriffen) 50m Durchmesser weggeglättet werden?

Das könnte jemand machen, der zu “adaptive contours distance” eine Idee hat. Man dürfte diese Glättung ja nur dort vornehmen, wo die Gegend “überwiegend flach” ist. Die Spitzen echter Hügel sind ja auch nur kleine Kringel und ihre Grate enge Schleifen und die möchte man nicht bügeln. Man bräuchte also was wie “wir glätten dort, wo sich eine einzelne Höhe über hunderte von Metern wirr über die Karte schlängelt, aber keine Nachbarhöhenlinie weit und breit in Sicht ist” und genau dieses Mass für lokale Flachheit und passende Korrektur der Linie wäre vermutlich der erste Schritt für besser verteilte Höhenlinen.

Alternativ, bessere Höhendaten würden auch dieses Problem lösen. Eine flache Landschaft mit Amtsdaten ist zwar immer noch ein bisschen falsch (ein Bach darf jede Höhenlinie nur einmal schneiden), wirkt aber wesentlich ruhiger und ebener (links OTM, rechts dieselbe 400m-Höhenlinie aus dem DGM-50 der Bayerischen Vermessungsverwaltung in dieser Gegend):

Nur leider haben wir nix besseres (#482) :wink:

Grüße
Max

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 :smiley:

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 :sunglasses:.

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 :wink:

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.