Ist das schon aufgeräumt?

Danke. Dass später neu nummeriert werden muss, ist glaub ich nie der Fall (man lässt ja für unbebaute Grundstücke Nummern frei und kann zur Not immer noch weitere einfügen nach dem Schema 21a, 21b...), aber manche Gemeinden führen Straßennamen ein ohne die Häuser neu zu nummerieren (Stillfried Haupstraße 9 statt nur Stillfried 9) um das Chaos bei der Umstellung zu vermeiden. Dafür ist es längerfristig nur eine halbe Lösung, weil die Nummern entlang der Straße nicht fortlaufend sind. Für meine Recherchen nach alter Literatur wäre es hilfreich, wenn die Konskriptionsnummern in irgendeiner Form erhalten blieben, aber sie werden meistens von den Häusern abmontiert, und es gibt leider keine öffentlich einsehbaren Verzeichnisse für alt/neu, siehe meine Frage in der Mailingliste vor ein paar Wochen.

Noch was: Die meisten Häuser in Feuersbrunn (z.B. way/503167753) sind mit addr:city=Grafenwörth getaggt. Das ist aber nur die Gemeinde. Die Ortschaft ist nicht Grafenwörth, sondern Feuersbrunn.

Zu way/706126453: So lang ist der Winzerweg nicht, dass die Orientierungsnummern bis 265 gehen können.

Ich hab dzt. wahrscheinlich öfter Zeit als du. Morgen geht's erst ab Nachmittag, weil ich ungefähr bis Mittag im AKH bin. Auf jeden Fall bräuchte ich deine Handynummer, falls was dazwischen kommt.

Das ist aber nicht "almost vertical". Ich traue mich so ziemlich jeden Betrag mit dir wetten, dass ich an jeder Stelle rauf- und runtergehen kann.

Ich hab mich da noch nie durchs Gestrüpp geschlagen, aber ich bin mir ziemlich sicher, dass da kein cliff ist. Dieses seh ich weder im Geländemodell noch auf Orthofotos, und vor Ort wäre es mir wahrscheinlich auch schon aufgefallen, und allein von der Geologie her ist es hier gar nicht möglich.

Die würde ich mit military=trench taggen (auch wenn das in den meisten Karten nicht dargestellt wird). Ob man zusätzlich barrier=ditch setzt, ist Geschmackssache, aber ich finde, das ist mit military=trench schon impliziert, und es war nicht der eigentliche Zweck der Gräben.

Users shouldn't attempt to delete random objects and rely on their editor to check if that's ok. They should only delete objects when they know what they are doing. Same for OSMI and Keepright. These are not QA tools unless their users don't know what they are doing. Most of them don't. They damage data rather than "correct" it, as they believe they do. The "nicht löschen" note was meant for those kind of users. Most of them don't read notes anyway, but at least there is a chance that they get to see the note by accident.

You are referring to the place=region wiki page, but that tag has another purpose than the boundary=region tag that you set. place=region is old, but not obsolete, and it is used rarely applications, but not so rarely by mappers. There are use cases for that tag – as opposed to boundary=region, for which there are no use cases.

It wasn't me who created the line and the node. Anyway, that sounds like a bug in your application (Osmose), not a problem in the OSM data. It was tagged like this not only for 2 years, but for 10 years, as you can see in way/168741013/history, and noone ever had a problem with it. The boundary=region tag seems strange, as I've never seen it before and it isn't mentioned in the wiki (boundary=*). Why would an application ever need that tag, when the boundaries are already defined by the set of relation members?

Das Dilemma mit Berg vs. Hang gibt es nicht nur im Leithagebirge, und man kann nur in jedem einzelnen Fall nach dem Namen, der Morphologie, der Literatur (inkl. Landkarten) und Beschilderung und Eindruck vor Ort entscheiden, auf was man den Namen setzt. In vielen Fällen haben die Einheimischen auch gar nicht so genau zwischen Gipfel, Rücken und Hang unterschieden, sondern der Berg war alles zusammen, zumindest soweit sie es von ihrer Seite aus gesehen haben. Und Bedeutungsveränderungen/-erweiterungen gab es auch schon viele ("...wand" -> Berg -> Gipfel).

Ich weiß es auch nicht. Wenn ich einen Berg aus der Basemap übernommen habe, kann es leicht sein, dass er falsch ist. Damals war ich in der Hinsicht noch etwas zu leichtgläubig.

Kannst du nicht lesen?

Warum wiederholst du ständig die Behauptung, dass die Straße nur mehr lokale Bedeutung hat, nachdem ich dir schon 2x das Gegenteil erklärt habe?
Und es steht nirgends, dass nur "internationale Fernverkehrsstraßen" primary sein dürfen. Nach dem Kriterium dürften so gut wie gar keine Bundesstraßen als primary getaggt werden.

Das ist dort der selbe Fehler. Nach deine Argumentation müsste man überall, wo eine Autobahn parallel läuft, die Bundesstraßen umtaggen, z.B. die B16 zwischen Münchendorf und Wulkaprodersdorf oder die B9 von Wien nach Fischamend. Das wird aber nicht gemacht, weil diese Straßen als Landesstraßen B als Hauptverbindungsstraßen benötigt und daher in einem guten Ausbauzustand gehalten werden, weil nicht jeder die Autobahn benutzen darf, und das hab ich dir schon eingangs geschrieben.

Für alle, die die Autobahn nicht benutzen dürfen (Kfz ohne Vignette, Mopeds, Radfahrer...), aber schon noch. Das ist eigentlich überall so, dass Bundesstraßen (Landesstraßen B), die parallel zu Autobahnen verlaufen, als primary getaggt bleiben. Wo sie keine große Verkehrsbedeutung mehr haben, werden sie zu Landesstraßen L oder Gemeindestraßen degradiert.

Man kann 3 verschiedene Meinungen haben: Dass access-Tags auf Schranken gesetzt werden *müssen*, dass es vorteilhaft aber optional ist, oder dass es nachteilhaft ist. Am meisten bringen mich erstere auf die Palme. Das sind meist Leute, die Tags setzen, ohne jemals dort gewesen zu sein, und ihre Changesets mit "Korrektur" betiteln. Oder die alles mit map notes ("is this gate accessible?") zuspammen. Mit der zweiten Gruppe ist das so, wie wenn man access=yes auf alle normalen Straßen setzt: Es kann Anwendungen nur nützen, nicht schaden, aber es macht die OSM-Daten für andere Mapper unübersichtlicher und man kann nicht mehr feststellen, was vor Ort wirklich angeschrieben ist. Insofern ist es schlimmer als oneway=no oder bridge=no, weil die zwar ebenfalls die Daten unübersichtlicher macht, aber wenigstens klar ist, dass es vor Ort nicht angeschrieben ist. Sowas hat auch praktische Auswirkungen, z.B. wenn man bicycle=no setzt auf ein lift_gate, wo eigentlich nur ein Fahrverbotsschild auf der Straße gilt. Dann löscht vielleicht ein anderer Mapper das Fahrverbot auf der Straße, weil das Schild entfernt wurde, aber am lift_gate bleibt das bicycle=no stehen. Genauso können sich auch Gesetze ändern. Manche User setzen bicylce=no auf alle Forststraßen und Pfade. Wenn das Forstgesetz geändert wird, kann man nicht mehr feststellen, wo das Verbot immer noch gilt (weil es angeschrieben ist), es sei denn, man geht alle Wege nochmal ab und schaut nach. Das ist ein riesen Aufwand. Das würde mich nicht stören, wenn diejenigen, die diese Tags gesetzt haben, dann auch diese Begehungen erledigen. Aber diese Tags werden meistens von Leuten gesetzt, die wenig bis gar keine Geländearbeit leisten. Die bürden die Arbeit also anderen auf. Das finde ich nicht ok.
Eine mögliche Kompromisslösung sehe ich in Zusatztags wie source:access (bzw. source:bicycle usw.), analog zu source:maxspeed. Dass sich das durchsetzen kann, glaube ich aber nicht, weil die Validatoren ja nur nach access-Tags schreien und nicht nach source-Tags.

Quellen für den Wachtberg als Namen sind die Josephinische (=Erste) Landesaufnahme ("Wachberg und Waldt") und die Franziszeische (=Zweite) Landesaufnahme ("Wachtberg" ist 2x eingezeichnet, also einmal die Siedlung und einmal der Berg). In beiden ist der Name weiter westlich eingezeichnet, aber der Gehöftname "Eder am Wachtberg" legt nahe, dass sich der Berg zumindest bis hierher erstreckt. Leider kann "am" im österrischischen Deutsch sowohl "auf dem" als auch "an dem" (= am Fuß des) bedeuten. Weil das Gehöft höher liegt als alles weiter westlich, kann "am Fuß" nicht gemeint sein.

Wenn du über Ortskenntnis verfügst, dann entscheide halt du über die genaue Verortung und Typisierung (natural=peak/ridge/slope/wasauchimmer oder schlimmstenfalls place=locality). Ich habe in Taginfo gerade natural=river_terrace entdeckt, was auch passen könnte, aber das Proposal dazu ist ungültig (Status "proposed", aber kein RFC date) und unausgereift (als Linie mappen, aber von wo bis wo? sollte nicht links=oben definiert werden? was ist ele=* bei einer Linie?).

Zu deinem Revert siehe Diskussion dort.
access=* steht seit jeher, d.h. seit 2006, ausschließlich für Berechtigung, siehe History von Key:access im Wiki. Dass barrier=(lift/swing)gate seit einigen Jahren mit bicycle=yes und foot=yes zugespammt werden, liegt an einer defekten Validatorregel, die sich wahrscheinlich ein einziger Entwickler ausgedacht hat. Auf andere Barrieren setzt kein Mensch irgendwelche access-Tags, weil der Validator darauf nicht anspringt.
Ob alle Router access-Tags auswerten, ist hier irrelevant. Es geht ja nicht darum, ob sie gesetzte Tags auswerten (das wollen wir doch hoffen), sondern welche Defaults sie annehmen. Wie du leicht an dieser Straße ausprobieren kannst, routen alle 5 auf openstreetmap.org auswählbaren Router sehr wohl drüber, d.h. sie nehmen auf barrier=lift_gate richtigerweise access=yes als Default an.
Dein Beispiel kann ich schwer überprüfen (Graz ist weit weg), aber wenn es stimmt, dass nur bestimmte Personen den Schranken öffnen bzw. passieren dürfen, dann ist er derzeit falsch getaggt, denn alle angegebenen access-Tags stehen auf yes.

Andere Quellen? Wie viele brauchst du? 10? 100? Relevanz hat der Gipfel dadurch, dass der Berg einen Namen hat. Man kann ihn auch als Linie mit natural=ridge mappen, aber dann muss man sich genauso entscheiden wo.
Woher willst du wissen, was die Leute in der Gegend wie bezeichnen? Bist du aus der Gegend? Oder hast du unter den Bewohnern eine Umfrage gemacht?