Sorry, ich versuche das gerade zu verstehen - nicht böse sein, wenn das naiv klingt…
Ich interpretiere mal:
stollen-d ist der Stollen mit kopfstehendem Bergwerkssymbol
stollen ist der Stollen mit aktivem Bergwerkssymbol
stollen2 ist der Stollen ohne Bergwerkssymbol.
Warum die ganzen resource-Values explizit aufführen? Insbesondere, wo coal fehlt?
Warum nicht so etwas wie:
case 'adit':
if (data.resource != NULL) { // oder Leerstring or whatever
if (data['abandoned'] == 'yes' || data['disused'] == 'yes')
return 'stollen-d'
else
return stollen;
} else
return stollen2; // alles ohne resource gibt das leere Stollensymbol, egal ob disused oder nicht
hmm, ich weiß nicht recht. Macht mich jetzt nicht sooo an. Wohl, weil aus dem Symbol nicht sofort ersichtlich ist, wofür das B steht. Symbole sollten sprachunabhängig für sich sprechen (oder zumindest in herkömmlichen Karten gut etabliert sein). Brauchen wir wirklich hier noch ein eigenes Symbol - ich könnte mir vorstellen, ein normales (leeres) Stollensymbol, dazu das Gelände als military getaggt, könnte ausreichen?
Nachher müssen wir noch zwischen militärischen Bunkern (Westwall,…), Regierungsbunkern und reinen Zivilschutzräumen unterscheiden.
Je subtiler die Unterschiede in den Symbolen, desto weniger werden die Unterschiede verstanden. Ein Beispiel: Bei Schlössern/Burgen/Herrenhäusern/Rittergütern etc. ist es meines Erachtens auch ein wenig zuviel des Guten. Die teilweise auch fließenden Übergänge sind nicht immer sehr gut nachzuvollziehen.
Letztlich muß der Kartenersteller entscheiden, ob “bunker” stärker ist oder “adit”. Ich plädiere ohnehin dafür, military als top-level property abzuschaffen (und einiges mehr).
Primär ist Form - sekundär ist Funktion (für die Datenbank). Ein Kartenersteller kann dann immer noch entscheiden, ob er die Funktionstags in den Vordergrund stellen möchte.
Oh sorry, das ist falsch angekommen: ich wollte nur zeigen, dass wir Kombinationen auch mit einem eigenen Icon darstellen können. Das Icon mit dem B ist mit der heißen Nadel gestrickt und natürlich für die Tonne.
Genau. Und ich halte mich aus den Regeln für die Darstellung (der config.js) raus. Das können andere besser.
Das war ein schneller Klick auf die Farbauswahl im xpaint. Es sieht sowieso doof aus, dass der Kringel durch das Symbol durch läuft statt dass das Symbol im Kringel zentriert ist. Die Icons kommen in die Tonne zusammen mit der Regel in der Config. Oder gibts Mülltrennung zwischen Grafiken und Codeschnipseln?
Ich beobachtete, dass sich einige Daten innerhalb eines Tages aktualisierten, aber manche Tags auf benachbarten Kacheln bis heute warteten. Oder sollte es ein Cache Problem sein?
wie schaut es denn mit Tags für Handschwengelpumpen aus? Die werden von vielen Gemeinden liebevoll restauriert und oft auch als techn. Denkmal ausgewiesen. Gibt es da irgendwelche >Vorschläge???
pump:style=modern wurde deswegen auch in unserer wikiseite nicht beschrieben
es besteht aber die gefahr, das plötzlich alle pumpen pump:style=historic werden…
wir natürlich nicht, aber ein bis zwei andere schon
pump:style=modern wird bei gelegenheit rausgenommen,
und für liebhaber von handschwengelpumpen können wir ja eine spezial-karte mit allen pumpen machen…
die geschichtskarten-basis wird zur zeit so umgestellt, das es ohne große mühe möglich ist, 100 erte
spezialkarten (auch regionale) zu erstellen die dann alle immer von den neusten code von wolfgang und seinen assistenten profitieren…
(also bin ich doch nicht alleine – nur wer ist der andere?
Und historisch ist viel mehr, als manche zunächst glauben.)
Die Icons sind schön geworden. Mir persönlich gefallen kleine Symbole besser als große, sofern sie sich durch Farbe und Geometrie von der Umgebung abheben.
Ich wusste gar nicht, wie viele Pumpen es in Berlin gibt. Sind manche davon noch in Betrieb (wenn, dann sicherlich kein Trinkwasser)?