Burgen und Schlösser bestehen oft aus mehreren Gebäuden (und anderen Dingen) auf einem größeren Gelände. Was ist der empfohlene Weg, um auszudrücken, dass diese Gebäude zu einem einzigen Komplex (mit eigenen Eigenschaften) gehören?
(Hintergrund: ich arbeite an Multipolygonen, und da ist wichtig, wo genau die Tags sitzen.)
Was ich bisher gefunden habe:
Site-Relation ist dafür nicht gedacht
engl. Wiki: historic=castle “on the outline of the construction” (Gebäude? Mauern?)
dt. Wiki: historic=castle “auf den Umriss der Anlage” (ganzes Gelände?)
in AT oft verwendet: historic=castle auf dem Gebäude (bzw. dem Gebäude-Multipolygon)
Der letzte Ansatz kann in Mapnik dazu führen, dass der Schlossname für jedes Gebäude dargestellt wird (außerdem ist unklar, ob das name-Tag zum Gebäude oder zum Schloss gehört). Mir ist klar, dass man das irgendwie hinbasteln kann, aber gibt es dafür eine “saubere” Lösung (etwa - analog zu amenity=school - das Gelände zu taggen)?
Bevorzugen würde ich ja schon eine Relation ähnlich “site”. Vielleicht sollte man “site” sogar entsprechend erweitern?
Und warum sollte site eigentlich nicht passen? Im Proposal wird doch auf heritage oder historic als Beispiele verwiesen?
Warum nicht (abgesehen davon dass es noch nicht über den Proposal-Status nicht hinausgekommen ist)?
Es als Multipolygon anzulegen mit einem outer-Way für den Umgriff und den Teilen innerhalb als inner-Membern (wie zum Teil z.B. auch bei Sportgeländen usw. praktiziert ) , steht im Widerspruch zur eigentlichen Verwendung von Multipolygonen für Objekte, bei denen die durch die inner-Member umgrenzte Flächen ja gerade nicht zum Objekt gehören.
Wie Du schon schriebst - analog zu Schulen passt doch.
Also historic=castle auf den Umring (der Fläche, dem Gelände) der Burganlage - dann gehört alles darin dazu.
Das schöne ist: Es ist nicht nur möglich sondern wird auch (gerade bei Burgen) recht häufig praktiziert. Da einzelne Teile der Burg oft ohne direkte Verbindung stehen, bietet sich die site-relation an: Alle member mit den jeweiligen Individualtaggings (Mauern, Türme, Brunnen etc.) taggen und als member in die site-Relation aufnehen. Gemeinsame Tags an die Relation, also insbes. historic=castle.
Und weil’s so gut funktioniert, stellt www.historic.place das auch dar. Wie z.B. hier:
Das etwas größere Symbol steht für die Site-Relation und ist auch bei niedrigeren Zoomstufen sichtbar. Die einzlnen member erscheinen erst bei einer höheren Zoomstufe gelb hinterlegt, wenn man mit der Maus über das Castle-Icon hovert.
Kleiner Trick: Wenn man während des Hovern mit der Maus Strg (Ctrl) gedrückt hält, bleiben die member sichtbar und lassen sich einzeln anklicken.
Gruß,
Zecke
Edit: Der “Rundweg um die Burg” ist natürlich ein bestes Negativbeispiel, wie man das name-Tag nicht missbrauchen sollte. Das gehört bestenfalls in description=
Site-Relationen sollte man nur verwenden, wo eine Fläche nicht reicht, das steht an sich auch so im Proposal. Daher: Eine Fläche per geschlossenem Way oder im Bedarfsfall als Multipolygon einzeichnen und als historic=castle taggen.
Ich kann mir zwar vorstellen, dass sich Ausnahmefälle finden lassen, wo eine site-Relation doch mal nützlich ist, aber die Regel ist das sicher nicht.
Diese Burg beispielsweise ließe sich problemlos mit einem einfachen Polygon darstellen.
Natürlich, wenn man an der Datenbank alleine arbeiten würde, und davon ausgegangen werden kann, alles im Polygon gehört zur Burg.
Die Mapping-Praxis sieht oft so aus:
und nicht mehr alle Burgen sind heute noch in sich geschlossen…
Da ist eine Site-Relation geeignet eindeutig die Objekte darzustellen, die wirklich zur Burg gehörten!
wie schon erwähnt, das Proposal zur Site-Relation sagt: “However, this relation is not to be used in cases where the elements are inside one or more areas where the perimeter can be tagged with an appropriate area tag.”
Die Gruppierung mittels Geländepolygon gefällt mir grundsätzlich am besten (analog amenity=school/hospital, one feature - one element), allerdings kann es, wie lutz schrieb, auf dem Gelände auch Dinge geben, die nicht historic sind (also die unmittelbare Kennzeichnung am Gebäude geht verloren). Dem könnte man mit building=castle etc. beikommen.
Für das Tagging wäre also ein Ansatz (historic=castle bezeichnet die gesamte Anlage):
a) an das Gebäude, sofern nur ein Gebäude
b) an den outer-Ring des Gebäude-Multipolygons (also Gesamtgebäudefläche inkl. Innenteile)
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
Beispiele gibt es natürlich für alle möglichen Varianten, immerhin Edinburgh und Windsor entsprechen c).
So sehe ich es auch. Umriss alleine schränkt deutlich ein. Ohne Not.
Und zum “Rundweg”: Auch wenn da ein Schild steht “Rundweg um die Burg” (ich weiß es nicht, nicht meine Ecke), kann ich mir das nicht als den “Namen” im Sinne von Eigennamen vorstellen. Es ist rein deskriptiv.
Ein Gegenbeispiel: “Weg der Liebenden” ist hier tatsächlich als Eigenname gemeint, es bezieht sich auf eine historische Anekdote aus der Geschichte des Landhauses.
Es wird da immer bis zu einem gewissen Grad Interpretationsspielraum geben.
Und ja, es ist die Gesamtfläche der Anlage gemeint.
Mehrfaches Taggen als “castle” erzeugt auch Mehrfachanzeige auf allen Karten und Auswertungen und ist faktisch falsch, es handelt sich nur um eine Burg. Wenn man unbedingt jedes Nebengebäude taggen will, bietet sich building:part=* an.
Noch schlimmer wäre es, zu diesem etablierten, einfachen und sogar im Wiki übereinstimmend beschriebenen Tagging-Schema noch irgendwas komplizierteres dazuerfinden zu wollen. Macht alles schwieriger und sorgt nur dafür, daß die Burg von der Karte verschwindet. Denn ausgewertet wird wie im Wiki beschrieben.
Ich finde name wird viel zu oft falsch verwendet. Wenn z.B. an einem Gebäude ein Schild angebracht ist mit der Überschrift “Brauhaus” oder “Ehemaliges Brauhaus” und weiteren Daten wie Baujahr, Bauherr etc. angegen sind, ist “Brauhaus” für mich kein “Eigenname” im Sinne des Wiki sondern nur eine Funktion / Beschreibung. Diese kann in description abgelegt werden.
Korrekt. Gibt’s aber oder gab es zumindest vor ein paar Jahren (ich war das jetzt nicht kürzlich nachschauen). Da ging das sogar durch die lokale Presse (was im übrigen als Quelle auch reichen würde).
Siehe auch: Weg der Liebenden
Genau. Und man kann es dem Renderer überlassen, ober er eher sparsam mit Bezeichnungen umgehen will, indem er nur echte bewußt vergebene Namen darstellt oder auch eher deskriptive. Oder dies z.B. nur dort, wo es wenig name=* und damit wenig Text auf der Karte gibt…
Wenn aber alles ins name-Tag gepackt wird, damit es auf Teufel komm raus in möglichst vielen Karten erscheint, ist das lupenreines Taggen für den Renderer.
tourism=information
information=board
board_type=history
description:de=weiteren Daten wie Baujahr, Bauherr
name=Ehemaliges Brauhaus
vor/an dem “Brau”-Haus.
Was ist der Unterschied bei “Weg der Liebenden” zu “Rundweg um die Burg” oder “Naturlehrpfad Schwarzbachtal” auf einen Schild?
Dann brauchten wir ja auch die Straßen nicht benamen, sondern setzen es in description:= und der Renderer soll es nutzen.
Der Renderer kann doch entscheiden, ob er in einer Straßenkarte die Wanderwegnamen anzeigt oder in einer Wanderwegkarte die Straßennamen. Wieso muss er alles mit name=* anzeigen?
Gut es gibt immer Meinungsverschiedenheiten - aber solange nichts festgelegt / falsch ist …
Klingt sehr theoretisch. Bei welcher Burg gehört jetzt der Platz/Burghof zwischen den Gebäuden oder der Burggraben nicht zur Burg? Nur mal so, damit ich mir das mal vorstellen kann. Und bekommt eine Burg ein “Loch”, wenn innerhalb der Mauern ein Kiosk errichtet wird, weil der Kiosk kein historischer Bestandteil der Burg ist? Selbst wenn man das so sehen wollte, könnte man das mit einem klassischen Multipolygon abbilden und bräuchte keine Site-Relation.
Nicht ernst gemeint: Bekommt der Kiosk anonsten ein layer=1, weil er >auf< der Burg steht?
Ist eine Burg denn überhaupt noch eine Burg, wenn da jetzt ein Restaurant oder ein Museum drin ist? Die “Funktion” als “Burg” wird doch seit Jahrhunderten nicht mehr genutzt - schon gar nicht, wenn sie “nicht mehr geschlossen” ist.
Nur auf dem ersten Blick, es geht ja nicht nur um Burgen, nimmst du als Beispiel mal ehemalige Rittergüter, Klosteranlagen oder Festungen,
wirst du sehr schnell merken, das du mit Multipolygonen an Grenzen stoßen wirst…
Wenn ich eine alte Burg mappe, ist es schonb wichtig, was ist noch wirklich von der Burg vorhanden, sprich was ist historisch, und was nicht!
Ein neugebautes Restaurant auf einem Burggelände zählt sicher nicht dazu.
Wir mappen nur nach Funktion?
Dann dürften auch die meisten Schlösser nicht gemappt werden, Kloster nur wenn darin noch Nonnen leben?
Ich bin immer wieder erstaunt, das ein 2m Grünstreifen zwischen Straße und Fußweg einen höheren Stellenwert bei OSM hat, als historische Informationen, die im übrigen untrennbar mit Tourismus und Wanderwegen verbunden sind…
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.