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.

Von Eyb und Harratried aus schon. Zu Fuß und per Rad ab Radweg an der B12. Zur B12 hin und nach Brettweg stehen aber noch Absperrungen.

Nicht gelöscht, sondern von den x Pfadabschnitten zur einen Relation "Leckner Ach" verschoben.

Die Vektorlinien sind jetzt zusätzlich mit source="Datengrundlage: LGL, www.lgl-bw.de" getaggt. Somit ist die geforderte Quellenangabe nun definitiv an gut sichtbarer Stelle eingebunden.