Berge, bei denen der Gipfel einen anderen Namen hat

Communities Österreich (Austria)
1

Es gibt hin und wieder Berge, deren Hauptgipfel einen eigenen Namen hat. Z.b. der Schneeberg, dessen Gipfel “Klosterwappen” heißt, die Koralpe mit Gipfel “Großer Speikkogel”, der Petzen mit Gipfel " “Kordeschkopf”.

Jetzt gibts aber in OSM nur ein übliches Tagging für (punktförmige) GIPFEL: natural=peak. Wie man aber die anderslautenden, (flächenmäßigen) Berge erfasst ist zum einen nicht eindeutig definiert, zum anderen werden diese Lösungen in kaum einer Karte - und vor allem nicht in der “Hautpkarte” Carto - angezeigt. Das ist natürlich ein großes Manko für eine Karte, wenn solch bekannte Namen wie der “Schneeberg” nicht aufscheinen. (Bitte jetzt nicht mit dem Totschlagargument: “Wir taggen nicht für Renderer kommen”, danke :wink:

Das erzeugt immer wieder Unzufriedenheit: Z.b. in einer emotionalen CS-Diskussion zum Schneeberg Changeset: 105079361 | OpenStreetMap , einer dazugehörigen Diskussion in der Mailingliste [Talk-at] Schneeberg, Klosterwappen

Welche Möglichkeiten gäbe es?

  1. Für größere Gebirgsgruppen hat sich in den Ostalpen das Tagging per place=region + region:type=mountain_area durchgesetzt, dieses wird aber nur in 2 Karten gerendert: Historische Objekte und https://opentopomap.org . Leider verweigeren die Carto-Programierer bis heute eine Anzeige dieser Gebiete

  2. Für linienförmige Bergzüge oder -rücken (für Flächen werden diese laut Wiki nicht empfohlen): natural=mountain_range, natural=ridge, natural=arete

  3. natural=massif: wird sehr selten verwendet, im Wiki scheint es unter “natural” gar nicht erst auf

  4. Man setzt beide Namen auf den Hauptgipfel in der Form: “Klosterwappen (Schneeberg)”

  5. Man setzt in etwa in der geometrischen Mitte des Bergs ein locality=Schneeberg - zumindest solange flächenmäßige Berge nicht in Carto aufscheinen. Ist vielleicht semantisch nicht ganz korrekt, aber auch nicht völlig daneben, da es sich bei Bergnamen ja auch um etwas ähnliches wie Flurnamen handelt.

Welche Ideen habt ihr, wie soll man dieses Problem lösen?

Ich hänge noch einen Ausschnitt der ÖK 250 an, wo das Rendering von Gebirgsgruppen, Bergen, Gipfeln vorbildlich zu sehen ist.

Berge
Berge1674×931 443 KB
(ÖK 250)

1 Like
2

Vielen Dank für den Vorstoß, ich war ja im Vorfeld auch in einige Diskussionen involviert. Als weitere Beispiele möchte ich noch die Rax, die Schneealpe (gegenwärtig als landuse=meadow gemappt, sicherlich nicht ideal), die Hohe Wand, die Dürre Wand anführen, die eh auch alle am ÖK50-Ausschnitt sind, zusätzlich in SW-NÖ den Gamsstein und die Voralpe und in der Obersteiermark die Kräuterin, den Trenchtling, den Reiting und die Haller Mauern (letztere sind gegenwärtig als “natural=bare_rock” gemappt, auch nicht ganz ideal), in Sbg z.B. Tennengebirge (gegenwärtig gleichzeitig als place=locality und natural=bare_rock gemappt, aber hier gibt es zusätzlich noch ein auch in Carto angezeigtes protected_area) und Hagengebirge, in Tirol z.B. Wilder Kaiser, Rofan. Es geht also nicht nur um Einzelfälle. Klar kann man nun argumentieren, dass der Wilde Kaiser kein einzelner Berg ist, auch das Tennengebirge und das Hagengebirge nicht, aber viele kennen die einzelnen Gipfel gar nicht wirklich und vermissen sie z.B. auf Carto.

Dann darf ich noch 2 von mir recht geschätzte OSM-Anwendungen erwähnen, wo regions und mountain_ranges zumindest teilweise gerendert werden: https://www.bergfex.at/, Mapy.cz

1 Like
3

Als Ergänzung dazu die taginfo von region:type und dem weiter verbreiteten natural=mountain_range. Wäre durchaus überlegenswert von region auf natural zu wechseln, falls es keine triftigen Gründe gibt die dagegen sprechen.

Interessant in dem Zusammenhang ist auch der Diskurs auf OSM Carto zu Rendering of valleys, ridges and other mountain elements, bei dem die Carto Entwickler ihre Sichtweise zum Ausdruck bringen.

4

Ein weiteres Beispiel für einen Berg mit vielen Gipfeln, die aber alle anders heissen: Der Витоша (dt. Witosha) südlich von Sofia, Bulgarien:

Dass der Name dort zu lesen ist, kommt von diesem Naturpark: Relation: ‪Витоша‬ (‪1407626‬) | OpenStreetMap

5

Vorab: Wir sollten uns nicht auf OSM Carto versteifen. Dieser Stil zeigt keine Höhenlinien oder Schummerung an und ist daher nicht gut geeignet um Berge darzustellen. Ein Gebiet zu zeigen ginge dort fast nur per Umrisslinie, und das macht bei Bergen keinen Sinn. Ich würde mir vielmehr wünschen, dass es auf Karten, die Höhen darstellen, gezeigt wird.

Ich bin ein ziemlicher Fan von Polygonen, die den Berg umspannen, mit natural (Variante 3, gerne auch =mountain, falls =massif unpassend wäre).

Ich finde Variante 4 (Berg- und Gipfelnamen im name) und Variante 5 (Locality) sind echt eine Notvarianten, die wir vermeiden sollten. Weil damit kann ein Renderer, der es ordentlich machen möchte, nicht arbeiten.

Ich werfe noch etwas ins Rennen, und zwar analog zu Brücken, wo es teilweise unterschiedliche Namen von Straße und Brücke gibt. Dort hat man bridge:name erfunden. Das könnte man auf mountain:name erweitern. Ein Renderer kann dann daraus machen, was er will, zB ein “Klosterwappen (Schneeberg)”, oder in gewissen Zoomstufen nur ein “Schneeberg”.

1 Like
6

Wenn ich mir den Screenshot der topografischen Karten ÖK 250 anschaue, welchen PPete2 gepostet hat, denke ich, dass dort mit einem solchen linienförmigen Objekt gearbeitet wurde, da der Name “Schneeberg” diagonal und in eine leichten Kurve dargestellt wird. Wobei ich selber bislang nur Erfahrung mit naturel=ridge habe.

Insofern könnte man im Fall des Schneebergs schon ohne eine neue Lösung hier mit natural=ridge + name=Schneeberg arbeiten.

Für größere “Gebirge” erscheint mit dann ein Arbeiten mit place=region + region:type=mountain_area (oder =mountain_range) geeignet. (Das dies im Carto-Stil nicht angezeigt wird, finde ich bedauerlich. Statt dessen aber nun etwas Neues zu erfinden würde dieses Problem nicht lösen.)

Klar sollten wir uns nicht auf OSM-Carto versteifen. Aber wieso sollte Carto so etwas nicht genauso darstellen können wie dies bei Opentopomap? Die zeigen so etwas ja auch nicht als Fläche an sondern erzeugen aus der Fläche einen linienförmigen Schriftzug. Das ließe sich bei Carto mit Sicherheit auch genauso machen.

Der trifftige Grund ist, dass ein solcher Wechsel unweigerlich zu einem Nebeneinander von alt und neu führen würde.

Von diesen beiden Lösungvorschlägen halte ich nicht viel. Es sind Lösungskrücken, die sich zu sehr an der Sichtbarkeit im Carto-Stil orientieren. Aber zum einen ist Schneeberg kein Flurname für eine kleine Fläche sondern der Name eines deutlich größeren Naturraums. Zum anderen sollten wir darauf verzichten, einen in dieser Form nicht existenzen Namen zu erfinden.

7

Opentopomap scheint alle drei hier genannten region:type zu rendern: mountain_area, natural_area und mountain_range

8

Aus meiner Sicht ist dieses Nebeneinander von alt und neu schon jetzt so vorhanden und der Wechsel von region auf natural würde dazu beitragen es zu beenden.

place=region ist eigentlich ein historischer Tag und stammt noch aus der Anfangszeit von OSM. Er wurde nie wirklich klar definiert und umfasst sowohl Gebiete mit fließenden Grenzen (z.B. Bergregionen) als auch Verwaltungsgebiete mit klar definierten Grenzverläufen. Da Gipfel, Berge, Bergkämme, Gebirgskämme, Gebirgsketten, usw. alle natürliche Objekte sind, wäre die einheitliche Verwendung von natural aus meiner Sicht sehr naheliegend und auch intuitiv leichter verständlich.

Warum werden Berg- und Gebirgsnamen auf OSM Carto derzeit nicht gerendert? Soweit ich die Argumentation der Carto Entwickler verstanden habe, ist ein Grund für das nicht Rendern die fehlende Schummerung bzw. die fehlenden Höhenlinien im Standard Stil, ohne die das Anzeigen der Berg/Gebirgsnamen aus ihrer Sicht nicht sinnvoll erscheint. Ein weiteres Argument ist das Fehlen einer durchdachten Lösung zum Erfassen und Taggen von Bergen, Gebirgen und Gebirgsketten - und ich denke, hier kann man ansetzen, um die Situation zu verbessern.

Aus meiner Sicht ist die größte Herausforderung, die Ausdehnung und Geometrie der Objekte (z.B. Berge) so zu erfassen, dass Datenkonsumenten ein möglichst wirklichkeitsgetreues Abbild der Objekte erhalten.

Mein Ansatz dazu wäre, die bereits in OSM vorhandenen Gipfel, Kämme, Grate, Gletscher, Scharten, usw. eines Berges in einer Relation zusammenzufassen und mit natural=mountain + name zu taggen. Das ergibt zusammen mit den Höhenangaben der einzelnen Objekte (ele) ein grobes Abbild der Ausdehnung und dem Höhenverlauf.

Damit sollten die Renderer in der Lage sein, eine entsprechende Beschriftung für den Berg zu generieren. Diese Berg-Relationen könnten dann in weiterer Folge zu Gebirgs- und Gebirgsketten-Relationen zusammengefasst werden, die auf die gleiche Weise gerendert werden.

Bei dieser Lösung wird auf bereits Vorhandenes zurückgegriffen und dieses zu neuen Einheiten zusammengefasst. Das Neuerfassen von Grenzlinien und Grenzpolygonen würde damit gänzlich entfallen und die Übersichtlichkeit beim Kartografieren deutlich erhöhen - Stichwort “Grenzlinienwildwuchs”.

Einen wirklich befriedigenden “quick fix” für die Anzeige des Bergnamens im derzeitigen OSM Carto kann ich leider auch nicht anbieten – es wären dann doch wiederum nur Lösungen für den Renderer.

9

natural=massif war nicht nur nicht auf natural verlinkt, sondern es gab überhaupt keine Seite dazu. Ich habe jetzt mal eine Wikiseite angelegt. Einen Link auf der natural-Seite einzutragen mache ich vorerst mal nicht, da wir noch keinen Konsens hier haben und der Tag so selten benutzt wird.

10

Ich sehe das genauso. natural passt viel besser. region:type ist verwirrend (auch aus dem Grund, dass es mountain_area und nicht mountain_range heißt) und in der Minderheit. Teilweise sind die Objekte auch schon mit beidem getaggt.

11

Wenn das so ist, verstehe ich nicht, wieso natural=peak angezeigt wird. Auch das sind topografische Informationen, die auf einer Karte ohne Geländerelief eigentlich nichts zu suchen haben. Wobei meines Wissens auf klassischen gedruckten Straßenkarten (z.B. Genalkarte) durchaus markante Berggipfel wie auch Gebirgszüge eingetragen sind. Und dies auch, obwohl diese Karten weder Höhenlinien noch Schummerung kennen.

12

Die Entscheidung, welche Informationen auf einer Karte angezeigt werden und welche nicht, ist nicht immer ganz einfach zu treffen, liegt aber letztendlich beim Ersteller der Karte. Wir als Datenerfasser können nur versuchen, die Informationen möglichst realitätsnahe und gut strukturiert anzubieten.

2 Likes
13

Zur Entscheidung natural=mountain_range oder place=region + region:type=mountain_area:

Es hat sich da im Ostalpenraum das place=* durchgesetzt, weil natural=mountain_range laut Wiki Tag:natural=mountain_range - OpenStreetMap Wiki dezidiert vor allem für linear verbundene Berge und Gipfel ist: “…high ridges and mountain peaks ranged in a line…” , “…For these reasons it is not recommended to map mountain ranges as areas…” und daher für flächige Berge und -gruppen nicht passt. Lineare Verbidungen kann man alternativ aber bereits mit natural=ridge, natural=arete eintragen, diese werden auch in Carto gerendert. Zum Ändern dieses praktizierten Schemas müsste man viel an internationaler Überzeugungsarbeit leisten.

Ich denke nicht das für eine Beschriftung von Bergen und Gebirsgruppen zwingend Höhenlinien, Schummerung oder Umrisslinien erforderlich sind. Z.b. ist dieses auf der ÖK 500 (siehe Screenshot unten) im Sinne einer Generalkarte gut gelöst (ok, Schummerung ist zwar vorhanden, aber auch ohne diese hätte die Beschriftung der Gebirgen einen Mehrwert für die Karte). Die ÖK 500 widerspricht somit auch dem (angeblichen) Argument der Carto-Entwickler warum diese Namen nicht in Carto dargestellt werden. Keiner verlangt das man mit der Beschriftung die genauen Grenzen eines Gebirges oder sonst einer Region (z.b. Waldviertel) sieht. Allein das Vorhandensein der Beschriftung ist der Mehrwert im Vergleich wenn sie nicht wäre. Bei place-nodes von Orten sieht man ja auch nicht die genauen Grenzen dieses Ortes, trotzdem würde Essentielles fehlen ohne diese Ortsbeschriftungen.

Man kann sich alternativ daher schon fragen: Wollen wir (noch) jahrelang darauf warten, bis die meisten Karten und vor allem der mit Abstand meistbenutzte Kartenstil Carto zu einer Lösung kommen, oder taggen wir (einstweilen - das ist jederzeit wieder änderbar wenn es eine vernünftige Lösung gibt) pragmatisch alternativ, also Punkt 4. oder 5. ?

ÖK500
ÖK5001380×906 406 KB
(ÖK 500)

14

Ich habe zwecks Anzeige in OSM-carto dort einen Issue eröffnet: https://github.com/gravitystorm/openstreetmap-carto/issues/4899

Würde sicher helfen, wenn man dort auch seine Meinung dazu kund tut.

1 Like
15

Übrigens vor ein paar Tagen wurde von @Elena_ausWien ein Gipfel Schneeberg angelegt.

16

Habe das CS kommentiert und den falschen Gipfel wieder entfernt

17

noch ein betroffener Gipfel: Note: 3970997 | OpenStreetMap (amtlich namenlose aber höchste Erhebung des Kuhschneebergs)