Hmm, ich hab mir den Wiki-Eintrag jetzt genauer angesehen und da scheint mir über das Proposal doch zu früh abgestimmt worden zu sein, weil das Tag nicht so recht auf Aufbahrungshallen passt: "Morgues, mortuaries and other places which are only there for the storage of dead bodies do not qualify as funeral halls. The same is true for places where a deceased person's body is kept between death and the funeral in order to allow friends and family to visit the body during that time [...] If you know that this is the case for a given funérarium (or corresponding place in another country), then do tag it as a funeral hall irrespective of its name". Eine Aufbahrungshalle ist nun aber in erster Linie zur Aufbahrung da und nicht für Trauerfeiern. Es kommt zwar vor, dass in der Aufbahrungshalle Trauerreden gehalten werden, aber das ist nicht die Hauptfunktion einer Aufbahrungshalle.

Aha, das ist eine ganz neue Erfindung. Ja, da scheint mir nichts dagegen zu sprechen. Nur würde ich das Tag auf das Gebäude setzen und nicht auf einen Node, es sei denn, ein Teil des Gebäudes wird anders genutzt.

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

Wenn ein Weg, der zu einer Höhle führt, eine Fehlermeldung auslöst, dann sollte dir als mitdenkendem Anwender schon klar sein, dass die Fehlermeldung ein Blödsinn ist und der Fehler nicht in den Daten, sondern im Editor liegt.
Hier gibt es also 2 Editor-Bugs: 1.) die Fehlermeldung, 2.) dass der Editor zulässt, dass Ways mit nur 1 Node entstehen.
Um diese Bugs den Entwicklern zu melden, bin ich nicht der richtige, weil ich diesen Editor nicht benutze. Das kannst nur du selber machen oder jemand, der sich mit dem Editor iD auskennt und den Fehler reproduzieren und beschreiben kann (was muss man genau tun, dass das passiert, usw.) und ggf. dann auch den Bugfix testen kann. In den Bug-Meldungen kannst du natürlich gleich mal diesen Changeset als Beispiel anführen.

Du hast irrtümlich die Höhle als Endpunkt des Weges gelöscht. Dabei ist ein Weg mit nur einem Node entstanden – ein böser Bug, der den Entwicklern des Editors (iD) gemeldet werden sollte.

Da stimmt was nicht. Auf der Dürren Wand gibt es keine Falkensteinhöhle, und die Links gehen zur Einödhöhle, die wieder ganz woanders ist.

Die Löschung der Wege scheint ok, aber warum hast du die Schwarzbergschichtfuge zur Schwechat hin verschoben? (node/952557521/history)

Hallo, du bist ja voller Eifer und und anscheinend auch Ortskenntnis. Aber um so wichtiger ist es, dein Wissen richtig in die Openstreetmap rüberzubekommen. Du setzt überall den Straßennamen und die Hausnummer in den Gebäudenamen. So gehört das nicht. In den Gebäudenamen gehört nur der Name des Gebäudes (bzw. der Firma), sofern es überhaupt einen gibt. Die Adressen gehören ausschließlich in addr:street, addr:housenumber usw. Es schaut zwar schön aus, wenn die Adresse in der Karte angezeigt wird, aber was schön ausschaut, ist halt nicht immer richtig.

Kannst du dir note/2324242 anschauen, du hast den Kreisverkehr zuletzt bearbeitet.

Du kennst die endlose Vorgeschichte zu diesem Dokumentationsfehler nicht. Also zunächst mal: Die Werte sind auf der access-Seite definiert, und da wiederum ist die englischsprachige Version die Referenz: access=*#List_of_possible_values
Leider haben über die deutsche Übersetzung die Deutschen eine Art Gewaltherrschaft erlangt (immerhin sind sie uns gegenüber zehnfach in der Überzahl) und sie sind ausgesprochen ignorant gegenüber Gesetzen anderer Länder. Sie sind der Meinung, dass "Anlieger frei" heißt, dass jeder zufahren darf, weil es in Deutschland mal ein derartiges Gerichtsurteil gab. Dass in Österreich "ausgenommen Anrainer" wirklich nur für die Anrainer gilt, geht in ihre Köpfe nicht hinein.

PS: Aufmerksam geworden bin ich auf deine Edits über note/2278408. Wie du siehst, erwarten sich normale Menschen, dass eine Suche nach "Amstetten" zum Ort führt und nicht zum Bezirk.

Diese Massenedits sind auf 2 Gründen nicht in Ordnung: Erstens weil sie nicht abgesprochen sind (siehe osm.wiki/Automated_Edits_code_of_conduct) und zweitens weil sie sachlich verkehrt sind. Das Wort "Bezirk" muss im name-Tag enthalten sein, damit z.B. die Gemeinde Baden vom Bezirk Baden unterscheidbar ist. Sonst ist die Bezirksgrenze in der Karte genauso beschriftet wie die Gemeindegrenze und keiner weiß, welche davon es ist. Die Sache wurde schon oft diskutiert, z.B. in der Mailingliste Talk-at. Viele vertreten die Meinung, dass "Bezirk" nicht Teil des Namens ist, aber es besteht ein Konsens, dass name:prefix:at NICHT das richtige Tag ist um diese Information auszulagern. Denn es gibt für dieses Tag weder eine Definition noch ein Proposal, und das :at am Schluss macht es noch unwahrscheinlicher, dass internationale Anwendungen je dieses Tag auswerten. Ich habe einst ein Proposal für ein einheitliches Tag gestartet (osm.wiki/Proposed_features/admin_title), aber es wurde abgelehnt, und daher bleibt uns bis auf weiteres nichts anderes übrig, als "Bezirk" im Namen zu lassen.
Ich ersuche dich daher, alle diese Änderungen rückgängig zu machen. Oder wenn du das nicht kannst, dann kann ich das für dich machen. Oder die DWG (Data Working Group).

Wenn es wirklich eine Kapelle ist (= groß genug um von einem Menschen betreten zu werden), kannst du dann bitte ein building=chapel hinzufügen, damit Anwendungen das erkennen können? Am besten nicht als Punkt (Node), sondern als Fläche (hier ein Quadrat oder Rechteck) einzeichnen. Falls es jedoch keine Kapelle, sondern nur ein Bildstock ist, genügt historic=wayside_shrine (statt amenity=place_of_worship).

This changeset has been reverted fully or in part by changeset/88215305 where the changeset comment is: changeset/88213678 revertiert, weil damit ein unzutreffendes Tag hinzugefuegt wurde

node/1426828800: Nölltal? Dort ist doch gar kein Tal?

Statt shop=yes wär besser eine Konkretisierung wie shop=houseware, und zusätzlich sollte hier ein craft=* gesetzt werden, z.B. craft=blacksmith, aber vielleicht gibt es einen noch passenderen Wert.

Du brauchst dich nicht entschuldigen, hast ja nach bestem Wissen gehandelt. Ich muss gestehen, dass ich mich mit StreetComplete nicht auskenne, habe es noch nie verwendet. Ich setze immer Wegpunkte am Garmin (oder merke mir, was ich gesehen habe) und editiere dann alles daheim mit Merkaartor. Der Nachteil ist, dass ich fixmes oder fehlende Tags erst dann bemerke, wenn es schon zu spät ist und ich nicht mehr vor Ort nachschauen kann (es sei denn, ich fahre nochmals hin).

Ich war noch nie in der Gegend und kenne den Steig nicht, aber so wie ich note #2224324 verstehe, hat ein Bergsturz einen Teil verschüttet. Dann müsste im Südosten, vielleicht auch am anderen Ende, der Steig noch erhalten geblieben sein.

Aufgefallen ist es mir bei way/112765816, ein anderes Beispiel ist 112761031. Der Mittelstreifen ist tatsächlich grass, aber in der Praxis sind die Bereiche, wo die Räder aufliegen, mindestens genauso interessant, vor allem wenn die Seitenstreifen (Spurrillen) in Summe breiter sind als der Mittelstreifen. Das ist vor allem bei tracktype=grade3 oft der Fall. Man müsste dann entweder nur den seitlichen surface taggen oder oder beide mit Strichpunkt in den Wert vermantschen (z.B. surface=grass;gravel). Weil wahrscheinlich die wenigsten Anwendungen etwas damit anfangen können, lasse ich das in solchen Fällen lieber ganz weg, zumal sich das über die Jahre sowieso ändern kann. Es wächst mit der Zeit immer mehr zu, aber es braucht nur einmal bei Regen der Traktor drüberfahren, und aus grass wird Gatsch.

Adding road surfaces ist ja an sich eine gute Idee, aber wenn du so was machst, dann bitte richtig. Denn falsches surface ist schlechter als gar keins. Wenn tracktype=grade3 ist und/oder der track am Orthofoto weiß ist, kann es nicht surface=grass sein.