Beim Ifinger bei Meran verschwindet der Name von z12 nach z13, taucht dann aber in z14 wieder auf.
Ein Beispiel ebenfalls von dort, weshalb der Algorithmus nie perfekt sein kann:
Die Texelspitze hat zwar der Gruppe den Namen gegeben, aber da das Roteck 19 m höher ist, taucht dieser Berg in z12 zuerst auf.
Diese verschwindenden Namen in Z11 und Z12 liegt daran, dass der Platz für den Namen von irgendwas anderem, vorher gerendertem, blockiert wird. Der Blockierer kann auch sowas unscheinbares sein wie die Beschriftung einer Höhenlinie (die gibts in Z10 noch nicht), bei Bergen sind die jedenfalls die Hauptursache.
Wir hatten die Gipfelbeschriftung mal erzwungen, dann überlappt sich der Schriftzug mit anderen (Ortsnamen z.B.) und das war nicht schön. Jetzt wird der Namen nur gerendert, wenn Platz ist, was auch nicht schön ist… 
Mal sehn, vielleicht gibts Kompromisse und wir überschreiben zumindest Höhenlinienbeschriftungen, falls Mapnik das so selektiv zulässt.
Grüße
Max
Falls ich mich mit einer ganz profanen Frage mal dazwischen drängeln darf: Geht das Landsat Layer normalerweise?
Eine Frage an die OpenTopoMap-Macher:
Habt Ihr eine Vorschlag / Lösung für dieses Problem:
https://forum.openstreetmap.org/viewtopic.php?id=60635
Grüße aus Oberschwaben
Kurzer Einwurf: Die nordenglischen Berglandschaften verhalten sich weitgehend wie erwartet. Erstaunlich ist, dass in den Yorkshire Dales in Z10 drei hohe Berge mit Namen auftauchen (darunter Whernside, der höchste), einige weitere bedeutende Gipfel als unbeschriftetes Dreieck, aber der zweithöchste (Ingleborough) nicht mal als Dreieck!
Zu wenig Dominanz zum Whernside? Die Scharte dazwischen ist aber beträchtlich tief 
–ks
Ich nicht… Man bräuchte einen Stil, der den Schriftzug “Grünten” in elegantem Schwung um den Berg schreibt und in dessen Mitte die Gipfel setzt. Das wäre jedenfalls die traditionelle Darstellung dieser Situation. Ideen gesucht…
Jo, zu undominant (immerhin 6800m, deshalb ab Z11 mit Schrift), aber halt zu nah an einem noch höheren. Mehr Glück hat der Pen-y-ghent daneben, der steht 9600m von seinem grossen Nachbarn weg.
Die Scharte finde ich schon mit dem Finger auf der Landkarte schwer (beim Bahnhof von Ribblehead ungefähr auf 300m?), ich kanns aber nicht berechnen… Aber auch da fehlt vielleicht einfach nur eine Idee. Die Dominanz schlief ja auch nur so lange, weil wir keine Möglichkeit fanden, die in vernünftiger Zeit (d.h. in 1 Stunde oder so) für ne halbe Million Gipfel zu bestimmen. Vielleicht scheitert die Schartenhöhe auch nur am Mangel an Programmiergeschick. Bis dahin testen wir an Regentagen vielleicht mal was mit “ragt X Meter aus seiner 1km-Umgebung heraus”.
Grüße
Max
Edit: dem Dativ gerettet…
Zum Trost: Zu jedem Algorithmus gibt es genügend Beispiele, für die das Verfahren zu einem beliebig unzufrieden stellenden Ergebnis kommt.
Zur Abwechslung auch mal ein Lob: Ich finde die Karte sehr ansprechend und ausgezeichnet nutzbar.
Vielen Dank für die bisherigen Rückmeldungen. Wir sind froh über jede Meldung à la “da passt was nicht”, weil jeder in seinem Gebiet am besten weiß, welche Berge tatsächlich relevant sind. Als Menschen mit technischem Hintergrund nähern wir uns dem Problem eher von der algorithmischen Seite, anders als ein studierter Geograph vielleicht uns einfach sagen könnte, mit welchen Parametern (Dominanz, Schartenhöhe, Reliefenergie, Oragraphische Dominanz) man einen Prominenz-Wert bestimmen kann, der von 0m ü.NN bis 8848m ü.NN funktioniert.
Großes Danke den Entwicklern für die Kartenoptimierungen der letzten Monate!
Die Darstellung der Berge mit großer Dominanz funktioniert zB beim Hohen Dachstein (2995m, Dominanz 47 km) in den österreichischen Alpen nicht besonders gut: [https://opentopomap.org/#map=16/47.47395/13.60662]
Bei Zoom 10 und 14 wird der Name gerendert, bei Z11 - Z13 verschwindet der Name hingegen.
Ich nehme an, es liegt daran, dass unmittelbar beim Gipfel die Dachsteinsüdwand > 500 m senkrecht Richtung Süden abfällt und der Höhenmodell dies nicht exakt sondern abgeflacht darstellt. Somit liegt der Gipfel des Hohen Dachstein auf der Höhenlinie 2750 m, also 250 m zu tief und die Namen der eigentlich niedrigeren Nachbarberge (zB Niederer Dachstein, Gjaidstein) werden als vermeintlich höher gerendert.
Beste Grüße aus Linz
Bernhard
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 
Frage: Gibt es einen Grund, warum OTM markante Bäume nicht rendert? Gerade im Flachland sind das wichtigere Orientierungspunkte als “Gipfel”
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 
Danke. “denotation” hinzugefügt