Gruppierung von Burggebäuden?

Wir mappen offenbar >solche< Dinge nach Aussehen. Da sind wir uns sicher ziemlich einig. Historic besagt ja im Grunde “ehemals” oder “schon sehr lange”, falls die Nutzung noch andauert. Klöster sind ein sehr schönes Beispiel. Die wenigsten Gebäudeesembles, die früher mal Klöster waren, werden noch so genutzt. Oder zumindest nur noch kleine Teile davon. Nicht wenige Klöster (so, wie sie seitens der Orden verstanden werden) sind heutzutage nur noch in Häusern oder gar nur in Wohnungen untergebracht.

Zur Burg:
Ja, ich weiß, das stammt nicht von Dir, zeigt aber, was bei komplexem Mappen letztendlich herauskommt:
Bei Deinem Beispiel “Burg Niedeggen” verstehe ich nicht, warum der “Burghof (ehem. Palas)” - auch wieder ein Musterbeispiel für Beschriftung statt name+alt_name - nicht Teil der Burg sein sollte. Einer der Aussichtspunkte ist Teil der historischen Burg - der andere nicht? Der Brunnen wurde anscheinend auch übersehen (name=Brunnen !?) - der dürfte sicherlich historisch sein. Die in der Site aufgenommene “Dürener Hütte” und das Büro der Bergwacht ist im Gegensatz dazu eher nicht historisch…

Meine Meinung: Es gibt seehr viele Mapper, die nicht so tief einsteigen, daher darf man KISS nicht zu sehr vernachlässigen.

Zufällig war ich letztes Jahr auf der “Burg Nideggen”. Daher sah und sehe ich mich die Tage gezwungen, das sehr vernachlässigte Tagging vor Ort “umzubauen”. Allerdings ist diese Burg sehr schwierig zu taggen. Auf alle Fälle sind die Elemente der Grundburg tlw. Ruine (Palas), tlw. wiederaufgebautes und restauriertes Gemäuer (Donjon) und tlw. recht neue Rekonstruktionen bzw. Neugebäude. Ich kann verstehen, warum wir uns bei so einem Projekt schwertun. Wie soll man bei einem Besuch und den Informationen aus dem Wiki all diese Bauten zu einer “historischen” Burg-Relation rekonstruieren. Außerdem fehlen z.Z. Daten, es gibt Taggingfehler und es werden zu wenig Tagging Elemente genutzt. Ich versuche jetzt, dort einige Elemente zu ergänzen. Aber eine “historische” Site-Relation ist bei diesem Beispiel so gut wie unmöglich, da grundsätzlich nur die Ruinen (ggf. die Wiederaufbauten) und die Umrissmauern (die auch fehlen - barrier=wall , wall=castle_wall) “historisch” sind.

Das war nicht mein Beispiel, und sollte sicherlich nicht die perfekt gemappte Burg zeigen,
sondern lediglich wie eine Site-Relation funktioniert, und darstellbar ist.

Das ist bei allen Themen so, der Mapper der nicht tief einsteigt, fängt mit einem Node historic=castle an.
Später wird daraus ein Polygon, und kann beim Detailmapping wenn nicht anders darstellbar durchaus eine Relation werden…

Egal ob Nahverkehr, Eisenbahn, oder historischen Mapping, spätestens wenn es ins Detail geht,
muss sich intensiv mit dem Thema beschäftigt werden.
Das hat nichts mit kompliziert und dazuerfinden zu tun!
Eine Site-Relation ist genau so einfach/kompliziert wie jede andere Relation bei OSM.

Hier mal ein Beispiel wo ich eine Site-Relation Sinn macht:
Festung Torgau

Grüße von Lutz

Ich denke es ist mittlerweile Konsens das historic=castle nur die Anlage kennzeichnet und keine einzelnen Gebäude oder Gebäuderuinen? Building=castle ist zwar im uralten Building Proposal hat es aber nicht auf die Featureseiten (castle, building) geschafft. In ein paar Kommentaren dazu wurde historic=castle noch als äquivalent angesehen. Mit 1400 Verwendungen wäre es mal wert dokumentiert zu werden. Gibt es einen Grund building=castle nicht zu dokumentieren?

Dadurch vereinfacht sich auch die Kioskfrage: Auch ein Kiosk gehört für mich zur Burganlage und damit zur Fläche von historic=castle. Ob ein Gebäude oder eine Ruine als Teil einer Burganlage historisch ist ergibt sich aus den Tags des einzelnen Features! Also start_date=* und vor allem building=*, …

Als derzeitiger Kurator des Site Proposals dazu noch meine Anmerkungen:

• Festung Torgau habe ich als Beispiel für type=site + historic=* eingetragen.
• Site Relationen haben zzt. keine Chancen in OSM-Carto aufgenommen zu werden
• Was flächig darstellbar ist sollte auch als Fläche/Multipolygon gemappt werden

Wenn ein flächig darstellbare Burg detailliert gemappt werden soll kann man imho auch noch unbeschadet extra eine Site-Relationen erstellen. Für Spezialseiten wie historic.place ist natürlich interessant ob Fläche+Relation gibt, ggf. würde nur die Relation dargestellt werden. Wenn es Fläche+Relation gibt:

• ein site_relation_exists=yes plus area_exists=yes an Relation/Fläche?
• die Fläche/Multipolygon als Member der Site-Relation mit einer speziellen Rolle (z.B. area_represetation)?
• oder Wikidata/(Wikpedia) Tag vergleichen?

Sehe ich auch so, allerding zeigt Mapnik Namen auf “historic=castle” überhaupt nicht an, weshalb Mapper den Namen grundsätzlich auf ein Gebäude setzen (und dann das historic-Tag auch gleich).

Siehe dazu diese Diskussion, die ich gerade gefunden habe.

Mir gefaellt die Auflistung von wolfbert aus Post #11:

Allerdings wuerde ich es wohl so formulieren, weil es inhaltlich gleich ist!?:
a) an das Gebaeude oder den outer-Ring des Gebaeude-Multipolygons, sofern nur ein Gebaeude
b) an das Gelände (wenn mehrere Gebäude, bzw. auch Außenflächen)
c) in eine site-Relation, wenn die Anlage unzusammenhängend und weitläufig ist

Wobei das mit dem Outer-Ring auch nicht erwaehnt werden muesste, weil das ohnehin die Regel bei MPs ist.

??? Standard is mittlerweile an die Multipolygonrelation. Bei OSM-Carto wird schon diskutiert die “old-style multipolygons” mit den Tags an den Outer in mittlerer Zukunft auszuschließen.

Klar! Sorry!!!

Meine Liste:

a) An das Gebäude wenn eine normale Fläche (geschlossene Linie)
b) Als separate Fläche um das Gebäude wenn Gebäude als Multipolygon getaggt (Schlosshof gehört zu historic=castle dazu)
c) An das Gelände wenn mehrere Gebäude, bzw. auch Außenflächen
d) In eine Site-Relation, wenn die Anlage unzusammenhängend und weitläufig ist. Eine Site-Relation kann experimentell auch zu a-c zusätzlich erstellt werden um Detailgrad zu erhöhen

Abgesehen von meinem Denkfehler zuvor:

Ist b) notwendig, wenn das outer im Gebaeude-MP eine einzelne, geschlossene Linie ist? Da koennte man dann ja tatsaechlich den Outer ring taggen und spart einen doppelten Way?

Hier hatte ich einen Denkfehler. Es wäre erlaubt: outer way(s) should be left untagged, unless they describe something in their own right.

-1

Eine Site-Relation sollte wenn dann ausschließlich zusätzlich zu üblichem Tagging erfolgen.

Wenn beim Anlegen einer Site-Relation das übliche Tagging entfernt wird, verschwindet die Burg für alle Auswerter, die wie ich keine Ahnung haben was überhaupt eine Site-Relation sein soll.

bye, Nop

Da habe ich ja etwas losgetreten…

@Nop: Ja, hatte ich in meinem ursprünglichen Versuch übersehen, die Site-Relation gruppiert ja nur.
@Gppes und Jojo4u: Und es wird noch komplizierter, wenn der outer-Ring des Gebäude-Multipolygons mehrere Teile hat…

Das führt uns also zu: historic=castleund die dazugehörigen Tags kommen, sofern flächig gemappt,…

a) wenn nur ein Gebäude: an den Gebäudeumriss
b) wenn mehrere Gebäude, bzw. auch Außenflächen: an den Umriss des Geländes
c) wenn mehrere unzusammenhängende Teile: wie a) oder b), für jedes Teil separat; ergänzend kann eine Site-Relation angelegt werden

Hinweis zu a): für ein Gebäude-Multipolygon kann der Umriss sein:

• der outer-Ring (sofern es sich um EINE Linie handelt) oder
• ein zweites Multipolygon (sofern der outer-Ring aus MEHREREN Teilen besteht) oder
• entsprechend b) ein separates Gelände-(Multi-)Polygon

Ich will da jetzt keine Doktorarbeit daraus machen, aber ich finde es auch sehr erhellend, sich mal bewusst zu machen. wie knifflig das werden kann (ähnliche Situationen kann es mit leisure, amenity etc. ja auch geben).

So würde ich das auch sehen, wobei steht nur noch ein Gebäude bzw. eine Gebäuderuine, sehe ich keinen Grund, es nicht ans Gebäude zu mappen.
Bedenklich finde ich eher building=castle, building=monastery usw., für Key/Values die eine Gesamtanlage beschreiben.

Ja, weil die einzelnen Teile einer Burg unterschiedliche Funktionen und Bezeichnungen haben, wo oft schon andere Key/Values existieren.
building=* wiederspricht sich von vorne bis hinten:

http://wiki.openstreetmap.org/wiki/DE:Key:building

Beispiel

Das Gebäude wurde als Kirche gebaut, und ist jetzt die Aula eines Gymnasiums.
Laut Wiki müßte ich building=church und building=school mappen.
Um Eindeutigkeit beim building=* zu erzeugen, muß sich entschieden werden, ob die Bauform, oder die jetzige Funktion Grundlage für den Einsatz von building=* dienen soll.
Alles andere führt zu Missverständnissen und Fehltagging…

Danke, schön zu sehen, das sich jemand ernsthaft mit dem Thema beschäftigt

Ob es Sinn macht, für unterschiedliche Auswerter doppelt zu mappen, mag ich nicht beurteilen.
Um die Site-Relation zu verstehen, nochmal ein paar Beispiele:

Tiefbunker Dortmund Historic.Place
Tiefbunker Dortmund OSM

Denkmal Ensemble Berlin

Denkmal Ensemble Schweiz

Sicher lassen sich viele dieser Ensembles auch mit

boundary=protected_area darstellen, ob es bei kleineren derselben erwünscht ist, eine Stadt mit hunderten von boundary=protected_area Grenzen zuzumappen wage ich zu bezweifeln…

Vermutlich besteht eine gewisse Abneigung bei Site-Relationen auch darin, das Relationen in der Auswertung teuer sind, und deshalb spärlich verwendet werden sollen.
Wenn dem so ist, dann benennt es Bitte konkret, und so das jeder Mapper es versteht…

Grüße von Lutz

ich würde gerne zu bedenken geben, dass Burgen üblicherweise nach dem Zwiebelprinzip aufgebaut sind: je nach Größe gibt es mehrere Schichten, die es als Angreifer zu überwinden galt, bzw. in die man sich als Verteidiger sukzessiv zurückziehen konnte. Äusserer Mauerring, innerer Ring, Hauptturm, etc., ggf. gab es mehrere äussere Mauern, ggf. waren die Hindernisse auch natürlichen Ursprungs (z.B. steile Felshänge).

M.E. ist das alles Teil der Burg, zu klären wäre ggf. wie man etwaige Vorburgen behandelt.

Heutzutage sind oft nur noch Reste vorhanden, so dass es z.T. evtl. irreführend wäre, die ehemalige Gesamtausdehnung zu taggen (außer man benutzt archeological_site oder versteht den Burgruinen-tag analog), und z.T. ist das ohne Hintergrundwissen auch gar nicht möglich.

Von daher wäre eine Untergruppe der site-Relation für Verteidigungsanlagen durchaus denkbar, da könnte man bei Mauerresten eine Rolle haben die aussagt, zu welcher Schicht sie gehören, auch ohne dass man den ehemaligen Verlauf komplett rekonstruiert

Ich antworte mir mal selbst zu den Vorburgen, wenn es erlaubt ist. Wikipedia hat wie ich entdeckt habe ein eigenes Lemma dazu: https://de.m.wikipedia.org/wiki/Vorburg

Vorburg wird darin als integraler Bestandteil und mit eigenem Mauerring befestigt beschrieben, auch das m.E. ein Argument für besondere Rollen in der Relation, weil mit einem Multipolygon keine Hierarchie ausgedrückt werden kann - oder man macht verschachtelte Relationen mit Relationen als member, z.B. Sammelrelation Burg, mit (einfacher Fall) Vorburg und Kernburg als Member (diese jeweils Polygone oder sites, sofern es verstreute Einzelteile sind).

Wie wäre es mit castle:part=outer_ward/outer_bailey/base_court?

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.

Für mich building=church mit building:use=school