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.
If it’s easier for you guys to integrate and to keep track of changes, keep it the way it is now. There aren’t that many tags that have to be translated.
Another thing I noticed was that the Dutch translations had some English translations in it. I translated them into Dutch, but maybe I missed a few more.
Another question, would it be possible to notify me somehow that new translations are expected ? By email, wiki-message or in this thread. I don’t mind which way you prefer.
@escada:
The easiest way to keep track of recent changes is to use the Wiki track changes functionality (white star right from “version history”) of the corresponding wiki page.
Gibt es hierfür schon ein Tag ? Durch diese führen auch Wege - eine verschließbare Einrichtung gibt es aber nicht mehr. Würdet Ihre das in zwei Teile zerlegen oder wie den Durchgang tagggen.
dafür gibt es doch den schönen Tag “barrier=entrance” auf dem gemeinsamen node.
Wenn die Mauer durchgehend ist (Tor-Durchgang) würde ich sie auch durchgehend mappen.
Wenn die Mauer geteilt ist (Mauer-Lücke), dann würde ich sie auch teilen.
habe die heritage=* sachen auf zoom 18 verschoben, wegen der übersichtlichkeit…
site-relationen werden weiterhin ab zoom 16 dargestellt, wenn es einspruch gibt, bitte jetzt melden!
man_made=windmill + disused=yes hätte ich bis heute für eine stillgelegte Mühle benutzt. Es gibt aber eine neue Attributierung nach der es disused:man_made=windmill heißen muss (siehe DE:Key:disused oder die englische Key:disused). Ich denke, dass ist noch nicht sehr bekannt. Damit es sich durchsetzt müsste es mal an prominenter Stelle besprochen werden. Auch das Presets/Historical_Objects sollte angepasst werden, da es ja ein Multiplikator ist.
Immerhin wird es schon benutzt: disused:shop=* 477 mal, disused:man_made=* 78 mal ,disused:amenity=* 1393 mal usw.
Gefällt mir. Hier mal als Beispiel Kolonistenhäuser in der “Alten Kolonie Nowawes” in Babelsberg.
Nur die Eisenbahnsymbole scheinen mir zu zahlreich. Wenn man sie in einer Relation zusammenfasst wird die Stecke nicht mehr markiert.
Wenn man sich http://de.wikipedia.org/wiki/Nowawes anschaut, stellt man fest, daß die Häuser als Ensemble (!) unter Denkmalschutz stehen. Insofern läge hier also ein unsauberes Tagging vor, es sollte eine Relation eingeführt werden statt alle Häuser einzeln zu taggen.