Unerheblich für’s Tagging. Es wird ja nicht als barrier=* getaggt. Zur Unterscheidung von Beton-Panzersperren dient antitank_obstacle=blast_hole.
Geschmacksache. Das Ding ist disused, kann aber jederzeit reaktiviert werden (TNT rein und Bumm!), ist also durchaus noch ein military-Objekt. Ich bin ohnehin ein Gegner der historic=* Schiene. historic=yes/no ist ein Attribut unter vielen, die ein Objekt haben kann (je nachdem ob bedeutsam oder nicht. Hier sicher der Fall, da denkmalgeschützt). Je nach Anwendungszweck einer Karte steht z.B. der militärische oder der historische Aspekt im Vordergrund. Daher würde ich hier nicht einfach historic=irgendwas taggen wollen.
Diese beiden haben kein historic - Tag sollen sie auch nicht bekommen, da diese Ruinen keinerlei historische Relevanz haben. Es ist eine simple, schnöde Gärtnerei-Ruine auf einem verwahrlosten zugewachsenen Grundstück. War sowas nicht schon mal draußen? Danch hatte ich schon mal gefragt.
Ich kann mich nicht erinnern, daß das mal anders war?! Es ist sicher eine Diskussion wert, ob jede Ruine getaggt werden sollte. Hier würde ich aber auf ein Statement von Lutz warten, der kennt die Vorgeschichte besser.
Hast du noch einen Link auf die alte Diskussion zu dem Thema?
ich weiß nicht ob es in diesem ellenlangen Thread schon mal angesprochen wurde, aber wenn mehrere Stolpersteine eng zusammenliegen, kann man wenn man Pech hat nur einen auswählen. Was kann ich tun ohne die Steine auseinanderzuschieben?
“ruins=yes” wurde den “sonstigen historischen Objekten” zugeordnet. Ich hab die Regel provisorisch getilgt, die Ruinen sind aus der Karte verschwunden. Der Lutz wird entscheiden, ob das so bleibt.
Ich könnte auch explizit ein historic=no setzen, und diese werden dann herausgefiltert und nicht angezeigt. Ich hab ja nur drei solcher Kandidaten in meiner Umgebung.
So, ab sofort werden alle Sprachversionen der Karte aus einer gemeinsamen Quelle generiert, mit Übersetzungstabellen. Das wird demnächst noch genauer dokumentiert. Das Anfertigen einer neuen Sprachversion wird damit erheblich einfacher und alle Sprachversionen sind gleich aktuell. (Was noch nicht drin ist, sind Wolfs nagelneue Sammel-Popups, die sind erstmal noch nur deutsch).
man_made=pipe - Ist das wirklich ein Rohr oder nicht eher ein Loch (mehrere)?
antitank_obstacle als main tag? Macht keinen Sinn. Da gehört schon ein military=antitank_obstacle hinzu (oder disused:military für die Freunde der Doppelpunkte).
Vielleicht statt name=Doppelsperranlage eher description=Doppelsperranlage. Vielleicht noch besser “description=Doppelsperranlage aus dem kalten Krieg”, dann hast du das auch drin.
Hallo Wolf, damit wäre ich aber wieder am Ausgangspunkt. Ich wollte ja gerade mal eine Strecke zusammenfassen. Hab es aber trotzdem gemacht, die Symbole sind alle da, die Markierung nicht. Siehe Friedhofsbahn. Die Schwierigkeit hatte ich eher bei einer zB L-förmigen Strecke gesehen, das Symbol nicht in der Landschaft zu platzieren, sondern nahe der Strecke. Gibt es Beispiele für eine Relation mit type=route, route=historic, historic=railway?
2. Bei site-Relationen werden die Elemente nicht angezeigt, wenn man mit der Maus drüber fährt zB hier. Bei älteren geht das noch. kannst du das noch mal prüfen?
3. Bei heritage:operator=whc werden die Grenzen nicht angezeigt. Als die Linien noch neu waren, wurden dicke blaue Rahmen angezeigt. Da es sich teilweise um größere Gebiete handelt, wäre es schön wenn die Füllfarbe der Fläche fast durchsichtig ist oder eben nicht füllen. Vielleicht ist es aber auch bewusst weggelassen worden. Kann man vielleicht noch ändern? zB Volkspark Glienicke
Mit der Spreewaldbahn haben wir sowas gemacht. Ist zwar sicher noch nicht perfekt, aber es funktioniert soweit. An den einzelnen Linienelementen ist dann der Tag railway=abadoned oder razed. Was noch fehlt: start_date und end_date…
Das liegt daran, daß Geheimdienste geheim bleiben sollen!
SCNR
Zecke
PS. Es sieht für mich so aus, als würden member einer Site-Relation, die selbst kein historisches-tag tragen, nicht mehr gelb hinterlegt. Da könnte sich ein Bug eingeschlichen haben (oder ist es Absicht?). Danach muß der Wolf schauen.
Wir haben vor kurzem die Auswahlregeln überarbeitet: Member, die selbst nicht historisch sind, werden nur dann aufgenommen, wenn die Relation verschärften Kriterien genügt, sozusagen “qualifiziert historisch” ist.
Schaut man sich das Tagging der BND-Anlage (ohne die Namen) an, so bleib völlig unklar, was man da vor sich hat. Ebenso geht es den Auswahlregeln. Der Knackpunkt ist das nichtssagende “historic=heritage”.
Möglicherweise wäre ein “historic=barracks” angemessen? Das gibts noch nicht in den Regeln, fügte sich aber zwanglos ein bei “castle|fort|palace”.
Das sind die aktuellen Bedingungen dafür, dass site/collection/route-Relationen ihre nichthistorischen Member in den Datenbestand ziehen:
Ich hab jetzt eingerichtet, dass “heritage=” eine historische Relation dazu qualifiziert, ihre nichthistorischen Mitglieder in den Datenbestand zu ziehen. Die BNDler können also wieder in die Häuser.
Wir stellen nicht mehr alles dar, sondern die Darstellung wird per Konfiguration gesteuert, und die aktuellen Konfigurationsregeln (“styleFromData”, fast am Ende der Datei) fragen nicht heritage ab, sondern physische Attribute. Ich hab mal "leisure="→grün in die config.js aufgenommen, um den Park grün einzurahmen; das wird aber recht sicher wieder getilgt werden.