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.

Why did you delete Hochblankensattel node/12690297174?

Sollte wahrscheinlich "Detail" heißen. Schau es Dir doch an.

Hallo mcliquid,
der Bach war etwas zu lang eingezeichnet. Auf der anderen Seite des Kamms ist eine fluchtende Erosionsrinne. Bach jenseits des Kamms ist gelöscht: changeset/170739039#map=16/47.33360/10.14267&layers=P

An unnoticed leftover from the source data. To be replaced with building=roof.

Invalid tag already deleted.

Looks like a mixed up key-value pair that somehow got added to the node.

Danke für den Hinweis. Ich habe unter note/4642558#map=15/47.61973/9.95057 darauf geantwortet. Falls die Bezugsscharte des Hirschbergs im Pfänderstock doch nicht auf der Bahnstrecke (künstlich) liegen sollte, liegt sie zwischen diesen unscheinbaren Hügeln, die auch kartiert sind, aber nicht von jedwedem Renderer dargestellt werden.

Servus,
ich folge der allgemeinen Regel, dass ein Sattel anhand der Topographie über einen Knoten im Sattelpunkt kartiert wird. Dass der Sattelpunkt und der Scheitelpunkt eines Passes über den Sattel nicht zusammenfallen, ist dabei gar nicht ungewöhnlich. Weil die tiefste Linie traditionell bereits dem Wasser gehört, wird sie vom Passweg ja gemieden und das oft auch am höchsten Punkt. Was ich an dieser Stelle aber tatsächlich vergessen habe, ist den Tag natural=saddle vom Passscheitel zu entfernen. Das habe ich jetzt nachgeholt. Danke für den Hinweis!

In diesem Fall schienen mir die Hinweise für eine Fehleintragung wirklich zu überwiegen.

1. Der ursprüngliche Eintrag nennt als Quelle lediglich ein Satellitenbild. Von lokalen Namen ist keine Rede.

2.Topographisch könnte man die Stelle als Kar auffassen. Es wäre aber wirklich ein sehr kleines und unscheinbares Kar. Zumal die dominante Hochgletscherwanne weitere ähnlich große "Ausbuchtungen" hat, die namenlos sind.

3. Weder VoGIS Landkarte noch VoGIS Flurnamen benennen die Stelle.

4. Weder die AV-Karte von 2019 noch der AV-Führer von 2008 benennen die Stelle.

5. Selbst der AV-Führer von 1977, der im Braunarlzug die Wannen, Grate, Scharten, Gipfel und selbst einzelne Graterhebungen sehr detailliert beschreibt, benennt für das gesamte Lechquellengebirge kein einziges Verborgenes Kar. Der AV-Führer liegt mir eingescannt, vollständig durchsuchbar vor.

6. Alle anderen Kare im Braunarlzug tragen den Namen "Wanne".

7. Ein Verborgenes Kar gibt es dagegen namentlich erwähnt/bezeichnet in den Lechtaler Alpen sowie im Zentralen Hauptkamm und der Hornbachkette der Allgäuer Alpen. Es sind keine großen Kare, aber deutlich ausgeprägter und eigenständiger.

Hast Du die Einwohnerzahlen mal hinterfragt? Bei den Orten war nicht die Einwohnerzahl des Orts, sondern die der Gemeinde eingetragen. Also falsch. Bei der Gemeinde wird die Einwohnerzahl laut Wiki aber nicht eingetragen, da in Wikidata aktueller.

Die Übersetzungen kommen aus der Migration der Tags aus den Hauptorts- und Gemeindeknoten. Wahrscheinlich wurden sie von chinesisch- und ukrainischsprachigen Nutzern eingepflegt. Als ich in Japan war, fand ich es auch sehr nett, dass es parallel zu den lokalen Namen meistens auch englische Labels gab.

Die name:de-Tags machen vermutlich keinen Sinn. Die sind mir beim Kopieren der name-Tags mit durchgerutscht.

osm.wiki/DE:Tag:place%3Dmunicipality

population=* - kann aktueller über Wikidata ermittelt werden

Für mich ist das einleuchtend. Es muss ja nicht jedwede Information in die Karte gepackt werden. Wenn es einen "Single Point of Truth" gibt, ist das an und für sich immer besser.

Weil im OpenStreetMap-Wiki erklärt ist, dass population nicht mehr gesetzt werden soll, weil sich aktuelle Zahlen über das Wikidata-Item ermitteln lassen. Die Zahlen sind ja tatsächlich meistens veraltet. Beim Hauptort ist auch oft nicht dessen Einwohnerzahl, sondern die der Gemeinde eingetragen.

Ich habe die drei Gemeinde-Knoten jetzt, den allgemeinen Richtlinien folgend, aus den Siedlungsgrenzen geschoben, die heutzutage unnötigen Tags entfernt und sie mit der Rolle "label" in die jeweilige Grenz-Relation eingefügt: changeset/160978019#map=12/47.4206/9.9617&layers=P

Ich habe nur diese drei Gemeinden bearbeitet, weil ich OpenStreetMap praktisch immer zusammen mit Wikidata bearbeite und von den Bergen ausgehend bei diesen drei Gemeinden darauf aufmerksam geworden bin, dass die Zuordnungen nicht stimmen. Die Notwendigkeit kommt dann daher, dass Wikidata (wohl meist auf Basis von GeoNames) die Gemeinde und den gleichnamigen Hauptort sauber unterscheidet. Das macht ja auch sind, denn es sind zwei unterschiedliche Entitäten mit voneinander abweichenden Attributen (z. B. Einwohnerzahl). Man würde ja z. B. auch nicht den Ort Sulzberg mit dem Sulzberg(rücken) vermengen, nur weil sie gleich heißen.

Wenn man beim Ort die korrekte Wikidata ID setzt, stellt die Prüfroutine von JOSM fest, dass Wikidata ID und Wikipedia-Artikel nicht zusammenpassen (die Artikel beziehen sich ja immer auf die Gemeinde und thematisieren den Ort nur mit). Also ist die beste Lösung, Wikidata ID, Wikipedia-Artikel und ggf. weitere auf die Gemeinde zutreffende Tags in den einen separaten Gemeindeknoten zu verschieben. Dann kann der Ort sauber bidirektional mit Wikidata verknüpft werden. Dort gibt es ein korrespondierendes Attribut "OpenStreetMap node ID".

Wenn jemand die Zeit investieren will, kann er natürlich die anderen Gemeinden in Vorarlberg auch entsprechend anpassen. Ich selbst arbeite eher nach dem Prinzip, dass steter Tropfen den Stein höhlt. Ich denke, dass der separate Gemeinde-Knoten und die label-Rolle in der Grenzrelation insofern sinnvoll sind, als dass dann für Renderer klar festgelegt ist, wo der Gemeindename und die damit verknüpften Informationen, wie der Wikipedia-Link, auf der Karte platziert werden sollen. Die Grenzrelationen selbst werden von manchen Renderern nicht dargestellt und sie sind auch generell schlecht greifbar, weil es in der Natur ihrer Sache liegt, dass sie meistens irgendwo ganz am Rande verlaufen.

Also müsste ich die Knoten noch etwas weiter vom Ort weg verschieben und dann in die Relation einfügen. Ich vermute mal, dass die Label-Rolle genau dafür angedacht ist, den Ort auf der Karte festzulegen, an dem die Informationen zur Gemeinde angezeigt werden sollen.

Wenn ich osm.wiki/DE:Tag:place%3Dmunicipality richtig verstehe, soll der Knoten place=municipality sogar immer zusätzlich zur Grenz-Relation erstellt werden:

Zeichne einen Punkt in der Mitte der Gemeindegrenzen (aber nicht in einer Ortschaft) und füge Folgendens hinzu:

place=municipality
name=*
wikidata=*
wikipedia=*

Der Punkt wird der dazugehörigen Grenz-Relation mit der Rolle label hinzugefügt werden.

Oder, wenn es eine Stadt mit demselben Namen gibt, wird diese mit der Rolle admin_centre der Grenz-Relation hinzugefügt.

Das solltest Du besser die Bewohner der Gemeinden fragen. Die können Dir sicherlich viele Dinge nennen, die ihre Gemeinde besonders machen.

Da Du die Knoten aufführst, willst Du aber wohl eigentlich fragen: "Warum hast Du für die Gemeinde einen neuen Knoten angelegt, wo es doch schon einen Knoten für das Dorf gibt, das ebenso heißt?"

Antwort: Weil sich die verschobenen Tags zu Wikipedia, Wikidata, Einwohnerzahl usw. auf die Gemeinde beziehen und nicht auf das Dorf, welches nun im Gegenzug die korrekte Wikidata ID zuordnet haben sollte. Alternativ könnte man die Gemeinde-Tags vermutlich auch in die Relation mit den Gemeindegrenzen verschieben. Der Nachteil ist dann, dass unklar ist, ob und falls ja, wo Renderer wie OsmAnd, die ein Wikipedia-Overlay für die Karte bieten, das Wikipedia-Icon zur Gemeinde darstellen würde.