Richtig.
Die Gebäude hatte ich ja auf 88214 gesetzt, bin dann aber wohl mit Vogelhäusle (88213) durcheinandergekommen.
Grenze ist geändert, wäre auch beim nächsten Lauf der "Fools" aufgefallen.
Danke für den Hinweis.

Das ist eine kürzere Alternative zu start_date=2019-05-02 & opening_date=2019-10-31,
siehe
osm.wiki/Comparison_of_life_cycle_concepts .
Führt offensichtlich dazu, dass die Straße momentan von der Standardkarte gar nicht mehr dargestellt wird :-( .

Stimmen die Adressen östlich der Straße Reihelberg? Dort wären die Hausnummern doppelt.
Anm.: Dort ist bereits die Gemarkung Birkenfeld.

Ich bekenne mich nicht schuldig ;).
Ich habe so weit ich es rekonstruieren kann, die PLZ-Grenze verschoben, um Speidelweg 112 und 114 und Eselweg 20 nach 70184 zu bringen.
User Peilscheibe hat 10 Minuten nach mir die PLZ-Grenze wieder geändert, die vorher verschobene Grenze aus der Relation herausgenommen, die Linie aber nicht gelöscht. Seine Grenze ist näher an der Stadtteilgrenze, stimmt aber leider nicht: Speidelweg 130 und 92 liegen da nicht in 70184. Die beiden Gebäude waren nicht in OSM eingetragen, das habe ich jetzt gemacht.
Ich habe jetzt die verwaiste Grenzlinie auch grob so geändert, dass Nr. 92 drin liegt.
Die Relation habe ich nicht angefasst, um keine Auseinandersetzung zu provozieren.
Ich überlasse es den "Stuttgartern", welchen Grenzverlauf sie für richtig halten.

Ein Teilrevert hätte doch genügt?
Ich habe im Zuge der as_Relations-Aktion auch oft nebenbei offensichtliche Fehler aus der JOSM-Prüfung heraus behoben.
Natürlich kann es da schon vorkommen, dass etwas, was offensichtlich schien, doch nicht so trivial ist.
Das kann man dann ja über CS-Kommentare regeln, dazu sind sie mMn da.

Tippfehler in Wittnau korr.

Ich habe damals die Gemeindegrenzen präzisiert. Dabei habe ich alle Zugehörigkeiten der alten admin-Relationen aktualisiert, so wohl auch zu dieser collection-Relation.
Die habe ich weder erzeugt noch irgend etwas mit ihr tun wollen. Ich habe nur beim Übergang von alten zu neuen Grenzrelationen nichts zerstören wollen, ich bin daher nur letzter Bearbeiter ohne irgend ein Interesse an dieser Realtion..

Unter Ort und Straße Birkhof bin ich endlich bei der DPAG fündig geworden -> 88400 Birkhof (d.h. zu Biberach).
Es gibt aber auch einen Telefonbucheintrag mit 88441 Birkhof (also Mittelbiberach). Das könnte einer der Fälle sein, wo nicht einmal die Bewohner ihre offizielle PLZ kennen (seufz).
Ich habe es mal gewagt, alles (Grenzen und Adressen) auf Biberach zu setzen.

Der vor einiger einigermaßen akzeptierte Konsens in solchen Fällen war, addr:place zu verwenden, wenn *keine* Straße dieses Namens (sicheres Indiz: Straßenschild) vorhanden ist, sondern nur ein Gewann-, Hof- oder Ortsname.
Oft werden allerdings diese Namen irrtümlich an die Straßen gehängt (wie Bahnstock bis vor kurzem).

Ein vollständiger Revert war mMn hier nicht nötig, so etwas hätte ich nur gemacht, wenn die PLZ-Grenze falsch wäre. Das ist hier aber wohl nicht der Fall, es wäre höchstens zu klären, ob nicht die zwei Häuser südlich davon an der L280 auch noch zu PLZ Biberach gehören. Die richtige Zuordnung zu den PLZ-Relationen ist eine kleinere Übung und ist von User Iberges ja woanders auch richtig gemacht worden.

Im Rahmen dieser Aktionen ist aber beim Birkhof (1km SO) einer neuer Fehler erzeugt worden. Er hat die PLZ von Biberach (was vermutlich stimmt, siehe Eichen und Eggelsbach), aber nun addr:city=Ingoldingen. Das passt nicht zusammen. Da müsste vermutlich ebenfalls eine PLZ-Grenze gezogen und addr:city geändert werden. Aber da ich die Adresse nicht finden kann, halte ich mich raus.

Hallo,
bei der Grenzlinie 674385739 (boundary=postal_code) ist was schief gelaufen.
Statt in den PLZ-Relationen zu Biberach und Bad Buchau ist sie in der admin-Relation von Biberach gelandet.
Es kann sein, dass der Weiler Bahnstock wie die Nachbarhäuser Filde postalisch zu Hofen und damit zu Biberach gehört. Ich habe ich darauf verzichtet, die Relationen zu korrigieren, da ich nicht sicher bin, wie die Situation tatsächlich ist.
Auf jeden Fall muss das bereinigt werden, da sich momentan die Gemeinden Biberach und Oggelshausen überschneiden.
An den Gebäuden muss die Adresse noch ergänzt werden, bei Filde habe ich das schon gemacht, da mMn dort die Sache klar ist. An die place=* gehört die PLZ nicht hin.

Über einen ähnlichen Fall (mit dem selben Verursacher) bin ich übrigens südlich von Giengen/Brenz gestolpert: Da sind sich DPAG und Anwohner nicht einig, wo sie hin gehören. Das Verlegen der PLZ-Grenze allein reicht jedenfalls nicht, es müssen dann konsequenterweise auch die Adressen im fraglichen Gebiet angepasst werden (habe ich bereits gemacht, wenn auch mit Vorbehalt - siehe note dort).

Perhaps service=emergency_access is the appropriate tagging of side tunnels since that includes emergency escape to my opinion.

Modern tunnels are mostly accompanied by auxillary tunnels for service and emergency escape. On Madeira there are often "breakout tunnels" at right angle to the outside. There is no established tagging for that and hw=escape is restricted to escape lane, I reverted that.

Of course local investigation and knowledge (survey) has priority, but there is no local ownership of data and especially no right for conservation of wrong tagging.
I appreciate constructive comments in order to get a better mapping - after 12 years of mapping on four continents this is the first time that I encounter comments in such an (in my opinion) agressive manner.

In OSM there is nothing like the "official location of a name", there are only positions of objects like mountain tops, viewpoints etc. It's completely up to the renderer where and if to place names. Only in rare cases with a peculiar shape of an area where the renderer would place the name at a strange position you may set a node as member of the corresponding area relation with role "label".
Sorry, there is a place node "Parque Ecológico do Funchal" with ID 3995319032. at N32.7080612, W16.9069025. You will notice that if you zoom in: the name will occur a second time to the right below.
BTW: You will also see two place nodes "Chao da Lagoa". I will not touch them: They represent an area of unknown extent and since I don't know the area I don't know which one fits better.

When there are nearby place=hamlet or similar nodes with identical names.
place=locality should only be used when no other place=* or no natural=*, tourism=* etc is applicable.
For me it looks like the place=locality nodes on Madeira come from an import without concern whether the object already existed in OSM e.g. Parque Ecológico as area.

What is these?
I will upload smaller change sets to ease communication

Sorry if you understood my comment as criticism. I considered it as constructive comment since I had to do with many thesis during my worklife.

If you aren't able to map correctly with Go Map, you are perhaps using the wrong tool (I'm not using it). There are low-entry-tools like iD which allow correct mapping.
BTW: On of the objectives of a thesis should be to find out appropriate tools for a given (sub)task.

Es stimmt, dass ich die Stadtteilgrenzen mitverschoben habe, den Generalrevert sehe ich aber als "unfreundlichen Akt" an.
Besser wäre eine Mitteilung gewesen, damit ich die AL-Grenzen von den PLZ-Grenzen trennen kann.
Jetzt stimmen nämlich die PLZ-Grenzen wieder nicht.
An den Stadtteilgrenzen steht übrigens immer noch ein FIXME=inaccurate dran. So erhaltenswert sehen sie damit auf den ersten Blick nicht aus.
Ich mache jetzt halt die Arbeit noch einmal, werde aber die PLZ-Grenzen von den AL-Grenzen lösen, wo immer ich darauf stoße.
Auf Spielchen revert vom revert möchte ich mich nicht einlassen.

Fast alles gesagt.
Bei den Fehlern in OSM Fools halten sich PLZ und PLZ-Grenzen in etwa die Waage.
Die ersteren könnten gar nicht erst entstehen, wenn die PLZ nicht eingetragen würde (Redundanzproblem), die zweiten aber könnten ohne diesen Eintrag kaum entdeckt werden.
Beispiel: Gifizenmoos bei Schramberg. Da liegen ein paar Häuser auf Dunninger Gemarkung, können aber nur über Schramberger Gebiet erreicht werden und haben daher dessen PLZ.
Nur bei den addr:country-Einträgen stimme ich teilweise zu. Die trage ich höchsten in Grenznähe ein (z.B. bei Schaffhausen).

Ich kann mich nur erinnern, in Schorndorf Hausnummern ergänzt zu haben, nicht an Eingriffe in Relationen.
Eine site-Relation braucht es für das Berufsschulzentrum jedenfalls nicht, da alles innerhalb einer amenity=school-Fläche liegt.
Übrigens eine kleine Unkorrektheit am Werkstattzentrum: Das südöstliche bulding:part liegt leicht außerhalb der outline-Fläche.
Zusätzlich fällt mir an diesem Schulzentrum auf, dass die Johann-Philipp-Palm-Schule als ein Gebäude erfasst ist. Nach Maps4BW sind das drei Gebäude (natürlich mit Durchgängen) und drei Hausnummern.