Gruppierung von Burggebäuden?

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?

wolfbert wrote:

Site-Relation ist dafür nicht gedacht

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=

Zecke wrote:

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=

Wieso?

Wenn ein Schild steht und der Weg so an den WW ausgewiesen wird ist name=* m.E. richtig.

http://www.traumziel-mv.de/fileadmin/As … 00-513.jpg

Zecke wrote:

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=

besser als Wanderwegsrelation. Dann hat https://hiking.waymarkedtrails.org/#?ma … 891!6.4783 auch was davon.

geri-oc wrote:

Wieso?

Wenn ein Schild steht und der Weg so an den WW ausgewiesen wird ist name=* m.E. richtig.

Es ist ein Wandeweg, also Wanderwegsrelation anlegen... Der Wanderweg hat diese Bezeichnung.

Ach ja, um nicht OT zu werden, von mir +1 für die site-Relation... Gerade wie Zecke es erläutert hat, drängt sich dieser Relationstyp dazu gerade auf.

Sven

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.

Zecke wrote:

hier

Diese Burg beispielsweise ließe sich problemlos mit einem einfachen Polygon darstellen.

+1 für Umriss. Warum kompliziert wenn's auch einfach geht? 🤔

Tordanik wrote:

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:

http://gk.historic.place/historische_ob … e&detail=3

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!

Grüße von Lutz

Danke für Eure Beiträge,

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.

Das Wiki sagt es doch schon richtig:

wolfbert wrote:

• engl. Wiki: historic=castle "on the outline of the construction"
• dt. Wiki: historic=castle "auf den Umriss der Anlage"

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

Zecke wrote:

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.

Straße und Straßenschild?

Ein Gegenbeispiel: "Weg der Liebenden" ist hier tatsächlich als Eigenname gemeint, es bezieht sich auf eine historische Anekdote aus der Geschichte des Landhauses.

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.

geri-oc wrote:

Zecke wrote:

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.

Straße und Straßenschild?

Ein Gegenbeispiel: "Weg der Liebenden" ist hier tatsächlich als Eigenname gemeint, es bezieht sich auf eine historische Anekdote aus der Geschichte des Landhauses.

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

geri-oc wrote:

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

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

PT-53 wrote:

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.

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

PT-53 wrote:

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.

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.

Zecke wrote:

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

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 ...

lutz wrote:

...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!

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.

Klingt sehr theoretisch.

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.

Die "Funktion" als "Burg" wird doch seit Jahrhunderten nicht mehr genutzt - schon gar nicht, wenn sie "nicht mehr geschlossen" ist.

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

lutz wrote:

Wir mappen nur nach Funktion?

pyram wrote:

Nicht ernst gemeint<

lutz wrote:

...Kloster nur wenn darin noch Nonnen leben?...

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.

pyram wrote:

Zur Burg:

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.

pyram wrote:

Zur Burg:.....

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

pyram wrote:

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

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?

Nop wrote:

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.

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:

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

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.

Gppes wrote:

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

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

Jojo4u wrote:

Gppes wrote:

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

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

Jojo4u wrote:

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?

Gppes wrote:

b) Als separate Fläche um das Gebäude wenn Gebäude als Multipolygon getaggt (Schlosshof gehört zu historic=castle dazu)

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.

Gppes wrote:

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

-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=castle`und 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).

Jojo4u wrote:

ch denke es ist mittlerweile Konsens das historic=castle nur die Anlage kennzeichnet und keine einzelnen Gebäude oder Gebäuderuinen?

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.

Jojo4u wrote:

Gibt es einen Grund building=castle nicht zu dokumentieren?

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...

Jojo4u wrote:

- Festung Torgau habe ich als Beispiel für type=site + historic=* eingetragen.

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?

dieterdreist wrote:

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

So soll ja die Site-Relation, wie Historic.Place sie anwendet funktionieren.

Jojo4u wrote:

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

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

lutz wrote:

das es sich um eine Vorburg, dem Kerker, der Stallung usw. handelt.
Die eindeutige Zuordnung zur Burg "Schlagmichtod" ist damit nicht gegeben...

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.

lutz wrote:

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.

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

lutz wrote:

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...

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!

Jojo4u wrote:

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.

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...

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

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?

Rogehm wrote:

Allerdings sollte man mit dem Namen noch etwas machen. Das ist jetzt eine Aula!

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

lutz wrote:

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?

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 … c%3Dcastle

Wiki wrote:

mapped as multipolygon with one outer and inner way(s): add the tag to the outer way.

Das entspricht aber nicht der Taggingempfehlung für MPs (Tags sollen an die Relation).

Jojo4u wrote:

Ich und zwei andere Mapper haben historic=castle gemäß den Diskussionen hier überarbeitet: https://wiki.openstreetmap.org/wiki/Tag … c%3Dcastle

Gefaellt mir sehr gut!

chris66 wrote:

Das entspricht aber nicht der Taggingempfehlung für MPs (Tags sollen an die Relation).

Siehe Diskussion im Thread weiter oben: Das MP bezieht sich auf das blanke Gebaeude, der historic Tag am Outer auf das Gebauede mit Innenhof.

Jojo4u wrote:

Ich und zwei andere Mapper haben historic=castle gemäß den Diskussionen hier überarbeitet

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.

Nop wrote:

-1

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

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.

Rogehm wrote:

.....Wir sind ja schließlich das Land der Burgen...

Aber hier und dort gibt es auch Burgen ....:D
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.

Rogehm wrote:

Ein disused:building=church könnte man ergänzen.

-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=1 … 9/14.51130

Was mich ungluecklich stimmt ist, dass auf openstreetmap.org der Name nicht mehr gerendert wird.

cepesko wrote:

Aber hier und dort gibt es auch Burgen ....:D
Wer würde das tagging hier ändern wollen? Hmmm, Funktion, historisch, site ? roll
Cepesko

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 😎

Gppes wrote:

Ich habe mich mal hier (Schloss Hanfelden) versucht:

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:

http://gk.historic.place/historische_ob … w490010058

Grüße von Lutz

lutz wrote:

Gppes wrote:

Ich habe mich mal hier (Schloss Hanfelden) versucht:

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:

http://gk.historic.place/historische_ob … w490010058

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

Gppes wrote:

Wieso hast Du die Tuerme auf historic gesetzt, das eigentliche Schloss und die Stallung daneben aber nicht?
Warum hast Du das Gebaeude von building=castle wieder auf building=yes gesetzt?

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.

Gppes wrote:

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?

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/openstr … 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: … c%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.