On Tue, Sep 07, 2010 at 08:08:31AM +0200, Josias Polchau wrote:
Nein die Suche ist bei Postgres effizient nicht der Speicherplatz.
und genau das brauchen wir für die XAPI
nicht um sonst hat die bisherige XAPI auch eine DB im hintergrund.
Das problem an der alten ist, dass keiner mehr den code
On Tue, Sep 07, 2010 at 08:56:53AM +0200, Bernd Wurst wrote:
Am Dienstag 07 September 2010, 08:08:31 schrieb Josias Polchau:
Ich hatte immer gelernt:
Entweder Schnell oder Platzsparend.
Das gilt da aber nicht. Im kleinen stimmt das meistens.
Wenn aber, wie Flo hier eindrucksvoll gezeigt
hi
Der TRAPI Ansatz klingt sehr gut.
Die Welt wird also zerschnitten in Rechtecke die z.B. 256kByte haben und
nacheinandere
in ein File gespeichert.
Am Anfang des Files muss ein Index sein, der einen direkten Sprung auf
so einen
256kByte Block ermöglicht.
Sollte der Index zu groß sein, dann
Hallo,
Bernhard Zwischenbrugger wrote:
Damit wäre das schwierigste Problem - die bbox Suche erledigt
(theoretisch zumindest).
Wenn der Client immer vorraussehbare Bounding Boxes anfragt, dann
*fast*. Das ist bei ti...@home der Fall. Wenn man grundsaetzlich
beliebige Bounding-Box-Anfragen
Am 07.09.2010 12:07, schrieb Bernhard Zwischenbrugger:
hi
Der TRAPI Ansatz klingt sehr gut.
Die Welt wird also zerschnitten in Rechtecke die z.B. 256kByte haben und
nacheinandere
in ein File gespeichert.
Am Anfang des Files muss ein Index sein, der einen direkten Sprung auf
so einen
256kByte
On 2010-09-07 12:28, Frederik Ramm wrote:
Hallo,
Bernhard Zwischenbrugger wrote:
Damit wäre das schwierigste Problem - die bbox Suche erledigt
(theoretisch zumindest).
Wenn der Client immer vorraussehbare Bounding Boxes anfragt, dann
*fast*. Das ist bei ti...@home der Fall. Wenn man
On 2010-09-07 13:23, Peter Körner wrote:
Am 07.09.2010 12:07, schrieb Bernhard Zwischenbrugger:
hi
Der TRAPI Ansatz klingt sehr gut.
Die Welt wird also zerschnitten in Rechtecke die z.B. 256kByte haben und
nacheinandere
in ein File gespeichert.
Am Anfang des Files muss ein Index sein, der
On Tue, Sep 07, 2010 at 12:07:21PM +0200, Bernhard Zwischenbrugger wrote:
hi
Der TRAPI Ansatz klingt sehr gut.
Die Welt wird also zerschnitten in Rechtecke die z.B. 256kByte haben und
nacheinandere
in ein File gespeichert.
Am Anfang des Files muss ein Index sein, der einen direkten
On Tue, Sep 07, 2010 at 01:23:39PM +0200, Peter Körner wrote:
Du vergisst die minütliche Aktualisierung. Hier muss sowohl der Index
als auch der Datenbestand regelmäßig angepasst werden, was zu löchern
in der Datenstruktur führt.
Rewrite des gesamten blocks - ich schreibe lieber das
On Tue, Sep 07, 2010 at 04:33:35PM +0200, Bernhard Zwischenbrugger wrote:
Warum braucht das überhaupt so viel Arbeitsspeicher beim befüllen?
Wird der Index wärend dem Einspielen gleich erzeugt?
Entweder beim befuellen oder nachtraeglich - schlussendlich wirds halt
richtig schneckig wenn der
On Tue, Sep 07, 2010 at 03:50:36PM +0200, M∡rtin Koppenhoefer wrote:
Am 7. September 2010 15:23 schrieb Florian Lohoff f...@zz.de:
Auf vernuenftiger hardware (16GB Ram, 8 Cores, 500GB Platte in 14 Spindles)
brauche
fuer einen osmosis/postgis import 3 Tage ...
hast Du mal versucht, den
Moin,
On Sun, Sep 05, 2010 at 06:38:12PM +0200, Josias Polchau wrote:
Datenbank:
Ich bin aus eigener Erfahrung für Postgres/Postgis. es ist sehr schnell
auch mit großen Datenmengen
Ganz ehrlich - fuer sowas wie die XAPI ist die postgres zu langsam. Ich
wuerde da eher sowas wie die TRAPI
On Mon, Sep 06, 2010 at 09:13:24PM +0200, Josias Polchau wrote:
Am 06.09.2010 09:37, schrieb Florian Lohoff:
SQL DBs passen nicht wirklich schoen zu den OSM Daten. Das Problem mit der
TRAPI
sind die vielen kleinen files und perl als interpretersprache die nicht
wirklich super fuer die bit
13 matches
Mail list logo
