Re: Rendering der Stolpersteine

wambacher wrote:

Was uns fehlt, ist eine Möglichkeit über einer "neutraleren" Mapnik-Basis-Karte Overlays darzustellen - und zwar vom OSM-Server aus. Dazu müsste man bestimmte Objektklassen aus den Rendering-Rules entfernen und gleichzeitig als WMS-Overlay zur Verfügung stellen.

Sowas wurde z.B. in dieser Karte gemacht. Links ein aufklappbares Menu mit dutzenden einschaltbarer Layer und als Basis eine neutrale auf Osm basierende Karte von Mapquest.
...
Sowas ließe sich - zumindestens für Demo-Zwecke - auf openstreetmap.de realisieren. Da sind wir ja wirklich unser "eigener Herr", oder?

Wir müssen aber sorgsam 3 Arten von Overlays unterscheiden:

- Serverseitig: der Server bietet für alle Overlay-Kombinationen verschiede Tileserver-Resourcen an
- Rasteroverlay:
es wird auf einer Hintergrundkarte (Rasterkarte vom Tileserver)
eine weitere Rasterkarte gelegt, mit Alphakanal (der den Transparenzwert angibt).
Meist sind dafür genau so viele Pixel nötig wie für die Untergrundkarte (Google Earth kann es auch stretchen).
Der Server muss mehere Raster-Layer übermitteln, der Client erreichnet das Overlay.
- Vektoroverlay:
Vom Server werden lediglich Vektordaten übermittelt, sehr datensparsam,
und der Client (Browser/Javascript, JOSM oder Anzeigeprogramm wie GoogleEarth/Marble etc.)
macht das Rendering lokal. Der Server wird also vom Rendering entlastet.

Der Vorteil des serverseitigen Renderns ist der, dass die Objekte besser in das Bild eingebettet werden können,
z.B. der weiße Rand um die Schrift, günstiges Platzieren der Beschriftung (Stolperstein-Schrift neben Straßennamen).
Beim clientseitigen Rasteroverlay hätte man das Platzierungsproblem, da es dann quasi für mehrere
Rasterebenen queroptimiert werden muss.
Das Vektoroverlay hätte auch ein Verdeckungs- und Platzierungsproblem. Ansonsten wäre es
natürlich am flexibelsten. Vektorobjekte könnten auch schön angeklickt werden, um Fotos zu schaun etc.
(wie im Beispiel der Geschichtskarte.

WMS ist immer ein Rasteroverlay, oder?

Da hätten wir dann ein Performance- und Speicherplatzproblem.
Für jede Tile-Layer müsste der Server berechnen und Daten vorhalten.
Gut, falls nur wenige Leute die Geschichtslayer benutzen ist die Last kleiner,
die Caches können kleiner ausfallen.
Aber da OSM nunmal nicht die großen Servercluster hat wie Google, fürchte ich,
das würde die vorhandenen Resourcen überschreiten. Zumal OSM bisher noch kaum
genutzt wird - fast alle die ich kenne schauen nur auf Google Maps.
Wenn OSM beliebter wird könnte die Last extrem zunehmen.
Es sollte nicht unbedingt die Geschwindigkeit beim Zappen durch die Hauptkarte
negativ beeinflussen.

Es hängt auch etwas vom Typ des Overlays ab. POI lassen sich gut
als Vektorlayer einfach drüberzeichnen.
Für das Rendering der Fahrradwege (OpenCycleMap) könnte das
schwieriger werden.