Hi,
ich werde aus diesem MP nicht schlau:
Der JOSM Validator ist natürlich auch nicht begeistert von dem Teil. 
Wie verbessern?
Mein Vorschlag: Löschen, statt dessen einfach eine Außenlinie mit den Tags.
Für die einzelnen Inners (derzeit ohne Tags): indoor=room ergänzen?
…so wollte ich es gerade schreiben…
Sven
Ich kenne die Situation vor Ort nicht (Sehe nur das Luftbild als Hintergrund) und bin auch nicht unbedingt der Gebäudeteilmapper, von daher weiss ich nicht wie eine optimale Lösung aussehen würde.
Aber da die einzelnen Gebäudeteile eine teils doch längere History haben würde ich in einem ersten Schritt mal den Änderungssatz rückgängig machen und dann schauen wie es, unter Nutzung der vorhandenen Daten, besser gelöst werden kann.
Ist ja kein Zeitdruck, da kann man den Revert mal machen ohne ihn hochzuladen und sich dann in Ruhe Gedanken machen.
type=multipolygon ist halt auch der falsche Relationstyp. type=site + site=mall scheint mir das Mittel der Wahl um ein Einkaufszentrum “zusammenzufassen”.
Das Gebäude an sich sollte ein Polygon sein, darin dann die Räume mappen, wie von dir geschildert. Dabei dann auch gleich building=* “reparieren”.
site ist für die Zusammenfassung von räumlich auseinanderliegenden Objekten, das ist hier nicht gegeben.
Was mir auf jeden Fall auffällt ist, dass durch das MP die ganzen Adressen verloren gingen und die Änderung allein deswegen schon von rückgängig gemacht werden sollen zusätzlich zum MP-Missbrauch.
Scheint mir irgendwie eine Marotte des Users zu sein, diese site-Sammelrelationen zu erstellen: Relation: Ratiodata Campus (6559047) | OpenStreetMap , Relation: Peras GmbH (14369854) | OpenStreetMap oder Relation: Betriebsrestaurant Christian Habrock (14369853) | OpenStreetMap . Es gibt sogar eine site-Relation, die member einer weiteren site-Relation ist: Relation: 6014313 | OpenStreetMap . Spannend!
Ist mir auch aufgefallen, Adressen, Höhenangaben, Gebäudetyp, …
Hier ein Beispiel für ein vorher:
Ich kenne die Lage vor Ort nicht, ob das eher ein building oder building:part sein sollte, aber zu löschen war das sicher nicht alles.
Die Mall würde ich auch als Umriss (zusätzlich) mappen, und die Relation löschen (aber die tags behalten, bzw. anpassen)
Die Teile sind eher ganze Wohnungen, sind nun als building:part gemappt.
Die anderen MPs des Users habe ich noch nicht geprüft.
Ich glaube, meine Idee war, das Center mit Indoor-Mapping zu taggen? Bin mir da nicht mehr so sicher.
Das Taggen solcher Standorte als type=site hab ich mir tatsächlich bei irgendeinem anderen Firmenstandort abegschaut, aber die genaue Quelle kenne finde ich nicht mehr. Allgemein warnatürlich die Idee, den Zusammenhang nicht nur als Tag, sondern als Relation zu haben, sodass sie nicht inferiert werden müssen, sondern als strukturierte Daten vorliegen. Ist das für OSM der komplett falsche Ansatz? Ich hab’ in all den Jahren wirklich noch nicht viel mit Relationen in OSM gearbeitet 
Ja, das ist dann auf jeden Fall ein dummer Fehler von mir. Sorry!
Wenn ihr gerade dabei seid, es fehlen scheinbar auch noch einige level=* angaben
https://openlevelup.net/?l=0#19/51.983205/7.634361
Unsere Struktur ist auch räumlich, wenn dadurch der Bezug bereits gegeben ist (etwas befindet sich in etwas anderem), dann brauchen wir keine Relation mehr die das nochmal bestätigt. Der räumliche Bezug ist automatisch und “vollständig”, wenn man Relationen wollte müsste man bei allem was man einträgt nochmal außenrum schauen ob es irgendwo eine Relation gibt oder geben sollte wo man es hinzufügt, das funktioniert nicht und solche Relationen sind auf Dauer unvollständiger als der automatische räumliche Bezug der automatisch entsteht und sich “automatisch updated”