Am 24.08.2010 09:47, schrieb Ulf Lamping: [...] > > OSM-Datenbank (halbwegs aktuell halten, also wohl planet und hourly > diffs oder so) > Mapnik-Renderer für Style Tests > Garmin Europakarte zumindest täglich rendern >
Willst Du den ganzen Planeten haben? Der ist inzwischen 10+ GB groß, im komprimierten Zustand. Im Moment gibt es noch keine praktikable Lösung eine DB mit einem Ausschnitt aktuell zu halten mit Minuten-, Stunden- oder Tagesdiffs. Da lohnt es sich eher alle X Tage einen neuen Ausschnitt einzuspielen. Für den kompletten Planeten kann man die DB aktuell halten, aber da braucht man gute Hardware. Für Style-Tests würde ich nur einen Ausschnitt der DB nehmen. Da könnte schon ein Bundesland ausreichen. > > Die Frage ist jetzt, ob eine Consumer-Kiste 8GB RAM, 1-2TB Platte, > Quad-Core i5 dafür geeignet ist (also so ganz grob 800 EUR), oder ob es > absehbar sowieso nicht ausreicht. Das wird reichen, allerdings wirst Du wohl nicht täglich die Garminkarte erstellen können. Auf dem OSM-Server wird die Karte auch nur an drei Tagen pro Woche angeboten. Allerdings teilen sich dort mehrere ressourcenhungrige Projekte den Server. > > Aus deiner Mail schließe ich, das 16GB-RAM eine Überlegung wert ist, > also sollte ich wohl besser nicht im ersten 8 GB Schritt alle Bänke mit > Riegeln voll machen ;-) > Jeh mehr RAM desto OSM ;) Wenn alles im RAM ist, muss (fast) nicht mehr auf die Platte zugegriffen werden. Ich würde auch so planen, dass man später vlt. nochmal Riegel nachstecken kann. Allerdings bekommt man mit aktueller Comsumer-Hardware max. 4 Slots. Einige Intel-Boards haben 6 und ansonsten bleiben nur Server-Boards. Dann wirds auch wieder teuerer. Schnelle Festplatten sind das zweite wichtige Kriterium. Ein Raid0 bringt da durchaus Vorteile. Es hilft auch schon wenn man mehrere Festplatten benutzt. Auf einer liegt der Planet, auf der zweiten die Datenbank, auf der dritten die Tiles usw. Egal welchen Prozessor man einbaut, er wird bis zum Maximum ausgenutzt. Zumindest beim Rendering und Erstellen der Garminkarte. Das initiale Bestücken der DB ist eher I/O lastig. Auf dem OSM-Servern lag die Last Seit Januar 2010 im Schnitt bei 3. Wenn man nur mit einem Bundesland arbeiten möchte, reicht ein aktueller Comsumer-Rechner locker. Lars _______________________________________________ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de