In klassichen Karten wird das Hammer und Schlägel-Symbol allgemein für bergbauliche Einrichtung verwendet - sei das nun ein Schacht (wenn er isoliert ist) oder ein ganzes Bergwerk(-sgelände). Oha - das ist ja schon wieder was anderes (landuse=mine oder landuse=industrial; industry=mining?)
Oftmals liegen einzelne Schächte eines Bergwerks aber viele Kilometer auseinander. Die site-relation ist da schon korrekt. Die Frage (neben einem separaten Symbol, falls man das wirklich will) ist, wie kann man eine site-Relation besser darstellen als durch einen Knoten in ihrem Schwerpunkt? Ich stelle mir da bei so etwas vor (modulo Machbarkeit…):
Wenn die Maus über dem Symbol ist (wäre sehr schick! - oder wenn das Symbol angeklickt ist), werden die Umrisse der Relationsmember farbig hervorgehoben. So ähnlich wie hier: http://www.openstreetmap.org/browse/relation/2721886
Oder reicht es, wenn es über diesen Link zu sehen ist?
Was das Symbol angeht, man könnte natürlich H&S für Mine nehmen und für Schacht ein anderes (z.B. einen stilisierten Förderturm). Das ist aber auch nicht wirklich eindeutiger, es ignoriert Schächte ohne Förderturm und H&S sind bereits gut etabliert. Ich könnte mir so etwas wie ein Fabrikgebäude mit H&S drauf neben/hinter/vor einem Förderturm für “mine” vorstellen?
Ich würde aber “=mine” statt “=mineshaft” für ganze Bergwerke vorschlagen.
Dem könnte man einen teil- statt volltransparenten Hintergrund gönnen, um es hervorzuheben.
Das Highlighten der Site-Bestandteile beim Überfahren des Site-Markers kommt zusammen mit den Linien-Features.
Staubige (und nicht mehr wirlich orange) Grüße
Der Assistent
Ich sehe, daß jetzt einige (alle?) site-Relationen mit größeren Symbolen dargestellt werden (z.B. auch heritage) und auch der Zoomlevel, ab wann sie sichtbar sind, sich geändert hat.
Informationstafeln sind auch a) größer geworden und b) früher sichtbar?
Es gibt noch einen Bug beim Nachladen von Symbolen beim Rein- und Rauszoomen. Er verrechnet sich anscheinend bei dem zu berücksichtigenden Bereich. (bevorzugt lädt er Symbole in die linke obere Ecke).
Hab mal ausprobiert, wie das wirkt: bei der Ofenkaulen sehr gut, bei Heritage ist es grober Unfug.
Vielleicht machen wir es an der Größe der Site fest. Oder wir entfernen es wieder.
Alles “früher sichtbar” gehört zusammen. Es war auf allen Zoomstufen alles sichtbar, weil ich die Gruppeneinteilung vom Lutz ignoriert habe. Die Objekte erscheinen zuerst nach Gruppe und dann nach Quads sortiert, bis ein Limit (zum Schutz von Server und Browser) zuschlägt.
Ist bereits gefixt.
Dass fast alles in der Größe 30x30 dargestellt wird, ist Folge des Aufräumens. Da können aber jetzt ganz einfach wieder andere Größen zugeordnet werden. Sag einfach Bescheid, was am meisten stört.
Sicherlich eine praktische Lösung (auch wenn die Ästethik etwas leidet – bei mittleren Zoomstufen liegen die Icons übereinander …).
Die Änderungen, die auch Mapnik anzeigt, erscheinen auf der Geschichtskarte recht schnell. Details, die nur die Geschichtskarte darstellt, brauchen bei manchen Kacheln 1-2 Tage (?), bei benachbarten Kacheln auch schon einmal mehrere Tage?
Nach welchem Zeitplan wird die Geschichtskarten-Datenbank aktualisiert?
Den Stand der Daten kann man oben rechts bei klick auf “Legende und Info anzeigen” abfragen. Was ich beobachten konnte wurde zumindest in letzter Zeit täglich aktualisiert. Auch wenn Stand der Daten bei 00:00 Uhr angezeigt wird, der Wechsel des Datenbestands geschieht wohl gegen Nachmittag/Abend des Tages ^^
Die Anzeige in dieser Form werde ich zurücknehmen. Über eine brauchbare Anzeige von Sites, deren Komponenten auch angezeigt werden, müssen wir noch nachdenken.
Das ist die Mapnik-Karte.
Das sind keine Kacheln, sondern Marker. Kann man leicht prüfen: mit der rechten Maustaste auf das Icon und die Grafik anzeigen lassen. Nur so kann der Lutz blitzschnell die Gruppen→Zoom-Zuordnung ändern.
Mitternachts ein Schnappschuss, und am frühen Nachmittag die Aktualisierung.
Die Daten (zur Zeit etwas über 300k Objekte) fallen als Abfallprodukt an bei einer anderen Anwendung an, für die völlig irrelevant ist, ob die Daten fünf Minuten, einen Tag oder eine Woche alt sind. Deshalb wird sich da in den nächsten Monaten nichts tun. Wer einen besseren Feed realisiert, darf gerne die Versorgung der Karte übernehmen.
Ja, so in etwa hatte ich mir das vorgestellt. Wenn dann irgendwann Linefeatures gehen, wäre es natürlich noch schön, wenn die tatsächlichen Umrisse von Linien- und die Fläche von Flächenobjekten markiert würden. Mir ist aber schon klar, daß das zwei zusätzliche Schwierigkeitsstufen sind (wenn dann noch MPs hinzukommen, eher drei =;-) )
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.