Thema Redundanz bei
description=historische …
historic=yes
Wie sinnvoll findet ihr, in
description=*
prägnante Aussagen über die jeweiligen Objekte zu machen, in der Form:
“historische Winde”, “historische Brücke”, “historisch …” ?
Die Frage ist: ist es redundant, weil wir ja gleichzeitig den tag
historic=yes verwenden, oder bietet es sinnvollen Mehrwert als Kurzinfo für Endanwender?
Wie sinnvoll findet ihr, in
description=*
prägnante Aussagen über die jeweiligen Objekte zu machen, in der Form:
“historische Winde”, “historische Brücke”, “historisch …” ?
das Ziel sollte schon sein, eine maschinenlesbare (eindeutige) Klassifizierung zu entwickeln (oder mehrere haha), ich würde da immer auch in taginfo nachschauen ob es vielleicht schon was gibt, und wenn ich denke dass es Sinn machen könnte verwende ich es. Man kann auch ein Proposal machen um die Sache durchzudiskutieren und so noch bessere Strukturen zu generieren, und vielleicht auch nochmal neu anzufangen 
Es gibt aber auch schon viele tags, man fängt ja nicht bei Null an.
Das liegt doch daran, weil Leute die Dinge gerne auf carto sehen möchten, die sie mappen. Würde carto beide Varianten gleich behandeln, würden wir diese Diskussion nicht führen.
disused=yes ist die ursprüngliche Variante, also die (noch) ältere.
Das Schema disused:*=* wurde später eingeführt (also irgendwann in der Steinzeit um 2013/2014 herum) und hatte eigentlich auch etwas von “es soll auf der Karte nicht mehr erscheinen”, weil disused=yes bei den Renderern auch nicht wirklich genutzt wurde. Gestört hat es halt bei den “funktionalen” Objekten, wie Läden. Wenn Carto damals disused=yes mit einem durchgestrichenen Symbol dargestellt hätte, dann wäre das Prefix-Schema vielleicht gar nicht geboren worden.
Was also bei Läden akzeptiert wird, ist bei “realen” Objekten eben das umgekehrte Problem. Daher wehren sich die Bahnmapper auch gegen das Prefix-Schema (laut Wiki "Disused rail lines have a special method of tagging which is in use: ").
Von daher sind beide Methoden irgendwie “Mappen für den Renderer”.
Beziehungsweise ist es hier bei den Kränen eine ähnliche nicht wirklich lösbare - weil philosophische - OSM-Frage, wie bei den Läden: Meint man den Kran oder die Funktion Kran?
Meiner Meinung nach ist
man_made aber vom Grundsatz her eher “der Kran”. Beim Geschäft (shop) ist es eher die Nutzung.
Das liegt doch daran, weil Leute die Dinge gerne auf carto sehen möchten, die sie mappen. Würde carto beide Varianten gleich behandeln, würden wir diese Diskussion nicht führen.
es geht nicht um Carto sondern darum, dass wenn eine Funktion nicht mehr da ist man einen anderen tag nimmt weil das für alle besser ist, weil die Funktion ja nicht mehr da ist und man so Fehlinterpretationen vermeidet. Das ist aber bei vielen physisch existierenden Dingen anders, die gibt es auch wenn sie nicht benutzt werden, da ist die Frage nach der Benutzung ggf. zweitrangig, und dort verwenden wir das Attribut. Vielleicht gibt es auch Grenzfälle aber eigentlich ist das normalerweise relativ klar welche Variante man verwendet.
Ich habe mich zu unklar ausgedrückt, denke ich.
Maschinenlesbar ist das tagging schon durch historic=yes (und da gibt es noch weitere Möglichkeiten das zu verfeinern, aber das ist nicht mein Punkt)
Mir ging es um die Frage, wie sinnvoll es ist, den Aufwand zu betreiben description=* für das menschliche Gehirn aussagekräftig zu machen.
In unserem Fall würde das heißen, für die Kanalbestandteilen einen kurzen Text zu entwickeln, der dann als Zusatzinfo dient. Wiki sagt
Es kann z. B. dazu verwendet werden, Text für eine Suchfunktion zur Verfügung zu stellen, oder eine ausführlichere Beschreibung für das Element in einem Popup anzuzeigen.
Langatmig z.B.: “historische Winde, Bj 1846, zur Bedienung verstellbarer Stauwehre, ehemaliger Standort im Flußlauf der Altmühl, Ludwig-Donau-Main-Kanal”. Oder auch kurz und knapp: “historische Winde, Ludwig-Donau-Main-Kanal” …
(legt mich nicht auf den Text fest, ist jetzt frei erinnert)
Gibt das Mehrwert? Oder ist es redundant, weil doch nur die maschinenlesbaren Elemente sinnvoll weiter zu verarbeiten sind?
Ich denke, das ist ein ziemlich konstruiertes Argument. Bei einem highway nutzen wir disused:highway=*, weil die Funktion Straße/Weg nicht mehr vorhanden ist, bei einem nicht-funktionierenden Kran aber nicht, weil der Kran noch da ist? Bei einem nicht funktionieren öffentlichen Telefon dann wieder disused:amenity=phone, obwohl das Telefon weiterhin dort steht (wie der Kran auch)? Sorry, das ist einfach nicht schlüssig.
Wenn es beim Tagging angeblich um Funktion und nicht das Objekt geht, dann darf an eine Sitzbank auch kein material oder colour getaggt werden, weil Funktionen kein Material oder Farbe haben.
Ich würde mich eher kurz fassen. Vielleicht ist es besser, in Wikipedia etwas vorhandenes zu nutzen, zu ergänzen oder neue Wikipedia-Seiten anzulegen.
Hier ist z.B. eine Liste aller Schleusen: Liste der Schleusen im Ludwig-Donau-Main-Kanal – Wikipedia
Ich habe mich zu unklar ausgedrückt, denke ich.
Maschinenlesbar ist das tagging schon durch historic=yes (und da gibt es noch weitere Möglichkeiten das zu verfeinern, aber das ist nicht mein Punkt)Mir ging es um die Frage, wie sinnvoll es ist, den Aufwand zu betreiben description=* für das menschliche Gehirn aussagekräftig zu machen.
In unserem Fall würde das heißen, für die Kanalbestandteilen einen kurzen Text zu entwickeln, der dann als Zusatzinfo dient .
kommt drauf an. Bestimmte zusatzinformationen sind vermutlich so speziell dass es keinen Sinn macht dafür einzelne tags zu entwickeln bzw. geht es nur schwierig (z.B. ehemaliger Standort, wobei ein Schema dafür auch an anderer Stelle verwendbar wäre, ist aber eher für die OHM, in OSM wäre es in description schon ok), aber dass es eine historische Winde ist und die 1846 in Betrieb ging, das braucht man nicht in description sondern sollte mit tags gemacht werden.
Ich denke, das ist ein ziemlich konstruiertes Argument. Bei einem
highwaynutzen wirdisused:highway=*, weil die Funktion Straße/Weg nicht mehr vorhanden ist, bei einem nicht-funktionierenden Kran aber nicht, weil der Kran noch da ist?
disused ist nicht für nichtfunktionierende Kräne sondern für nicht genutzte, wenn der Kran nicht mehr funktioniert ist es abandoned
Bei einem nicht funktionieren öffentlichen Telefon dann wieder
disused:amenity=phone, obwohl das Telefon weiterhin dort steht (wie der Kran auch)? Sorry, das ist einfach nicht schlüssig.
wenn du die Telefonzellen als Objekte mappst, z.B. man_made=telephone_booth oder building=telephone oder so, dann bezieht sich der tag auf das physische Objekt und disused=yes wäre passend. amenity=telephone ist ja keine Telephonzelle sondern ein öffentliches Telefon (Dienst), das könnte auch in einem Laden stehen oder sonst ohne Zelle, es stimmt schon, das physische Telefon ist bei amenity=telephone schon dabei, zum Teil mischt sich das, eine Packstation hat einen Typ auch wenn sie disused ist und es da (behaupte ich mal) vorrangig um die Funktion geht.
Na klar. Und ein amenity=bench ist keine Bank, sondern nur die Funktion “Sitzgelegenheit”. Ich kann hier nur noch mit dem Kopf schütteln…
Siehe bitte
Kran an Anlegestelle und Sack zubinden:
Weniger die Fortführung schon lange geführter Diskussionen um grundsätzliche, philosophische OSM-Fragen ist unser Ziel, sondern die (pragmatische) Einigung auf eine Darstellung des Kanals, die den Besonderheiten gerecht wird und möglichst hohe Konsistenz der Daten aufweist. Darum will ich hier wieder sichern, was wir haben.
Die bisher letzte wichtige Diskussion fasse ich so zusammen, dass
man_made=crane
disused=yes
zwar nicht die moderne Lösung ist, aber auch nicht in allen Fällen vom Prefix-Schema erstetzt werden konnte.
Darum ist es teilweise nicht erwünscht, jedoch “zulässig” beim bisherigen tagging zu bleiben. Für beide Ansätze gibt es gute Argumente, ich sehe mich/uns nicht in der Lage eine Variante als eindeutig falsch zu bestimmen.
Für das LDMK-Projekt wäre es ein Nachteil alle Kräne zu disused:man_made=crane zu ändern. Wir würden in eine bisher stabile nicht hinterfragte Praxis, das grundsätzliche und konflikthafte Thema hinein tragen. So würden wir uns nur zusätzliche Hindernisse in den Weg legen und da liegen schon genügend … .
Ich hatte noch überlegt, parallel den Wunsch an osm-carto heranzutragen, dass die Krane (weil touristisch wichtig und so …) auch mit prefix-Schema gerendert werden sollten. Einfach aus Kraftmangel werde ich das vorerst lassen, sonst verliere ich den Fokus in der Fülle der Aufgaben.
Klärungen gab es zur Verwendung von
Wir sind bei diesem Tagging Schema gelandet:
man_made=crane
crane:type=floor-mounted_crane
disused=yes
historic=yes
noname=yes
description=*, Ludwig-Donau-Main-Kanal
engineer=Johann Wilhelm Spaeth
engineer:wikidata=Q1696619
engineer:wikipedia=de:Johann Wilhelm Spaeth
manufacturer=Späth Eisengießerei Nürnberg / Dutzendteich
material=metal
start_date=*
wikidata=*
wikimedia_commons=*
wikipedia=de:*
source=*
Danke an euch alle! HeiKue und ich werden das auf alle Kran-Objekte anwenden. Wenn ich mit dem Abgesang zu früh bin und es doch noch Einsprüche gibt, bitte ich um Nachricht.
Die nächste (wahrscheinlich diffizilere Frage) ist schon in Vorbereitung. Wahrscheinlich machen wir dazu einen anderen Detail-topic auf, damit man auch später beim Nachlesen den Überblick behält.
Macht Freude mit euch!
Viele Grüße HAmap
Wäre ja zu schön gewesen, wenn wir schon durch wären
Bei den beiden Bamberger Kranen habe ich das hier gefunden:
heritage=4
heritage:operator=BLfD
historic=technical_monument
Das tagging sieht nach Vergleich mit dem Wiki für mich gut aus, gestolpert bin ich nur über diesen Absatz:
Erzeuge eine Relation:site und füge type=site hinzu. Außerdem die Eigenschaften heritage=, heritage:operator=, ref:xxx=* und weitere siehe Tabelle. Alle Objekte werden als Member hinzugefügt.
Wir wollen die nicht-wiki-konforme Relationen zurück bauen.
Aber, wie schätzt ihr das ein? Sollten wir für die Krane eine site-Relation verwenden? Oder ist es für 8 Objekte besser das tagging am Objekt selbst zu belassen? (keep it simple)?
Edit: gerade fällt mir noch auf, dass wir prüfen müssen welche der Krane tatsächlich den Denkmalschutzstatus haben. Ich würde mich ja wundern, wenn nicht, aber wer weiß, vielleicht sind nur die in Bamberg besonders schützenswert.
Nur wenn sie in der Denkmalliste als Ensemble aufgeführt werden. Das halte ich aber bei den weit auseinanderliegenden Kranen für unwahrscheinlich.
Es ist eher wahrscheinlich, dass Schleuse, Schleusenwärterhaus und ein eventueller Kran etc. als Ensemble unter Denkmalschutz stehen - das müsste jedoch für jedes einzelne Objekt recherchiert werden, ob Ensemble oder die Objekte jeweils einzeln unter Denkmalschutz stehen.
Du hast einen guten Riecher:
D-4-61-000-30 Am Kranen 1; Am Kranen; Nonnengraben. Kanalhafen Bamberg, Kaimauer aus
Sandstein als Bestandteil des Ludwig-Donau-Main-Kanals, 1836-45; zwei Eisenkräne,
bez. 1864, hergestellt bei I. W. Spaeth, Dutzendteich.
Das ist aus der Bamberger Denkmalliste, die HeiKue auf der Projektseite längst verlinkt hat.
Das würde heißen, in das Kran-tagging kommen die Denkmalmerkmale nicht, sondern in eine site-relation, die dann auch die Kaimauer mit einschließt
Aufpassen, obige sind die 2 vom “Am Kranen”, das sind nicht die vom Nonnengraben!
Hier Nonnengraben:
D-4-61-000-21 Am Kanal; Nonnengraben. Anlände, Bestandteil des Ludwig-Donau-Main-Kanals,
Sandsteineinfassung mit Rampen, 1836-45; zwei Eisenkräne, der eine bez. I. W. Spaeth
Dutzendteich 1846; der zweite von der gleichen Art.
nachqualifiziert
Unter dieser Nummer ist damit auch die Kaimauer mit Rampen.
Die Idee einer Site-Relation hatte ich auch schon, aber noch nicht weiter verfolgt.
Man könnte da alle Objekte in der Relation aufnehmen, nicht nur Krane, sondern auch Kaimauer usw.
Ggf. nicht nur für Denkmalschutz, sondern auch andere gemeinsame Tags z.B. für historic, wiki usw.
Hoppla, darauf wäre ich reingefallen … . Ich merk schon, du hast mehr Überblick im Thema, danke für dein Aufpassen!