Das eine Item wurde von Mr.Ibrahembot erstellt. Das andere von Sk!db8t. Sieht aus wie Kandidaten zum Mergen.

Die Erhebungen bilden einen zusammenhängenden Kammverlauf, der sich deutlich aus dem Relief abzeichnet. natural=ridge ist weder auf bestimmte Regionen noch auf bestimmte Metriken der Erhebungen beschränkt.

This is what the notes are actually good for. When determining and checking key cols, prominence and parent peaks, such small notes are very helpful to avoid confusion of saddles.

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.