Hallo Frederik, Frederik Ramm schrieb: > Auch; vorallem jedoch das Fehlen einer inkrementellen/partiellen > Bearbeitung von Objekten durch die API. Wer auch nur eine Bushaltestelle > in seiner Bounding Box hat, muss die ganze Relation herunterladen. Jede > Aenderung an einer Relation erfordert ein vollstaendiges Update. > Jedesmal, wenn Du Deiner Relation eine Bushaltestelle hinzufügst, muss > die ganze Relation mit 2500 Members an den Server hochgeladen, dort > verifiziert und vollstaendig in die History eingetragen werden. Das > kostet Zeit, Bandbreite und Speicherplatz.
Das verstehe ich nicht. Wieso kann eine Relation nicht partiell editiert werden? Ich muss die Gruppe doch nicht auflösen! Es gibt verschiedene Möglichkeit. Nehmen wir an, ich habe die Nodes 123, 135, 212 und 732 in der Relation "test" (relations-id 666). Erste Möglichkeit: Keine Referenz-Datenbank. In der Haupt-Datenbank stehen: node-id | lat | lon | relation | ... 100 | xxx | xxx | 132 | xxx | xxx | "test" 135 | xxx | xxx | "test" 200 | xxx | xxx | 212 | xxx | xxx | "test" 732 | xxx | xxx | "test" Wenn ich nun den Node 135 verschiebe, ist es doch vollkommen egal, ob der in einer Relation ist oder nicht. Es ist doch in der Datenbank nur ein Hinweis, dass Node 135 sich in der Relation "test" befindet. Wenn ich einen neuen Node in eine Relation packe, sagen wir Node 839, wieso wird dieser dann nicht einfach - wie bei Ways auch - hinten in die Relation drangepackt? In der Haupt-Datenbank stehen: node-id | lat | lon | relation | ... 100 | xxx | xxx | 132 | xxx | xxx | "test" 135 | xxx | xxx | "test" 200 | xxx | xxx | 212 | xxx | xxx | "test" 732 | xxx | xxx | "test" 839 | xxx | xxx | "test" Wenn man nun den Node 212 aus der Relation rauslöschen würde: node-id | lat | lon | relation | ... 100 | xxx | xxx | 132 | xxx | xxx | "test" 135 | xxx | xxx | "test" 200 | xxx | xxx | 212 | xxx | xxx | 732 | xxx | xxx | "test" 839 | xxx | xxx | "test" Das ganze könnte natürlich bei unserer riesigen Datenbank Performance-Probleme geben, aber dafür gibt's Clustering. OSM ist kein 200 Leute Projekt mehr, also nicht in kleinen Dimensionen denken. Zweite Möglichkeit: Referenzdatenbank. Vorteil: Die Hauptdatenbank wird nicht immer voll ausgelastet und man kann die Relations-Datenbank auslagern. In der Relations-Datenenbank 666 steht nun: id | node-id 0 | 123 1 | 135 2 | 212 3 | 732 In der Haupt-Datenbank stehen: node-id | lat | lon | ... 132 | xxx | xxx | ... 135 | xxx | xxx | ... 212 | xxx | xxx | ... 732 | xxx | xxx | ... Wenn ich nun den Node 135 verschiebe, ist es genauso wie in der 1. Variante vollkommen egal. Wenn ich den Inhalt der Relation "test" abfrage, sollte die Datenbank lediglich Verknüpfungen (joins) über die REF-ID zu den obigen Nodes aufbauen und mir deren Information herauswerfen. Wenn ich einen neuen Node in eine Relation packe, sagen wir Node 839, wieso wird dieser dann nicht einfach - wie bei Ways auch - hinten in die Relation drangepackt? Die Relations-Datenbank 666 würde dann so aussehen: id | node-id 0 | 123 1 | 135 2 | 212 3 | 732 4 | 839 In der Haupt-Datenbank stehen: node-id | lat | lon | ... 132 | xxx | xxx | ... 135 | xxx | xxx | ... 212 | xxx | xxx | ... 732 | xxx | xxx | ... 839 | xxx | xxx | ... Wenn man nun den Node 212 aus der Relation rauslöschen würde: id | node-id 0 | 123 1 | 135 2 | NULL 3 | 732 4 | 839 Dann hat man nur einen Integer, der halt null rauswirft. Durch geschicktes Datenbank-Handling kann man irgendwann die Verknüpfungen wieder korrigieren. Grüße Tobias _______________________________________________ Talk-de mailing list [email protected] http://lists.openstreetmap.org/listinfo/talk-de
