Weil ich heute über ein nicht richtiges Multipolygon gestoßen bin… hab dazu mal eine Overpass-Abfrage gemacht, um eventuell ähnliche Fälle zu finden. Viel Spaß beim Fixen 
Multipolygon mit Löcher
→ eventuell Fehler wenn auf outer ein building-Tagging ist,
dann werden die Löcher nicht dargestellt.
Gruß Miche
Danke.
FYI, solche Strukturen werden auch von Osmose markiert, siehe:
Art des Multipolygons passt nicht zur Art der Mitglieder
Wie geht man mit mehreren Gebäuden in einer Relation um? Ist das eine Sammelrelation und kann die weg?
Für die drei Gebäude, die ich geprüft habe, gab es auf Osmose keinen Hinweis. Prüft Osmose leicht etwas anderes?
Das sollten nach meinem Verständnis zwei einfache Gebäude sein, ohne Relation.
…die aber beide zum Alexander-von-Humbold-Gymnasium gehören??? …das ist da meine Folgefrage… wenn ja könnte man type=site disskutieren, wenn nein… dann wäre sie für mich obsolet… das kann aber nur einer mit Gebietskenntnisse vielleicht beantworten.
Sven
Ja, aber man packt doch nicht alle Gebäude, welche sich auf dem Gelände einer Schule befinden, in eine Relation 
. Das ist für mich eine Sammelrelation, welche wir ja nicht wollen. Eine Site-Relation halte ich auch nicht für sinnvoll, da man auch ohne diese die Objekte auf dem Gelände der Schule zuordnen kann,
Ich denke, wir sollten alles so einfach wie möglich mappen, damit auch neue Mapper schnell ins Thema finden.
Ja, zwei einzelne Gebäude, Zugehörigkeit zur Schule ergibt sich durch die Lage innerhalb des amenity=school Umrings.
genau, eine site-Relation macht nur Sinn wenn man es mit einem Polygon nicht lösen kann, weil die Sache nicht zusammenhängt und man Nodes oder lineare ways integrieren will.
Evtl. auch für erweiterte Semantik (Rollen), aber dazu gibt es zwar ein paar Vorschläge aber kaum Widerhall in Gemapptem
Außerdem sind jetzt nach aktueller Definition von Multipolygonen die Gebäude im Beispiel doppelt gemappt
Danke für die Rückmeldungen. Ich habe die Relation mit CS 135072149 entfernt.
Ich kann mit Leben… 
Mein Hauptgedanke bezüglich type=site war der Hintergrund, daß z.B. Uni-Gebäude an verschiedenen Orten mittels dieses Relationstyps zusammengefasst werden (können).
Natürlich kann man Sammelrelation dazu sagen… Man kann kann auch “geometric collection” dazu sagen…
Man kann den Begriff “Sammelrelation” eng oder weit auslegen… Unterm Strich sind unsere Haltestellenrelationen bei den ÖPNV-Relationen auch Sammelrelation, wenn man es streng betrachtet…
Sven
Als Anlass für das Löschen habe ich die Doppelung der Daten in der relation und der amenity genommen.
Die Overpass-Abfrage hat mir auch einen Treffer geliefert, wo ich noch nicht so recht weiß, wie ich damit umgehen soll. Hier sind 4 einzelne Gebäude gemappt und als Relation zusammengefügt. Architekturhistorisch ist dies ein Gebäude des Architekten Mies van der Rohe in der Weissenhofsiedlung. Im Moment sind es einfach 4 outer nebeneinander. Die wichtigen (gemeinsamen) Informationen (Architekt, Weissenhofsiedlung, wikidata …) sind jedoch vierfach an den einzelnen Gebäuden. So wie es jetzt ist, erscheint es mir falsch, ich weiß es aber im Moment auch nicht besser zu mappen.
In diesem Zusammenhang gibt es dann auch noch die Relation Weissenhofsiedlung
Eine site-Relation ist hier m.E. völlig angebracht. Aber welche Rolle bekommen die einzelnen Mitglieder? einige haben building, andere buildingpart und weitere keine Rolle.
Mein Hauptgedanke bezüglich type=site war der Hintergrund, daß z.B. Uni-Gebäude an verschiedenen Orten mittels dieses Relationstyps zusammengefasst werden (können).
für Gebäude würde ich nie site verwenden, weil das immer mit multipolygonen geht. Die Frage wäre in diesem Beispiel eher wie man das taggt, weil es da immer noch kein detailliertes Schema gibt
Natürlich kann man Sammelrelation dazu sagen… Man kann kann auch “geometric collection” dazu sagen…
Man kann den Begriff “Sammelrelation” eng oder weit auslegen… Unterm Strich sind unsere Haltestellenrelationen bei den ÖPNV-Relationen auch Sammelrelation, wenn man es streng betrachtet…
Sammelrelationen sind immer dann eine solche, wenn das gleiche auch mit tags ausgedrückt werden kann. Haltestellenrelationen sind eher keine reinen Sammelrelationen, Netzwerkrelationen schon eher, aber die werden wohl als Ausnahme toleriert (?)
In diesem Zusammenhang gibt es dann auch noch die Relation Weissenhofsiedlung
Eine site-Relation ist hier m.E. völlig angebracht.
halte ich nicht für besonders gelungen, einerseits könnte man die jetzigen Members alle mit einem MP mappen, andererseits geht das noch viel einfacher und vollständiger indem man einfach das komplette Gebiet zeichnet anstatt jedes einzelne Haus nochmal in der Relation aufzuführen, wie es jetzt ist. Die Außenanlagen (Gärten) gehören zur Siedlung dazu.
Aber wäre die Aussage dann nicht eine andere, nämlich, dass die beiden Gebäude eigentlich ein und dasselbe Gebäude sind? Oder würdest Du die Gebäude-Tags dann jeweils an den Gebäude-Umrissen lassen und im Multipolygon nur z.B. amenity=university (ja, schlechtes Beispiel) taggen?
Aber wäre die Aussage dann nicht eine andere, nämlich, dass die beiden Gebäude eigentlich ein und dasselbe Gebäude sind? Oder würdest Du die Gebäude-Tags dann jeweils an den Gebäude-Umrissen lassen und im Multipolygon nur z.B.
amenity=university(ja, schlechtes Beispiel) taggen?
genau, die tags sollten jeweils dort hin wo sie gelten, also building tags an das individuelle Gebäude, und an die Relation die tags die für das Gesamtobjekt gelten.
Oh wow, ich habe für solche Fälle bisher immer eine Site genommen, aber das wird halt nicht supported. Danke, das ist tatsächlich die bessere Lösung 
Könnte schon sein, das Osmose eine etwas andere Prüfung macht - hast du mal ein Beispiel dazu parat?