Für Objekte unbestimmter Ausdehnung gibt es ja place=locality und das wird in manchen Gegenden auch reichlich für Bergnamen u.ä. genutzt.
Mit einem differenzierenden Untertag wie locality=mountain wäre mir das lieber als eine schwammig umrissene Fläche natural=mountain.
Noch genauer, aber aufwendiger wäre eine Relation mit den zugehörigen Gipfeln, Graten, Sätteln, … als Mitgliedern.
Flur-, Hang- und Bergnamen als place=locality werden in der Tat häufig benutzt, mit dem gerne auftretenden Problem, dass jemand daraus schließen möchte, das Objekt befände sich exakt an dieser Koordinate, obwohl es in der Realität etwas Flächiges bezeichnet.
Der oben erwähnte Fagradalsfjall in Island wurde anhand des Isländischen Atlas, wo dieser Name in einem großen Font quer über das Massiv hinweg steht (damit ist eindeutig, dass es sich um das ganze Massiv handelt), im Isländischen GIS-System an eine exakte Position in der Mitte des Schriftzugs ganz nah zum gegenwärtigen Vulkanausbruch geheftet, und damit hat der ganze angelsächsische Sprachraum geglaubt, den Vulkanausbruch mit diesem Namen bezeichnen zu müssen, was nicht korrekt ist, weil dort ein Hang und eine Talgruppe (Geldingadalir) liegt, aber kein Berg (fjall heißt Berg, dalur heißt Tal). In Island wird der Vulkanausbruch mit “Geldingadalir” bezeichnet und im deutschen Sprachraum überhaupt mit dem ganzen Vulkansystem Krýsuvík, zu dem der Fagradalsfjall und die Geldingadalir gehören.
Damit sind Punktkoordinaten für größere Objekte wirklich nicht zielführend, meine ich persönlich.
Eine Relation aus mehreren Unterobjekten hätte einen gewissen Charme, ist aber sicher aufwendig und vielleicht auch fehleranfällig.
Ich bin da wirklich überfragt, aber ich bin ein OSM-Anfänger…
Ohne weiteres Tag ist das in der Tat missverständlich bis missgebräuchlich. Mir ist schon eine Gegend untergekommen, wo mehrfach place=locality gesetzt wurde, um den Namen genau so zu platzieren wie er in einer Karte vorkam, obwohl hundert Meter daneben der (echte) Gipfel mir dem selben Namen inkl. Höhe gemappt war.
Das Mappen von unscharfen Objekten wie Bergen, Gebirgszügen, Tälern oder Regionen egal ob per Punkt oder per Linienzug ist bis heute nicht befriedigend gelöst.
Das ist kein Problem, sondern ein grundsätzlicher Denkfehler - und der lässt sich wahrscheinlich nicht beheben.
Ziele gibt es viele. Was bedeutet da schon zielführend? Es ist eine praktikable Lösung. Insbesondere wenn man bedenkt, dass viele Objekte zwar flächig sind, diese aber keine genaue Grenze haben.
Spätestens ein Router wird wieder einen (Schwer-)Punkt daraus machen und der Renderer einen Punkt, wo er den Namen hinschreiben soll 
Ob ein Denkfehler behoben werden kann, liegt schon auch an der Darstellungsart - wenn ich mit einer Darstellung ein Missverständnis erzeuge, dann habe ich nicht die richtige Darstellung gewählt.
Also mein Ziel ist, dass jemand das Dargestellte so auffasst, wie es gemeint ist. Wenn etwas praktikabel ist, aber falsch interpretiert wird, ist es zweifellos nicht zielführend.
Im Fall von Flächen, die keinen definierten Umriss besitzen, ist ein erfundener Punkt einer erfundenen Linie oder Fläche allemal vorzuziehen. Extra Bonus: der Punkt ist immer an derselben Stelle, unabhängig vom Renderer.
Linien könnte man entlang dieser Linie beschriften, Flächen innerhalb der Fläche.
Bei Punkten geht das nicht. Ausserdem weiss man bei Punkten auch nicht, ob das Gebilde die Karte halb ausfüllt, weil der Hügel riesig ist oder ob man erst ein paar Zoomstufen weiter den winzigen Hügel beschriften soll und bis dahin den Platz lieber für andere zu beschriftende Dinge freihalten soll.
Zu einem ähnlichen Fall gab es hier https://forum.openstreetmap.org/viewtopic.php?id=66950schon einmal eine wilde Diskussion ohne Ergebnis.
Anlass war diese Fehlermeldung https://www.openstreetmap.org/note/1768954
Ein “erfundener Punkt” stieß damals nicht auf Zustimmung.
Ich sehe das relativ… Hier in der brandenburgischen Pampa sind selbst Erhebungen, von 15-20m über Geländeniveau Berge…
Schöne Beispiel: der Schwarze Berg
Die Bergspitze bekommt übrigens demnächst noch ein man_made=cross (oder summit:cross=yes und auch summit:register=yes. Ich muß mal da mal wieder hin. Klingt zwar jetzt schräg, ist aber korrekt: https://www.lr-online.de/lausitz/luebbenau/tourismus-im-spreewald-warum-raddusch-jetzt-ein-gipfelkreuz-hat-56101262.html gesamter Artikel ist zwar hinter der Bezahlschranke, die Bilder sind aber zu sehen…
Sven
In der Gegend hier sind einige Flurnamen als Knoten place=locality erfasst, zB auch Hügel; nicht immer entsprechen die etwas, das sich als “natural=wood|meadow|*” Fläche anbietet. Also verdeckt auf der gerenderten Karte bei kleinen zoom-levels manchmal eine winzige Flur eine andere, größere.
Es gibt meines Wissens kein Attribut, das die fehlende Dimension (Bedeutung, Größe, etc.) ersetzen könnte. Andre place=… sind ja hierarchisch gestaffelt. Ein Manko, ja.
@Streckenkundler: Vergiss mir nicht die Bloischdorfer Alpen!
https://www.lr-online.de/alpengipfel-in-der-niederlausitz-37369942.html
Ich hab ja meine Alpen vor der Haustür 
: die Hartmannsdorfer Alpen…
Aber Alpenländereien haben wir in der Lausitz einige:
-Geigersche Alpen (Kippengebiet, technisches Denkmal)
-Steinitzer Alpen (gefaltete Endmoräne bei Drebkau, bergbaubeeinflußt)
Bei Potsdam außerhalb der Lausitz die Glindower Alpen…
alpenländische Grüße,
Sven
Der einzige Alpengipfel hat es bislang aber noch nicht zu OSM geschafft https://www.berliner-stadtplan.com/Alpengipfel-12277-Berlin-Marienfelde_a51809
Nur eine Fehlermeldung gibt es seit langem https://www.openstreetmap.org/note/2460881
Ich vermisse den Lausitzer Himalaya ;).
Zur Problematik der Relevanz von locality-nodes:
Geht mMn nur über (etwas subjektive) Zusatztags wie z.B. importance=high|medium|low als Angebot an die Kartenersteller, damit sie einen Anhaltspunkt haben, was zuerst dargestellt werden sollte.
Abgesehen davon, dass ich wenig von “schwammig begrenzten” Flächen halte, würde ich z.B. bei niedrigem Zoomfaktor dem Node “Zugspitze” in Konkurrenz zur Fläche “Wettersteingebirge” diesem den Vorzug geben.
Das wäre auch eine Möglichkeit, bei vielen natural=peak auf engem Raum eine Rangfolge anzugeben.
Zur eigentlichen Frage, um die es hier geht, weiß ich allerdings keine befriedigende Lösung.
Eintrag als Punkt: Enthält keine Information über die Ausdehung des Objekts. Ist aber klar in der Karte positioniert. Aber nicht immer gibt es einen Gipfel (siehe nächstes Beispiel).
Eintrag als Linie: bei einem langestreckten Berg kann man natural=ridge auch mit dem Namen des Höhenzugs versehen. Ich habe dies bereits gelegentlich genutz, wenn ein “Berg” keinen Gipfel hat sondern im Grund nur ein von einem höheren Berg ausgehender Höhenrücken ist: https://www.openstreetmap.org/way/820929295 Beim Stiensberg ist der höchste Punkt im Grunde der (nicht definierte) Übergangspunkt vom Stiensberg zum Unteren Langenberg. Dort irgendwo auf gut Glück einen Gipfel zu setzen, würde der Situation nicht gerecht. Alternativ hätte man den Stiensberg als place=locality irgendwo mitten auf den Höhenrücken setzen können.
Eintrag als Fläche: Problem hierbei ist, dass die Grenzen wo ein Berg anfängt, in der Regel nicht klar definiert sind. Trotzdem würde ich mir ein eindeutiges Tagging-Schema wünschen, dass es ermöglicht, einen Berg oder auch ein Gebirge als Fläche in einer Weise einzutragen, die auch in Karten beim Rendern berücksichtigt wird. Ich habe mich mal vor Längerem daran versucht, das bereits von jemand anderen eingetrage Mittelgebirge “Teutoburger Wald” zu bearbeiten https://www.openstreetmap.org/relation/3255240… nicht wirklich etabliert sowas bislang. Aber ungefähr in der Art könnte ich mir das flächige Eintragen von Bergen vorstellen.
Ich halte davon nichts… Wie du richtg geschrieben hast… subjektiv und das nicht nur etwas… Jeder, der seinen Berg in der Karte haben will, setzt dann importance=high, ein anderer ändert das wieder und schon ist Streit vorprogrammiert…
Ja, das habe ich auch schon genutzt… http://overpass-turbo.eu/s/15Rr
Interessant… Das wäre für mich ein Ansatz, auch größere Waldgebiete wie die Annaburger Heide besser abzugrenzen, um vom MP’s mit >1Outer wegzukommen…
Sven
Die Idee stammt nicht von mir, habe das Bestehende nur bearbeitet. Aber ich kenne bislang nur eine Karte, die das auswertet bzw. anzeigt: http://gk.historic.place/historische_objekte/translate/en/index-en.html?zoom=10&lat=51.72688&lon=10.75467&pid=HaHbHcSaHe
Im OSM Wiki steht dazu hier was:
https://wiki.openstreetmap.org/wiki/DE:Tag:place%3Dregion
Einen einzelnen Berg kann man aber vielleicht nicht wirklich “Region” bezeichnen. Das kleinere Pendant wäre dann place=locality, was in der Regel in Punktform für Flurnamen verwendet wird, aber auch als Fläche zulässig ist. (In der Verwendung als Punkt wurde es hier in dieser Diskussion ab #31 ff bereits gdiskutiert):
Zur genauen Definition eines Gipfels braucht es zwei Angaben, die Dominanz und die Prominenz oder Schartenhöhe. Mit diesen Angaben ist ein Gipfel eindeutig bestimmt. Eventuell kann in einem dritten und vierten Tag noch der Berg und der Gebirgszug untergebracht werden.
Komisch, bei Tälern und Schluchten, siehe paralleler Thread werden eben nicht Flächen verwendet aber bei Bergen und Gebirgen schon?
Da ja place mittlerweile auch als Fläche verwendet wird könnte auch mit place=mountain und place=mountain_range gearbeitet werden, jedoch hat mich das alles noch nicht überzeugt. Im Endeffekt braucht es ein freiverfügbares Höhenlinienmodell als Unterbau damit der Renderer wirklich was damit anfangen kann.
Du meinst den Harz? Den kann die OpenTopoMap auch beschriften. Die kann Gebiete darstellen aus
region:type" IN ('natural_area','mountain_area') OR "natural" IN ('massif','mountain_range','valley','couloir','ridge','arete','gorge','canyon')
Jeweils als Strich oder Fläche gemappt, nicht aber als Punkt (aus den in #37 genannten Gründen). Möglichkeiten für Berge hätten wir also, auch wenn m.E. kleine Gebiete im unvollendeten Proposal dazu ein bisschen zu kurz kommen. Man müsste sie nur verwenden.
Nein, ich meine den Teutoburger Wald, wenn man auf dem Kartenausschnitt ein wenig nach Westen scrollt zwischen Paderborn und Detmold.