12

Ähnliche Probleme haben wir vom Prinzip her auch bei unserem Projekt. Wir sind aber eigentlich gut mit der simplen Lösung gefahren, jeder Kachel noch einen Datensaum rings um die eigentlich enthaltenen Daten zu spendieren, also Daten nahe der Kachelgrenze zusätzlich auch noch einmal in der Nachbarkachel abzuspeichern. Diese Option ist für Mapsplit geplant und steht auf der im Wiki verlinkten TODO-Liste unter der vielleicht nicht selbsterklärenden Bezeichnung “border treatment”.

Ich will auch noch mal etwas auf geeignete Anwendungsszenarien eingehen. Wie Peda erklärt hat: Wir verwenden diese Kacheln für “realistisches” 3D-Rendering auf einem Tileserver. Dieser Anwendungsfall hat bestimmte Eigenheiten, deretwegen so etwas wie Mapsplit besonders nützlich ist:

  • Ein Objekt hat in der Regel nur in einem eher kleinen Umkreis Auswirkungen. Eine Baumkrone mag ein Stück in die Nachbarkachel ragen, aber da hilft der angesprochene Datensaum.

  • In einer Kachel werden fast alle Daten für die Darstellung benötigt.

Kurz: Fürs Rendern einer Kachel braucht man die dortigen Daten - und nur diese.

Ich denke, dass gerade bei den detaillierten Zoomstufen unserer gewohnten Kartenstile eigentlich sehr ähnliche Bedingungen vorliegen. Bei Aufgaben mit einer komplett anderen Sicht auf die Daten (wie Routing) halte ich Datenkacheln für ungeeignet, obwohl ich mich gerne überraschen lasse. :wink: