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.
Personally, I don’t find the new method for translations easier.
I have to navigate to a webpage, save it, open it in an editor, start looking for some string that indicates “not yet translated”. update. Save. Create mail message, attach file.
The old way of just opening an editor in the browser was more convenient for me. But maybe I have to get used to the new method.
für uns hat es sich auf jedenfall erleichtert,
nach der alten methode mußte die übersetzung händisch in den kartencode integriert werden!
und wir mußten ständig die übersetzungsseiten überwachen.
dabei ist sicher auch viel untergegangen…
jetzt können wir das text-file nehmen und automatisch daraus die übersetzte karte generieren
hoffe, es hat dir keine allzugroßen umstände gemacht…
Der entscheidende Punkt war, daß alle Karten den gleichen Stand haben sollten. Dazu ist eine automatisierte Generierung mit Hilfe von Übersetzungstabellen wichtig. Dass das vielleicht noch nicht so benutzerfreundlich ist, wie man sich das gerne vorstellt, liegt daran, daß es ein erster Ansatz ist und wir froh sind, daß er so gut funktioniert.
Ich werde im nächsten Schritt hingehen und das ganze Wiki-editierbar machen.