Multipolygone sind eine Art, Flächen zu beschreiben. Nicht mehr. Und wirklich nichts besonderes: bei der angezeigten Fläche sind die Löcher bereits abgezogen.
Die Auswahl der Icons ist in dieser Datei konfiguriert. Kein komplexer Algorithmus, sondern besteht nur aus switch und case und return: sollte selbsterklärend sein.
Bei dem Beispiel haben wir man_“made=adit” und “military=bunker”. Die brauchen zwei unterschiedliche Tags, wir zeigen aber nur eines. Welches, das hängt von der Reihenfolge der Abfragen in obiger Datei ab.
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???