Also ich könnte mir vorstellen, dass es schneller wird, wenn man planet einmal mit splitter in z.B. 4 Teile aufteilt und dann diese 4 Teile parallel updated, jeweils mit Angabe der bbox. Zu prüfen ist halt, ob dabei alle Relationen intakt bleiben.
Dann sollte man auch mehrere splitter parallel laufen lassen können. Insgesamt dürfte das auf Maschinen mit vielen Kernen und mehreren Platten/SSD halbwegs gut skalieren, aber I/O bleibt das Problem.
Warum sollte das nicht gehen? Ich kann doch auch ein planet diff auf Germany anwenden und das Ergebnis ist korrekt.
Mein Ansatz war: Wenn ich ein 60gb Planet update um einen Tag bedeutet das:Ich muss weil 100mb anders sind, 60gb auf der Platte schreiben. Anschließend liest splitter die 60gb und schreibt sie erneut auf die Platte. Und die Erfahrung zeigt, der planet wird nicht kleiner 
Aber ist auch nur eine Idee, wie man es anders machen könnte. Lediglich finde ich, dass das aktuelle System zur Kartenerstellung so langsam an seine Grenzen stößt. Wenn es schneller ist, die 60gb per torrent zu laden als 100mb zu laden und lokal upzudaten, sollte man sich gedanken machen, wie man den Prozess beschleunigen kann. Was aber wie gesagt nicht heißt, dass meine Idee das non-plus-ultra ist.
Hallo Henning,
es wird funktionieren, wenn man vom Planet-File mehrere Splits pflegt. Das heißt, einmal gesplittet und dann auf jeden dieser Splits alle Change-Files anwendet und jeweils neu schneidet (mit genau den Bounding-Boxes wie bei der Erstellung dieser Splits). Das was nicht in die jeweilige Box gehört, wird dann wieder verworfen und was nach neuem Stand in die Box gehört (z.B. Relation vom Rand der Nachbar-Box ragt jetzt in die aktuelle Box) kommt zusätzlich hinzu. Wichtig ist, dass alle Nodes schon da sind, wenn ein veränderter Way (aus der Nachbar-Box) diese nach neuem Stand benutzt und dass die Nodes und Ways schon da sind, die eine veränderte Relation nach neuem Stand nun benutzt.
Was ich meine, was nicht funktioniert, ist, diesen Import nach dem Splitvorgang für die Kartenerstellung mit mehreren hundert Tiles anzuwenden. Die Kalkulation der Tilegrenzen beruht auf den aktuellen Daten, während die Changes dann vieles verändern. Die Anzahl der Nodes in den Tiles ändert sich, Nodes die schon da waren gehören zu einem verlängerten Way der nun hineinragt, die Vorausberechnung für “–keep-komplete” war “falsch” usw.
Meinetwegen kann der Splitter die Pflege von Portionen des Planet-File übernehmen, der Splitvorgang für die Tile-Erstellung für mkgmap sollte aber mit den kompletten Daten im Ist-Zustand erfolgen.
Grüße
Mario