So soll ja die Site-Relation, wie Historic.Place sie anwendet funktionieren.
Das ließe sich sicher machen, um Relationen zu vermeiden.
castle:part=* würde aber das Problem nicht lösen, da es ja nur zeigen würde,
das es sich um eine Vorburg, dem Kerker, der Stallung usw. handelt.
Die eindeutige Zuordnung zur Burg “Schlagmichtod” ist damit nicht gegeben…
Grüße von Lutz
Versteh ich nicht, die castle:part=* Teile sind ja Sub-Flächen einer größeren historic=castle Fläche? So wie bei building:part=*. Die spatiale Berechnung ist den Renderern und Auswertetools allgemein zuzumuten.
Die Kirche wurde zu einem bestimmten Datum entwidmend. Und dadurch verliert es den Status einer Kirche.
Die historic tags können natürlich bleiben. Ich finde, alles richtig getaggt. Ein description tag wäre vielleicht gut, um die Entwidmung zu erklären. Ein disused:building=church könnte man ergänzen. Allerdings sollte man mit dem
Namen noch etwas machen. Das ist jetzt eine Aula!
Da haben wir aneinander vorbeigeredet, ich war gedanklich noch bei den Burgen, Klöstern, Denkmal-Ensebles, für die das Zeichnen einer geschlossenen Fläche nicht geeignet ist…
building:use=* kannte ich nicht, jedoch wird da nicht das Pferd von hinten aufgezäumt?
Zusatztags, nur um building=* keine einheitliche Linie geben zu müssen?
Ja, ich werde den Namen auf old_name ändern.
Da ist jetzt sicher mehr als nur die Aula drinn, wie das Gymnasium das Gebäude jetzt bezeichnet, weiß ich nicht.
Als ich zur Schule ging, war es eine Turnhalle, so ändert sich stetig die Nutzung.
Grüße von Lutz
Nein, building geht vom Typ aus, also vom Aussehen. Die Nutzung ist zweitrangig. Zu building=church heißt es ja genau "A building that was built as a church. "
Wenn dem so wäre, müssten mindestens building=civic, building=hospital, building=commercial, building=dormitory,
building=hotel, building=retail usw. von der Liste.
All diese “Einrichtungen”, können sich in anderen auf der Liste stehenden Gebäude befinden.
Da ist die Mischnutzung noch nicht einmal angedacht…
Und nun kommen wir auf dem Punkt, der Mapper der gerade die Schule mappt, wird sich in der Regel building=school aus den Vorlagen hangeln.
Der Mapper, der die historische Kirche mappt, nimmt building=church.
Grüße von Lutz
Ich und zwei andere Mapper haben historic=castle gemäß den Diskussionen hier überarbeitet: https://wiki.openstreetmap.org/wiki/Tag:historic%3Dcastle
Das entspricht aber nicht der Taggingempfehlung für MPs (Tags sollen an die Relation).
Gefaellt mir sehr gut!
Siehe Diskussion im Thread weiter oben: Das MP bezieht sich auf das blanke Gebaeude, der historic Tag am Outer auf das Gebauede mit Innenhof.
Könnt ihr das auch auf der deutschen Wiki-Site entsprechend umsetzen?
Ich denke, das ist es wert. Wir sind ja schließlich das Land der Burgen. Danke.
P.S. Ich hab z.Z. leider keine Zeit dafür, daher die Anfrage. Wenn es sonst keiner macht, dauert es ein paar Tage.
Ich verstehe die Überlegung dahinter, aber das wäre ein Widerspruch zum Grundsatz “ein Feature, ein OSM-Element”. Genauso wie wenn ein POI sowohl als Node als auch als Fläche eingetragen ist.
Aber hier und dort gibt es auch Burgen …
Wer würde das tagging hier ändern wollen? Hmmm, Funktion, historisch, site ? 
Cepesko
PS: sehe bei Burgen hauptsächlich dann einen Grund für eine Site-Relation, wenn die Anlage nur rudimentär vorhanden und vorwiegend andere Landnutzung sichtbar und dominant ist oder eher Richtung Stadtmauer geht, wie z.B. in Carcasonne. Mietwohnungen in der Burganlage bekämen m.E. auch kein landuse=residential ausgestanzt, ebenso wenig wie ein Kiosk im Wohngebiet ein landuse=retail wäre.
-1, der building tag ändert sich nicht wenn die Kirche nicht mehr benutzt oder gar entweiht wird, der passende tag wäre eher disused:amenity=place_of_worship bei Nichtnutzung und abandoned:amenity=… bei Entweihung
Ich habe mich mal hier (Schloss Hanfelden) versucht:
http://www.openstreetmap.org/edit#map=19/47.25899/14.51130
Was mich ungluecklich stimmt ist, dass auf openstreetmap.org der Name nicht mehr gerendert wird.
Ich finde es immer wieder lustig, wenn bei Diskussionen extreme Ausnahmen, die weit unter einem Prozent der Masse,
bei der es in der Diskussion geht liegen angebracht werden.
So etwas wird geklärt, wenn das Tagging der großen Masse eindeutig ist!
Ich stelle mich jetzt mal hin, und sage, da sich die Burgen in einem Freizeitpark befinden, ist ersichtlich,
das es keine echten Burgen sind 
Danke, habe es noch ein wenig überarbeitet.
In dem Fall kann sicher klassisch herangegangen werden, und es ist kein MP oder Site-Relation nötig:
Grüße von Lutz
Danke fuers Nachbearbeiten! Ich finde das Schloesserl waere ein schoenes Beispiel fuers wiki. Eben weils simpel, aber schon mehr als nur ein einzelnes Gebaeude ist. Deshalb koennte ich mir vorstellen, das Teil als Beispiel in irgend einer Form in das Wiki zu kopieren. Vorher aber noch ein paar Fragen:
o Wieso hast Du die Tuerme auf historic gesetzt, das eigentliche Schloss und die Stallung daneben aber nicht?
o Warum hast Du das Gebaeude von building=castle wieder auf building=yes gesetzt?
Noch eine technische Frage: Wieso hast Du den umschliessenden historic Way neu erzeugt anstatt zu bearbeiten, es hat sich ja zu meiner Version nichts geaendert, ausser das Tagging?
Ich hoffe, Du fuehlst Dich nicht geloechert! Letztendlich moechte ich den Taggingstil auch auf andere Schloesserl uebertragen!
Lg, Gppes
Das ist im Prinzip mappen für den Renderer 
Türme werden in der Regel mit man_made=tower und anderen Subtags gemappt.
Will ich als Auswerter nun die für mich brauchbaren Türme herausfiltern, brauche ich ein eindeutiges key/value, das verhindert,
das ich keine Neubautürme zB. aus Glas und Beton anzeige.
historic=yes ist so ein Basic key/value, das eindeutig, einfach zu gebrauchen und auszuwerten ist.
Und es dürfte auch nicht für andere Auswerter der Datenbank behinderlich sein…
Bei dem eigentlichen Schloss als Gebäude ist das anders, in der Mapping-Praxis werden Schlösser einmal als historic=castle, und einmal als building=castle gemappt, oder beides zusammen.
Deshalb muss ich als Auswerter will ich alle Schlösser anzeigen beide key/values berücksichtigen.
Nun kommt die Krücke, hast du ein Polygon mit historic=castle gezeichnet, wird davon ausgegangen, das alles im Polygon zum Schloss gehört.
Ein zusätzliches building=castle am Gebäude würde zwei Schlösser in der Auswertung produzieren, und größere Schlossanlagen bestehen aus mehreren Gebäuden.
Ein historic=yes am Gebäude selbst ist nicht notwendig, da das Schloss am Polygon ausgewertet wird.
Es existiert kein Königsweg beim Mappen von Burgen, Schlösser, Klosteranlagen, Festungen usw…
Die Frage ist immer betrachtest du zB. die Schlossanlage, oder das Hauptgebäude in dieser als Schloss?
Da existieren bei drei Leuten schon fünf verschiedene Ansichten
Willst du wirklich die Schlossanlage und deren Beziehung zueinander darstellen,
ist meiner Meinung nach die Site-Relation der einfachste Weg.
Das war ein Versehen, ich ging irrtümlich davon aus, das dein Weg Mitglied eines MP ist, und wollte alles vereinfachen.
Hatte das ganze schon nur als Node gemacht, um anschließen doch das Polygon zu favorisieren.
Grüße von Lutz
Auf openstreetmap.org wird immer noch genau nix gezeigt, wenn man historic=castle auf eine Burganlage setzt.
Das ist vermutlich der github issue:
https://github.com/gravitystorm/openstreetmap-carto/issues/744
Also, das juckt mich schon muss ich sagen… 
Hallo,
im Rahmen der Diskussion auf der github Seite habe ich jetzt auch noch mal das deutsche Wiki upgdatet:
https://wiki.openstreetmap.org/wiki/DE:Tag:historic%3Dcastle
Ich habe mir diesen Thread nochmal durchgelesen und versucht etwas detaillierter zusammenzufassen. Den komplexeren Teil der Site-Relation habe ich aber (noch) nicht beruecksichtigt.