@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.

zu way/968242591 :
Wildgehege schreibt man nicht mit Umlaut und ist kein Name, sondern ich würde nur barrier=fence und description=* und access=private setzen.
Interessant wär, ob das ein forstliches oder ein jagdliches Sperrgebiet ist und mit welcher Begründung. Sonst darf der Besitzer das Betreten gar nicht verbieten.

Du meinst den scheinbaren Flurnamen, der nicht am Graben, sondern am Rücken östlich davon steht? Diese Namen sind aus dem franziszeischen Kataster abgeschrieben, wo sie oft nur zu Orientierungszwecken an Ecken der Einzelblätter und darum an falschen Stellen (in diesem Fall sogar an dreien) stehen. In diesen alten Karten sind fast alle Zusammensetzungen mit -graben, -wald, -wiese usw. getrennt geschrieben. Vor allem dann, wenn das Bestimmungswort abgekürzt ist (Gr., W., Ws., Kg., B. ...), hat das einen guten Grund: Sonst könnte man oft nicht erkennen, wo das Bestimmungswort endet und die Abkürzung des Grundwortes anfängt (Starkg. = Starkgipfel oder Starkogel? => darum Stark G. oder Star Kg.).

Ich habe dir schon erklärt, dass die Wege sogar im Geländemodell erkennbar sind. Wege als Flurschäden zu bezeichnen ist eine Absurdität, die mir noch nie untergekommen ist. An deinen beruflichen Kontext zur Forstwirtschaft, den ich wegen solcher Terminologie angenommen habe, glaube ich immer weniger. Damit hättest du gar nicht die Zeit, um Tag und Nacht vorm Computer zu sitzen. Ich warte immer noch auf eine Reaktion der DWG, und wenn die sich raushalten, muss ich selber versuchen, deine Verwüstungen so gut es geht wieder in Ordnung zu bringen.

Es geht hier nicht um die neue Forststraße (die wäre auch ohne dein Zutun bald eingezeichnet worden), sondern um die von mir und anderen gemappten Wege, die du umgetaggt bzw. gelöscht hast.

Die Höhlen in Richtung Schneeberg konnte ich nur deshalb mappen, weil keiner meine Wege gelöscht und mich damit in Gefahr gebracht hatte. Wenn du dort das gleiche gemacht hättest wie hier, wäre ich heute tot.

Es wird in der Tat lächerlich. Erst wusstest du nichts von den Höhlen und jetzt tust du so, als läge es nur an fehlender Liebesbekundung, dass du sie nicht gemappt hast. Fakt ist, dass du hier noch nie was Konstruktives beigetragen hast, sondern nur bestehende Daten beschädigst.

Du hast vorher auch schon keine Höhlen gemappt. Du verstrickst dich immer mehr in Widersprüche. Erst die neue Forststraße, jetzt die Höhle.

Den Unterschied zwischen Schneise und track habe ich schon beschrieben. Was du als Harvesterspur bezeichnest, sind Wege, die schon länger existieren, wie man im Geländemodell sieht. Außerdem haben Harvester und Traktor/Geländewagen verschiedene Spurweiten.
Natürlich gibt es hier viel, nur kennst du es nicht, weil du entweder nicht dort warst oder mit Scheuklappen gefahren bist. Sonst wüsstest du, dass 3 m neben dem Rand der Forststraße, auf der du so oft gefahren sein willst, eine Höhle ist.