On Tue, Sep 07, 2010 at 03:50:36PM +0200, M∡rtin Koppenhoefer wrote:
> Am 7. September 2010 15:23 schrieb Florian Lohoff :
> > 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 RA
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 in
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 me
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 direkte
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 eine
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 grundsae
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 Bl
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 ver
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
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
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 co
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 di
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
13 matches
Mail list logo