Gruppierung von Burggebäuden?

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.

Das Wiki sagt es doch schon richtig:

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.

bye, Nop

Straße und Straßenschild?

Wenn es kein Schild mit “Weg der Liebenden” gibt, sich nur auf eine Geschichte beruft, würde es in description:de=* gehören.

Es gibt auch Tafeln (Karten) vor Ort, wo Bezeichnungen der Wege eingetragen sind. Dann müssten diese “örtlichen Wege” m.E. loc_name=* erhalten.

Bei name=* gehe ich davon aus, das es “Schild mit dem Namen” gibt.

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.

Grüße aus Oberschwaben

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.

Gruß,
Zecke

Das ist für mich dann eher ein Schild / Tafel:

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? :wink:
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…

Grüße von Lutz

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: :frowning:
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