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?

@Luzandro: Im Proposal steht aber auch nicht, dass es auf Schranken richtig ist, sondern dass es eine andere Bedeutung hat als locked=*. (Der Abschnitt heißt "Rationale", also Proposal-Begründung.)
Ein Rechtsgrundsatz lautet, "was nicht verboten ist, ist erlaubt", und davon sollten auch Router ausgehen. Aber letztlich können wir den Router-Entwicklern keine Vorschriften machen. Es gibt ja auch welche, die über highway=track nicht drüberrouten. Manche Kfz- und Rennradfahrer sind sogar froh, wenn sie über solche Schotterstraßen nicht geroutet werden. Es bringt nichts, sich beim Mapping über alle solchen Auswirkungen Gedanken zu machen. Bitte mappt einfach das, was dort ist.

Ich habe nichts dagegen, wenn du Kollateralschäden behebst, die bei einem Revert entstanden sind. Z.B. layer=1 auf way/504449885 - Asche auf mein Haupt, dass ich das nicht selber gemacht habe. Bei manchem bin ich mir nicht sicher bzw. es kann sich seit meinem letzten Besuch geändert haben (maxspeed=40, surface=compacted vs. fine_gravel). Manche deiner Änderungen sind aber einfach falsch: lanes=1 ist irreführend bei einer 5 m breiten Straße, wo Gegenverkehr nirgends ein Problem ist. Und was du dir bei waterway=tube gedacht hast (Ways 975129574, 975129576) bleibt ein Mysterium. Dieses Tag hat nicht mal eine Wikiseite. Bei way/975129574 vermute ich nach Geländemodell und Orthofoto, dass dort überhaupt eine Brücke ist.

@Woazboat Ich habe nie behauptet, dass keiner access-Tags auf Barrieren setzt. Sondern dass es falsch ist, weil access=* für die Berechtigung steht und nicht für physische Passierbarkeit. Wenn ein Router falsche Annahmen trifft, ist das ein Bug im Router => ggf. Bugreport erstellen. Wir mappen nicht für den Renderer und auch nicht für den Router. Selbst wenn ein Schranken zu ist, aber nicht abgesperrt, ist er passierbar und es spricht nichts dagegen, darüber zu routen. Wenn ein Schranken abgesperrt ist, dafür gibt es locked=yes. Das ist relativ neu und dir und manchen Router-Entwicklern vielleicht noch nicht bekannt. Es wurde über ein ordentliches Proposal (mit Abstimmung) eingeführt und genau mit dem Zweck, dass access-Tags nicht mehr dafür missbraucht werden.
Zum PS: Wenn du mit Fällen argumentierst, die real nicht vorkommen, kannst du genausogut access-Tags für Drachen und Klingonen setzen.
Mein eigenes PS: Während einer laufenden Diskussion mit einem Revert loszufahren ist nicht in Ordnung!

Die Aussage "Combine with access=* where appropriate" gehört m.E. gelöscht, weil es eigentlich nie appropriate ist. Genauso stand auch jahrelang im deutschen Wiki im Widerspruch zur englischen Seite, access=no stehe für "Benutzung nicht erlaubt oder nicht möglich", bis sich jemand erbarmt und das "nicht möglich" rausgelöscht hat. In den Köpfen vieler deutschsprachiger User ist das "nicht möglich" immer noch drinnen, und darum bilden sie sich ein, sie müssten mit access-Tags angeben, ob die Querung eines Schrankens möglich ist. Das ist allein schon deshalb absurd, weil ein Schranken dazu da ist, manchmal offen und manchmal zu zu sein. Man kann seriös bestenfalls angeben, wann oder wie oft er zu ist, nicht ob. So ähnlich wie ob eine Ampel auf Rot steht.

Zunächst mal muss man die Berechtigung (access)=* davon unterscheiden, ob bzw. wann der Schranken geschlossen ist. Berechtigungen sind in Österreich immer nur für Straßen angeschrieben, nicht für Schranken. Wer access=* auf einen Schranken taggt, macht das um einen fehlerhaften Validator zu befriedigen, nicht um die Realität abzubilden. Was die description=* wegen der Lawinengefahr betrifft, da bin ich mir nicht sicher. Die Löschung ist durch den Revert passiert, der aus anderen Gründen notwendig war. Ich war zuletzt vor 2 Jahren dort, und da war nicht angeschrieben, dass der Schranken nur bei Lawinengefahr zu ist. Selbst wenn er bei Lawinengefahr zu ist, kann man daraus nicht schließen, dass er *nur* bei Lawinengefahr zu ist. Ich hab schon mal erlebt, dass die Straße wegen Holzbringung gesperrt war (aber ich glaube, der Abschnitt war eher im Westen und der östliche Schranken war offen). Solche Schranken, die üblicherweise nur bei Lawinengefahr zu sind, kenne ich auch im Adlitzgraben und bei Stans. Man kann da nie ausschließen, dass sie nicht auch in anderen Fällen (z.B. bei einem Unfall oder bei Bauarbeiten) gesperrt werden. Ich glaube, selbst wenn der Schranken zu ist, wird in den seltensten Fällen ein Schloss dran hängen, sonst würde womöglich jemand auf der Straße eingesperrt werden, Einsatzfahrzeuge könnten behindert werden usw. Wie auch immer. Vor Ort überprüfbar ist nur die Existenz des Schrankens, alles andere ist Fantasie oder verlangt Insiderwissen, auf das besser in einem note=* o.dgl. hingewiesen werden sollte. osm.wiki/Verifiability

1) Laserscan (LIDAR)
2) Das siehst du schon an den Siedlungsnamen (... am Wachtberg), aber auch in der Josephinischen Landesaufnahme.

Ich weiß nicht, wer derzeit was wie rendert, aber grundsätzlich hat sich nichts daran geändert, dass die ganze automatische Umtaggerei regelwidrig war und ebenso das Umschreiben des Wiki und das deprecated-Setzen. Mir konnte noch keiner sagen, was an ford=yes besser sein soll, noch dazu wo solche *=yes Tags normalerweise nur als Attribute gesetzt werden und nicht als Main-Tags. Darum setzt man ja auch highway=crossing, railway=crossing, highway=traffic_signals, waterway=weir usw. und nicht crossing=yes, traffic_signals=yes, weir=yes usw.
Mit jemandem, der sich als Entwickler von Grasshopper ausgab, hab ich schon mal gestritten, weil er auf access-Tags auf allen barrier=lift_gate/swing_gate bestand und dabei erstens nicht verstehen wollte, dass access-Tags für Berechtigung stehen und nicht für physische Passierbarkeit, zweitens dass zumindest in Österreich die Berechtigungen immer für Wege und Areale gelten und nicht für die Überwindung von Barrieren, und drittens dass gates dafür gemacht sind, manchmal offen zu stehen und manchmal nicht. Was für Anwendungsentwickler so schwer dran sein soll, highway=ford und ford=yes gleich zu behandeln, ist mir ein Rätsel. Anwendungsentwickler sollten die Daten nehmen, wie sie in der Datenbank stehen, und wenn man z.B. 100 verschiedene Schreibweisen eines Namens findet, dann muss man halt, wenn man es ordentlich machen will, jede einzelne davon berücksichtigen. Wie auch immer. Wer unbedingt für den Renderer (oder Router) mappen will, der darf von mir aus zusätzlich ford=yes setzen, aber bitte nicht meine mit Bedacht gewählten Tags rauslöschen und auch nicht als Changesetkommentar irgendwas von "Korrektur" oder "Fix" schreiben.

This changeset has been reverted fully or in part by changeset/117734635 where the changeset comment is: revert 117494739

Das Fehlen der Seehöhe war ein Versehen. Ich hab sie jetzt nachgetragen. Auf der Gipfelbuchkassette steht übrigens die falsche Seehöhe 941m.

way/176134937 kann nicht stimmen. Aber wahrscheinlich reicht es, den einen Node rauszunehmen.

This changeset has been reverted fully or in part by changeset/117064774 where the changeset comment is: revert 43317886

This wasn't a typo but the normal spelling.