This is an OSMI bug. I've now reported it at: https://github.com/geofabrik/osmi_simple_views/issues/49

You should never trust validators blindly, but always use your own brain to determine what is wrong and what is right. First of all, when you edit landuse, you should check with recent aerial images. In this case, you would immediately see that there are forest areas between the scree and the bare_rock, and therefore it can't be right to add them as inner members to the forest multipolygon.

When you add inner members to a forest multipolygon, thus specifiying that these areas are not forest, you should also ask yourself what landuse there is instead. If you don't know, don't edit it. Create a map note or ask/tell the original mappers.

Austria is a country with a high density of competent mappers. Many of us check for errors regularly. So you don't need to do this, particularly if you don't speak the local language and don't know the specifics of alpine regions. You better focus on countries with a low density of mappers, or the area(s) where you live and have local knowledge.

Please write in English or German. I don't understand Italian, and this area is not in Italy.

This changeset has been reverted fully or in part by changeset/123773269 where the changeset comment is: 113231318 revertiert, weil falsche inner-Members hinzugefuegt wurden; siehe auch meinen Kommentar zu changeset/84477499

Die Changesetbeschreibung stimmt nicht mit dem überein, was bei dem Edit passiert ist. Da wurde der Name des Steinbruchs verändert (2 Werte mit Strichpunkt zusammengestückelt statt alt_name) und ein tagloser Node gelöscht, vielleicht Teil des Steinbruchrandes.

Oops. Thanks. I'm going to fix that.

I already wrote in my first comment that baryte is the normal spelling. Google reports 6.930.000 of baryte vs. 4.800.000 of barite. Of course I hope that my preferred spelling will outnumber the other spelling variant one day, but that only works if people like you don't attempt to "correct" the "typo", thereby reversing the normal course of tagging evolution. Words can hardly describe how evil your interference is.

I already explained to you why it's not a wrong value.

I have no time for edit wars in the Wiki, and I've never said that "barite" was wrong. I just said that I had a good reason to spell it with "y", and that it wasn't a typo.

Sorry, war note #3243382, nicht #2945120.

Looks like I need to be more careful. I've upgraded to a new Merkaartor version recently. Maybe it doesn't snap nodes in the same manner as its predecessor. Anyway, I've now corrected the mistake here. Thanks for the info.

Sorry, I left that gap by accident. Thanks for the message. I've now connected the ways.

Vielleicht habe ich ihn mit dem bei Alland verwechselt. Beide neben der Autobahn und von SW bis W her am schnellsten zu besteigen.

Das ist wahrscheinlich noch mit Barometer gemessen, den ich an einer Kote kalibriert hatte. Also ungenau. Kannst du gern nach Laserscan korrigieren. Evtl. auch die Position, aber da ist der Fehler sicher geringer wegen des relativ guten GPS-Empfangs auf Gipfeln.

addr:suburb=Liesing würde ich nicht taggen, weil man das in Adressen normalerweise nicht reinschreibt. Außerdem ist nicht ganz klar, was damit überhaupt gemeint ist: Bezirk Liesing oder Katastralgemeinde Liesing oder der ehemalige Vorort (jetzt place=suburb).

Der Name steht zumindest in der höhlenkundlichen Literatur. Dort den Literaturverweisen rekursiv nachzugehen könnte länger dauern...

Ich meinte motorway_link.

Unter emergency access verstehe ich sowas wie Feuerwehrzufahrten zu Wohnhausanlagen. Die Zufahrten auf Autobahnen sind glaub ich eher nur für den Straßendienst. In deinem zweiten Beispiel sind bezeichnenderweise Gebäude von Asfinag und Straßendienst daneben. Ich würde sie wie gesagt als track taggen. Rein nach Spezifikation müssten wir sie eigentlich als trunk_link taggen, aber das würde die meisten Anwender irreführen, weil trunk_link so prominent gerendert wird, und ich schätze, daran ändert auch access=private nicht viel.

Hab ich tw. schon gemacht (z.B. way/27479563/). Aber ich kann nicht alles alleine machen, und es wird sowieso alles immer wieder hin und her umgetaggt.

Sobald es eine Zufahrt nicht zu einem einzelnen Haus oder einer einzelnen Firma, sondern einer ganzen Siedlung oder einem ganzen Industriegebiet ist, ist es kein highway=service mehr, sonst müssten wir so ziemlich alle Straßen als service taggen. Wer diesen Schranken benutzt, weißt du genausowenig wie ich. Ich wette, da fuhren früher etliche Lkw durch, zum Leidwesen der Anwohner südwestlich, und mit der Fertigstellung der Autobahnanschlusstelle konnte man diese Verbindung sperren und zu dem Zweck den Schranken errichten. Ich schätze, dass Straßendienst usw. den Schranken nutzen, und insofern passt track als "Wirtschaftsweg" eh. highway=track ist ja nicht auf Feldwege beschränkt, sondern auch für Forststraßen, Straßen in Steinbrüchen usw., also überall wo Arbeiten im Gelände anfallen, und da passen Wege, die dem Straßendienst dienen, ganz gut dazu.

Du bist ungefähr so lang bei OSM wie ich. Also muss dir bewusst sein, dass in Österreich unclassified für Freilandstraßen verwendet wird und residential für Ortsgebiet. Das Konzept, Landuse auf Straßen zu taggen (siehe auch abutters=*), war dem ursprünglichen Design von OSM als mit GPS aufgenommener Straßenkarte geschuldet. Da konnte man abseits von Straßen nicht viel mappen, es gab noch nicht mal building=*. Die ersten österreichischen Mapper haben Straßen von vornherein unabhängig von Landuse getaggt und daher mussten wir uns später nie mit dem Fehldesign herumplagen.
maxspeed=50 + source:maxspeed=AT:urban gilt auf highway=residential automatisch, und ich finde es keine gute Idee, das explizit zu taggen, weil unerfahrene Mapper dann denken, das gehört so, und dann alles mit diesen Tags zupflastern, auch dort, wo sie es gar nicht wissen. Genauso wie die iD-User das mit den access-Tags machen.
Das war auch hier so, dass unerfahrene User falsche maxspeed und source:maxspeed gesetzt hatten, tw. widersprüchlich (unclassified mit AT:urban u.dgl.), tw. nicht der Realität entsprechend (maxspeed=100 wo in Wahrheit Ortsgebiet ist), und tw. waren Abschnitte unterschiedlich getaggt. (Sonst wär mir das gar nicht aufgefallen.)
Zum Track: Ist nicht ganz passend (kein Wirtschaftsweg), aber alles andere ist noch falscher, z.B. highway=service, als was es zuvor getaggt war. Es ist keine Zufahrt (zu was?), sondern ein Weg zum Durchfahren, einerseits für Berechtigte (die den Schranken öffnen können), andererseits für Radfahrer (die am Schranken vorbeifahren, den Weg hab ich wegen baulicher Trennung separat gemappt, war vorher nicht, aber auch bei dem kann man sich übers Tagging streiten).