Gipfel statt Hügel statt Gipfel

chrsmsk · 2021-03-30T07:14:54.000Z

Gelöscht weil nicht relevant

dieterdreist · 2021-03-30T07:45:19.000Z

unixasket:

Völlig korrekt ist das aber auch nicht, den Namen an den Grat zu heften, da es ja eigentlich der Bergname ist. Hat ein solcher Berg auch mal nicht die Form eines eindeutigen Rückens, sondern ist z. B. Mehrgratig und trotzdem zu klein für eine ganze Berggruppe, dann gibt es keine Möglichkeit den Namen an ein entsprechendes Objekt zu heften. Daher müßte es auch ein natural=mountain geben und zwar als Flächenobjekt.

es folgt daraus, dass man neben Gipfel auch für Berg einen Weg der Abbildung haben will, das muss aber nicht unbedingt eine Fläche sein, es könnte z.B. auch einfach ein tag sein, der bei Gipfeln zusätzlich sagt von welchem Berg sie ein Teil sind (sowas wie mountain_name) oder eine Relation, die Bergteile zusammenfasst (aber auch valide wäre ohne dass man eine vollständige Fläche bildet). Damit könnte man zwar den Umriss des Berges nicht erkennen, aber der Ort wäre klar

seichter · 2021-03-30T08:57:42.000Z

dieterdreist:

unixasket:

Völlig korrekt ist das aber auch nicht, den Namen an den Grat zu heften, da es ja eigentlich der Bergname ist. Hat ein solcher Berg auch mal nicht die Form eines eindeutigen Rückens, sondern ist z. B. Mehrgratig und trotzdem zu klein für eine ganze Berggruppe, dann gibt es keine Möglichkeit den Namen an ein entsprechendes Objekt zu heften. Daher müßte es auch ein natural=mountain geben und zwar als Flächenobjekt.

es folgt daraus, dass man neben Gipfel auch für Berg einen Weg der Abbildung haben will, das muss aber nicht unbedingt eine Fläche sein, es könnte z.B. auch einfach ein tag sein, der bei Gipfeln zusätzlich sagt von welchem Berg sie ein Teil sind (sowas wie mountain_name) oder eine Relation, die Bergteile zusammenfasst (aber auch valide wäre ohne dass man eine vollständige Fläche bildet). Damit könnte man zwar den Umriss des Berges nicht erkennen, aber der Ort wäre klar

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.

kuhni74 · 2021-03-31T17:18:57.000Z

seichter:

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…

seichter · 2021-03-31T19:06:43.000Z

kuhni74:

Damit sind Punktkoordinaten für größere Objekte wirklich nicht zielführend, meine ich persönlich.

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.

pyram · 2021-03-31T19:10:19.000Z

kuhni74:

…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.

Das ist kein Problem, sondern ein grundsätzlicher Denkfehler - und der lässt sich wahrscheinlich nicht beheben.

kuhni74:

Damit sind Punktkoordinaten für größere Objekte wirklich nicht zielführend, meine ich persönlich.

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

kuhni74 · 2021-04-06T15:57:21.000Z

pyram:

kuhni74:

…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.

Das ist kein Problem, sondern ein grundsätzlicher Denkfehler - und der lässt sich wahrscheinlich nicht beheben.

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.

pyram:

kuhni74:

Damit sind Punktkoordinaten für größere Objekte wirklich nicht zielführend, meine ich persönlich.

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

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.

Hungerburg · 2021-04-06T20:02:38.000Z

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.

maxbe · 2021-04-06T20:33:22.000Z

Hungerburg:

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.

uvi · 2021-04-07T06:30:26.000Z

Hungerburg:

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.

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.

streckenkundler · 2021-04-07T06:49:23.000Z

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

Hungerburg · 2021-04-07T08:50:31.000Z

maxbe:

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

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.

Pfad-Finder · 2021-04-07T09:23:10.000Z

@Streckenkundler: Vergiss mir nicht die Bloischdorfer Alpen!

https://www.lr-online.de/alpengipfel-in-der-niederlausitz-37369942.html

streckenkundler · 2021-04-07T09:48:45.000Z

Pfad-Finder:

Vergiss mir nicht die Bloischdorfer Alpen!

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

uvi · 2021-04-07T09:54:30.000Z

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

seichter · 2021-04-07T10:41:56.000Z

streckenkundler:

-Steinitzer Alpen (gefaltete Endmoräne bei Drebkau, bergbaubeeinflußt)

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.

Galbinus · 2021-04-07T11:15:04.000Z

streckenkundler:

Ich sehe das relativ… Hier in der brandenburgischen Pampa sind selbst Erhebungen, von 15-20m über Geländeniveau Berge…

https://de.wikipedia.org/wiki/Der_Engl%C3%A4nder,_der_auf_einen_H%C3%BCgel_stieg_und_von_einem_Berg_herunterkam

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.

streckenkundler · 2021-04-07T11:31:17.000Z

seichter:

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.

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…

Galbinus:

Eintrag als Linie: bei einem langestreckten Berg kann man natural=ridge auch mit dem Namen des Höhenzugs versehen.

Ja, das habe ich auch schon genutzt… http://overpass-turbo.eu/s/15Rr

Galbinus:

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.

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

Galbinus · 2021-04-07T11:55:18.000Z

streckenkundler:

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…

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

https://wiki.openstreetmap.org/wiki/DE:Tag:place%3Dlocality

skyper · 2021-04-07T11:55:46.000Z

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.