Is there documentation on type=drainage_divide? I was looking for it, but could not find it.

Concerning the Alpine Watershed relation/14461262, they tagged the ways with type=boundary and boundary=geographical where they did not use administrative borders to approximate the drainage divide.

Regarding the resuse of existing ways, it is something that I have considered, but decided against, because I assume that it will create issues:
- Particularly where ridges are oriented normal to the major direction of the divide, the typically leaves the ridge somewhere to follow the valley divide to the next ridge. Therefore, we would need to split existing continuous ridges even if these are named, have Wikidata and Wikipedia, and Wikidata referenecs the ID of the ridge way. A pattern that we do also observe quite often is the divide running up a hill and running down again at an angle < 90°.
- Reusing ridges will significantly increase the amount of relation members
Elsewhere, relations do also often not resuse existing ways, but only the notes. For example forest and meadow relations typically do not use road ways and even if forest and meadow share a boundary line, they do nevertheless use distinct ways for their boundary lines.

I would assume that they guy who mapped the Alpine divide got it wrong. Only Americans use the watershed term for a drainage basin. For normal English speakers, it is synonymous with drainage divide. But the OSM concept of watershed is understanding it the AE way.

Hi,
The type=watershed tag is obviously used for relations on drainage systems of rivers which collect all the waterway ways within the main stream's drainage basin. What I mapped is a drainage divide. It is the line of division between two adjacent basins. If there is established tagging for a drainage divide, then please provide the reference.

Thanks. Then let's put the vertex there: changeset/176019379

Is this the vertex at 1972 m?

https://s.geo.admin.ch/rfpqunaneuor

This would mean that it is only about 8 m below terrain level.

Hi Cele, at the location close to the geographical col, where the pass vertex was located before, the elevation is 1917 m according to the cited data source. The source tends to provide quite accurate data. At the current location of the pass vertex, the elevation is 1937 m. Even closer to the tunnel entrance, the road might be higher, but I cannot rule out that the elevation reading from my source is influenced by the surrounding terrain. Therefore, I would see this change as an attempt of improvement. If you have access to more accurate data or know the elevation profile inside the tunnel, feel free to move the vertex to the de facto highest point of the road.

Hallo Bergfrei,
die Bank werde ich wohl verschoben haben, damit sie auf der gleichen Seite des Weges bleibt. Ich habe sie nach Augenmaß verschoben und nicht nachgemessen. Wenn sie zu weit abseits ist, dann rücke sie einfach wieder näher an den Weg.

Obwohl die Qualität der Luftbilder besser geworden ist, besteht insbesondere im Gebirge nach wie vor das Problem, dass die Aufnahmen in den meisten Bereichen verzerrt und verschoben sind. Deshalb lässt sich aus einem Luftbild meiner Meinung nach bestenfalls der relative Verlauf eines Weges ablesen. Die Position wird von GNSS in der Regel besser wiedergegeben.

Luftbilder zeigen außerdem immer die Vergangenheit. U.a. erosionsbedingt ändern sich Wegverläufe im Gebirge aber immer mal wieder.

Abweichungen von Luftbildern sind übrigens normal. Luftbilder sind praktisch immer verzerrt und verschoben.

Die Quelle ist doch abgegeben. GNSS = Global Navigation Satellite System. GPS ist nur das US-amerikanische. Mein Gerät nutzt aber weitere, wie z.B. Galileo.

I considered it more convenient to have this new changeset, citing the sources provided by you: changeset/173123377

Do you have an idea why the peak names would be confused on Geoportal DGU? Their topographical map looks quite accurate.

And a question on another possible name confusion: The HGSS map denotes P.1702, which is approximately 3.4 km to the east of Višerujno and slightly to the south, as "Zoranićev vrh", whereas DGU denotes it as "Babin vrh". Instead, HGSS denotes P.1738 further to the north as "Babin vrh". Do you have an idea which source is correct and which other sources there might be?

According to GeoPortal DGU, the name is "Debelo brdo", see https://geoportal.dgu.hr/?view=cAGe6C1tCrAzyr1EL7L50a for reference. What is the source of the different name provided by you?

Allein diese Erwiderung zeigt, dass Du es überhaupt nicht verstehst. Nein, die Vektordaten in der OSM-Datenbank sind keine Karte. Sie sind eine Datensammlung, aus der sich verschiedene Karten ableiten lassen. Dabei können die Daten für verschiedene Zwecke gefiltert und unterschiedlich visualisiert werden. Je nach Renderer und individuellen Vorlieben mal besser und mal schlechter für die Bedürfnisse eines jeden Kartenkonsumenten geeignet.

Was Kammlinien anbelangt, liest und verstehst Du vielleicht erst einmal diesen Artikel natural=ridge ehe Du hier solche Behauptungen aufstellst. Es gibt sogar mehrere Beispielbilder
osm.wiki/File:Walker-Ridge-z14-from-Opencyclemap.png
osm.wiki/File:Druim-Eileasaig-z14-opencyclemap.png
osm.wiki/File:Z16-crete-du-liou-opencyclemap-zoomed-out.png
Vielleicht reichen die schon aus, falls Du der englischen Sprache nicht recht mächtig bist.

Solange Du "andere mappen Unsinn" es nicht vermagst, einen sachlichen und konstruktiven Dialog zu führen und Dich mit Quellen auseinanderzusetzen, werde ich auf Deine Einlassungen nicht mehr antworten. Du trittst hier nur als Nörgler und sinnloser Zerstörer in Erscheinung.

Du scheinst es nicht zu kapieren. Daher nochmal: OpenStreetMap ist keine Karte, sondern eine digitale Datensammlung, auf deren Basis sich Karten erstellen lassen. Wenn Dir "die" Karte nicht gefällt, dann wende Dich an den Herausgeber der Karte und nicht an eine Person, die Daten erfasst. Wenn Dein Freund in seiner App eine Kammlinie nicht von einem Lift unterscheiden kann, hat er entweder eine Einschränkung bei der Wahrnehmung und Verarbeitung visueller Informationen oder er verwendet eine extrem schlechte App, die nur ähnlich aussehende Linien darstellt. In der App, die ich häufig verwende wird eine Lift u.a. über Gondelsymbole an seinen beiden Endpunkten kenntlich gemacht. Wendet euch auch in diesem Fall an die Herausgeber der App und macht ihnen z. B. Vorschläge, wie sich die Darstellung verbessern lässt oder schlagt vor, dass sie Kammlinien gar nicht erst rendert sollen. Oder willst Du jetzt vielleicht im Bregenzerwald auch noch alle Stromleitungen löschen, weil Dein lieber Freund sie mit einem Lift verwechseln könnte? Wenn Du gerne eine purisitische Karte und/oder App haben möchtest, dann gründe doch einfach ein Projekt, das genau dies zum Ziel hat. Es ist überhaupt kein Problem, aus den digitalen Daten bestimmte Punkte, Linien und Relationen anhand ihrer Tags herauszufiltern und gar nicht erst in eine Karte zu übernehmen. Meine App macht das übrigens auch. Zum Beispiel bekomme ich die vielen Skipisten und Skirouten, die mittlerweile aller Orten gemappt sind, nur im Skiprofil zu sehen. Obwohl sie mich die meiste Zeit des Jahres nicht interessieren und sie mich auch mal beim Mappen stören, lösche ich die nichtsdestotrotz nicht einfach weg. Denn es gibt sicherlich Menschen, für die diese Informationen sehr wertvoll sind.

Mit den Vektordaten in der OpenStreetMap-Datenbank kann man im Übrigen noch allerlei mehr Dinge tun, als lediglich Kartendarstellung abzuleiten.

Und was Gipfelnamen anbelangt: Beschäftige Dich doch einfach mal mit den angegeben Quellen. Außer VoGIS gibt es tatsächlich noch weitere. Die Quellen habe ich in aller Regel angegeben, an den OSM-Features Wikidata-Tags hinterlegt und auf Wikidata die Fakten mit ihren Quellen aufgelistet.

Wege mit natural=ridge sind m.E. auch dann für ein schnelles Erfassen der Topographie sinnvoll, wenn ein Renderer Höhenlinien und Schummerung bietet. Der Kamm liefert eine gut erfassbare Information, welcher Teil der Topogrsphie "oben" ist und wo die Kammlinie verläuft. Ansonsten wäre es generell die Aufgabe des Renderers, die Kammlinien einfach anhand ihres Tags zu ignorieren und nicht darzustellen. Es ist nicht die Aufgabe des Mappers.

Was die Kammverläufe anbelangt, hängt es von den verwendeten Höhendaten und dem Satellitenbild ab, was als Kamm erscheint und wo er zu verlaufen scheint. Es gibt auch immer wieder alte Kammlinien, die extrem grob eingezeichnet sind. Kämme ausschließlich über Beobachtung und ggf. Navigationsdaten zu mappen, ist aus meiner Sicht praktisch unmöglich.

Wenn Du auf einen Kamm stößt, der auch im Flachen noch weiter läuft, kannst Du ihn ja bei besserem Überblick der tatsächlichen Situation gerne einstutzen und ggf. auch weiter detaillieren. Am besten in einem Änderungssatz, der nicht jede Menge weitere Änderungen enthält. Das erleichtert die Nachvollziehbarkeit.

OSM ist keine Karte, sondern eine Grundlage zum Erstellen von Karten. Wenn Du in bestimmten erfassten Merkmalen ein Problem siehst, liegt das Deinen Beschreibungungen folgend daran, dass Du einen m.E. schlechten Renderer verwendest, der bei jedem Maßstab einfach alles im Kartenausschnitt rendert. Beispielsweise stellt der von mir verwendete Renderer die von Dir monierten Sättel nahe eines Gipfeld nur dann dar, wenn ich sehr stark in die Karte hinein zoomen. Und dann kann man sich denken, dass der Gipfel sehr wahrscheinlich nur eine unbedeutende Erhebung ist. Bei weniger Zoom wird bei mir nur der Gipfel dargestellt. Wenn Du Deinen Renderer als Maß aller Dinge siehst, dann störe Dich doch besser an Personen, die Landschaftsflächen, die bis zu einem Weg reichen, nur bis knapp zum vermeintlichen Wegesrand anstatt zusammenfallend mit den Knoten des Weges mappen. Diese Leute erzeugen etwa 200 % mehr Knoten als für eine schematische Karte notwendig wären. Und das ist dann wirklich übel für die Performance und ggf. auch die Darstellung eines einfachen Vektorrenderers.

Ich gewinne den Eindruck, dass Du Dich mit den topographischen Merkmalen nicht wirklich auseinandergesetzt hast. Ein Gipfel ist immer der höchste Punkt einer Erhebung. Dieser kann mit einem sog. Gipfelkreuz zusammenfallen, muss es aber nicht. Beispiele, wo Gipfel und Aufstellort des Kreuzes mehr oder weniger weit auseinander liegen, sind die Blasenka, der Schattenberg und das Rubihorn bei Oberstsdorf oder der Breitenberg bei Hinterstein. Ein Kreuz wurde oft schlicht da platziert, wo es aus dem Tal gut zu sehen ist oder wo die Wanderer besser pausieren können. Das ist nicht notwendigerweise am tatsächlichen Gipfel. Den Sattel(punkt) scheinst Du mit einer Passhöhe zu verwechseln. Ein Sattelpunkt (natural=saddle) ist entlang der Kammlinie der tiefste Punkt zwischen zwei Gipfeln/Erhebungen. Entsprechend muss es zwischen zwei Gipfeln auch immer einen Sattel geben. Ein Sattel kann passierbar sein, muss es aber nicht. Der höchste Punkt eines Passes (mountain_pass=yes) kann durch einen Sattelpunkt führen, quert die Kammlinie aber häufig an einem höheren Punkt als im Sattelpunkt. Selbst wenn es keinen Weg gibt, kann der Sattel einen Namen tragen und auch seine Höhe ist relevant. Wenn man sie von der Höhe des folgenden Gipfels abzieht, hat man ein Maß dafür, wie weit man (entlang des Kammverlaufs) mindestens aufsteigen muss, wenn man dort hin will. Ich persönlich schaue häufiger mal Sattelhöhen nach, wenn ich entscheide, ob ich den nächsten Gipfel noch mitnehme oder nicht. Wenn Du diese paar Informationen in OSM zu viel findest, dann schaue Dir doch mal eine klassische AV-Karte an und vergleiche, was da alles an Informationen zur Topographie hinterlegt ist. Auch Kammverläufe sind relevant. Vor allem bei hoher Verkleinerung/in der Übersicht lassen sie sich erheblich schneller erfassen als Höhenlinien. Bei denen kann man in der Übersicht auch mal Berg und Tal verwechseln. Ich persönlich bewege mich gerne entlang von Kammlinien und ich vermeide es bei längeren Touren, unnötig viele Kammlinien zu queren. Eine Vektordarstellung wird nur dann "überladen", wenn ein primitiver Renderer, ggf. gepaart mit veralteter Hardware verwendet wird. Ich persönlich kenne diese Problematik nur von JOSM. Und dort ist sie dadurch zu erklären, dass der Fokus auf dem Editieren der Vektorlinien liegt, weshalb ungefiltert alle Knoten und Linien darstellt werden. Und das auch bei einem sehr großen Kartenausschnitt, wo es dann entsprechend speicher- und rechenintensiv wird. Von Karten-Apps kenne ich Deine Überladungsproblematik nicht. Ein guter Vektorrenderer zur Kartendarstellung sollte abhängig von der Verkleinerungsstufe entscheiden, welche Merkmale dargestellt werden. Ggf. sind dazu bereits in den Kartendaten Entscheidungshilfen hinterlegt. In einem besiedelten Gebiet sollten z. B. Nebenstraßen, Gebäude, Läden usw. bei einem sehr großen Kartenausschnitt nicht darstellt. Erst bei ausreichend geringer Verkleinerung sollten solche Merkmale dann gerendert werden. Außerhalb besiedelter Gebiete sollte ein Renderer ähnlich verfahren. Andernfalls ist es kein guter Renderer.

Hallo,
wie wäre es, wenn Du - ehe Du einfach irgendwelche Knoten und Wege, die Information tragen löscht - die Änderungshistorie liest und bei Objekten, die einen Wikidata-Tag tragen, Dich dort darüber informierst? Den Hochblankensattel hat Walther Flaig im guten alten AVF von 1977 mehrfach erwähnt und klar beschrieben. Diesen AVF findest Du der Freigiebigkeit des DAV sogar online: https://bibliothek.alpenverein.de/webOPAC/01_Alpenvereins-Publikationen/07_AV-Fuehrer/Bregenzerwald_und_Lechquellengebirge/Bregenzerwaldgebirge_Flaig_1_Auflage_1977.pdf. Beim Ragazer Blanken steht das "Gipfelkreuz" meiner Beobachtung nach überhaupt nicht auf dem Gipfel, sondern auf einer Erhöhung knapp daneben. Es ist also der "Ostgipfel" der kartographisch zutreffende Gipfel. Was "Namengut/Flurnamen Vorarlberg" anbelangt, werden dort überhaupt nicht alle benannten geographischen Objekte abgehandelt, sondern maximal nur jene, denen einen Flurnamen zugeordnet ist. Dass Du die Darstellung sehr subjektiv "als mit unnötigem Ballast gefüllt" empfindest, mag vielleicht dadurch verstärkt werden, dass Du einen schlechten Renderer verwendest. Was machst Du denn in Innenstädten? Löscht Du da auch einfach 2 von 3 Ladengeschäften weg, weil dort zu viele auf engem Raum sind und Du Dich vielleicht persönlich nicht für Waren einer bestimmten Kategorie interessierst? Also sei hier bitte in Zukunft sensibler und bedenke, dass "überladen" und "Ballast" sehr subjektiv sind und ein guter Renderer außerdem, abhängig vom aktuellen Verkleinerungsmaßstab, sinnvolle Entscheidungen trifft, welche Objekte dargestellt werden, damit die Karte für Dich nicht überladen wirkt.