[OSM-Devserver] Cronjob OLM Update

Alexander Matheisen AlexanderMatheisen at ish.de
Di Apr 12 15:17:58 CEST 2011


Am Dienstag, den 12.04.2011, 07:07 +0000 schrieb Sven Geggus:
> Alexander Matheisen <AlexanderMatheisen at ish.de> wrote:
> 
> > Andere Sache: Könnte man nicht bei der hstore die Centroids schon beim
> > Import berechnen?
> 
> Klar, wenn jemand einen passenden patch für osm2pgsql baut. Peter hatte da
> wohl mal was gemacht.
> 
> > Das würde schon einmal einen Geschwindigkeitsschub bringen. Und wie sieht
> > es aus mit Nodes ohne Tags? Die dürften einen großen Teil der Nodes
> > ausmachen und werden für POI-Karten nicht benötigt.
> 
> Sind die wirklich in der DB drin?

Ich habe nachgeschaut, sind nicht drin. Hätte ja sein können...

> > Hmm, dann müsste ich mein Updatescript umbauen. Wie mache ich das dann?
> > Kann man da einfach eine Abfrage SELECT drüberlaufen lassen?
> 
> Würde ich genau so machen.
> 
> > Wahrscheinlich eher nicht... Dann muss ich immer auf die Diffs zugreifen
> > können, da muss ich dann aber wissen, wie und wo die liegen.
> 
> Das bringt Dir ja nichts, dann müsste ja der Import doch wieder synchron zu
> Deinem update laufen.

Jedesmal die Tabelle ganz neu erzeugen? Das dauert ziemlich lang... Bei
meinem jetzigen Script dauert der Teil, der das Diff auf die Tabelle
anwendet, vielleicht 10 Minuten. Die Tabelle neu erzeugen mit einem
anderen Script dauerte mehrere Stunden, etwa 5.
Kann man nicht die Diffs "an mich weiterleiten"? Jedesmal wenn die Diffs
für ein Zeitintervall runtergeladen werden, werden die auch in ein
Verzeichnis von mir kopiert und am Ende der Woche läuft mein Script
durch die Diffs durch und wendet sie auf meine Tabelle an.

Also konkret:
osmosis --rri bla --wxc diff.osc
osm2pgsql (...) diff.osc
cp diff.osc olmverzeichnis/<timestamp>.osc


Ist ähnlich wie mein Vorschlag zuletzt, nun könnte man das auch besser
bei mehreren Projekten machen. Beispiel: OLM, Postkarte, Hausbräu. Jede
Karte kriegt die Diffs in ein Verzeichnis kopiert ab, Montags arbeitet
OLM die Diffs ab und wendet sie auf die Spezialtabelle an, Dienstags
Postkarte, Mittwochs Hausbräu.

Also ich weiß nicht, was noch dagegen spricht. Last und Laufzeit ist
wegen der Diffupdates gering, eine Zentrale Datenbank für POI-Details
und Spezialtabellen für die einzelnen Projekte, die in der Regel bei den
meisten Projekten eine geringe Größe haben sollten.


Alex