Updates mit Osmosis abholen ok, aber wie in PostGIS einspielen?

moenk · 2012-09-10 14:40:43

Moin zusammen,

also legen wir doch gleich mal los:

gdi:~# osmosis/bin/osmosis --rrii workingDirectory=.

Die configuration.txt wird erzeugt uns sieht plausibel aus.
Nun den Status abholen:

gdi:~# wget http://planet.openstreetmap.org/hour-replicate/state.txt -O state.txt

Auch die Datei state.txt kommt und sieht gut aus.

Jetzt das Update zusammenbasteln:

gdi:~# osmosis/bin/osmosis --rri workingDirectory=. --wxc update.osm.gz

Auch sehr schön, OSM-Change-Datei mit ganz viel Modify, auch wohl richtig so.

gdi:~# osmosis/bin/osmosis --read-xml file="update.osm" --write-pgsql user="postgres" database="osm" &

Das klappt dann aber nicht, was soll man dann mit dem Update machen?

LG,

-moenk

SunCobalt · 2012-09-10 14:56:38

moenk wrote:

Moin zusammen,
also legen wir doch gleich mal los:
gdi:~# osmosis/bin/osmosis --rrii workingDirectory=.
Die configuration.txt wird erzeugt uns sieht plausibel aus.
Nun den Status abholen:
gdi:~# wget http://planet.openstreetmap.org/hour-replicate/state.txt -O state.txt
Auch die Datei state.txt kommt und sieht gut aus.
Jetzt das Update zusammenbasteln:
gdi:~# osmosis/bin/osmosis --rri workingDirectory=. --wxc update.osm.gz
Auch sehr schön, OSM-Change-Datei mit ganz viel Modify, auch wohl richtig so.
gdi:~# osmosis/bin/osmosis --read-xml file="update.osm" --write-pgsql user="postgres" database="osm" &
Das klappt dann aber nicht, was soll man dann mit dem Update machen?
LG,
-moenk

müsste es in Deinem letzten Befehl nicht --write-pgsql-change sein?

wambacher · 2012-09-10 18:13:58

SunCobalt wrote:

müsste es in Deinem letzten Befehl nicht --write-pgsql-change sein?

und wie ! simc fehlt noch, nur warum in zwei Schritten?

osmosis/bin/osmosis  --read-replication-interval  --simc --lpc interval=60 --write-pgsql-change user="postgres" database="osm"

lpc "erzählt" ein wenig Statistik, kann auch weg. simc muss sein.

Gruss
walter

p.s. hier mal mein ganzer Script. Der rennt mit cron ganz gut.

#!/bin/bash
#
#set -x
#
cd /home/walter/osm/db/diff
date
PIDFILE=`basename $0`.pid
RUNLOG=`basename $0`.log

OSMOSIS=/opt/install/osmosis-git/package/bin/osmosis

m_info()
{
        echo "[`date +"%Y-%m-%d %H:%M:%S"`] $$ $1"
    echo "[`date +"%Y-%m-%d %H:%M:%S"`] $$ $1" >> "$RUNLOG"
}
getlock()
{
    if [ -s $PIDFILE ]; then
        if [ "$(ps -p `cat $PIDFILE` | wc -l)" -gt 1 ]; then
            return 1 #false
        fi
    fi
    echo $$ >"$PIDFILE"
    return 0 #true
}
freelock()
{
    rm "$PIDFILE"
}
if ! getlock; then
    m_info "pid `cat $PIDFILE` still running"
    exit 3
fi

TSTART=`date "+%s"`
m_info "starting osmosis"

$OSMOSIS  \
        --read-replication-interval  \
        --simc \
        --lpc interval=60 \
        --write-pgsql-change database=osm authFile=authFile.txt

RC=$?
m_info "osmosis done RC=$RC"

m_info "lag is `$OSMOSIS   --read-replication-lag humanReadable=yes workingDirectory=.`"

Vorteil: wenn ein Update läuft, kann cron den trotzdem ein 2. mal starten. der loggt sich dann einfach wieder aus, solange der erste noch nicht fertig ist.

*/1 * * * *     /home/walter/osm/db/diff/update-db >> /home/walter/osm/db/diff/cron.log 2>&1

Last edited by wambacher (2012-09-10 18:25:04)

SunCobalt · 2012-09-10 18:56:17

wambacher wrote:

simc muss sein.

ähm, also ich bin der Meinung, es ist optional. Bissl langsamer, speziell wenn man seltener repliziert und damit die Wahrscheinlickeit steigt, das es mehr als eine Änderung an einem Objekt gibt, was --simc zu einer einzigen Änderung verschmilzt, aber es geht auch ohne

wambacher · 2012-09-10 19:46:35

SunCobalt wrote:

wambacher wrote:
simc muss sein.
ähm, also ich bin der Meinung, es ist optional. Bissl langsamer, speziell wenn man seltener repliziert und damit die Wahrscheinlickeit steigt, das es mehr als eine Änderung an einem Objekt gibt, was --simc zu einer einzigen Änderung verschmilzt, aber es geht auch ohne

sorry, widerspruch:

ohne --simc

walter@wno-server:~/osm/db/diff$ ./update-git
Mo 10. Sep 20:40:53 CEST 2012
[2012-09-10 20:40:53] 6189 starting osmosis
Sep 10, 2012 8:40:53 PM org.openstreetmap.osmosis.core.Osmosis run
Information: Osmosis Version 0.40.1-159-g9107173
Sep 10, 2012 8:40:54 PM org.java.plugin.registry.xml.ManifestParser <init>
Information: got SAX parser factory - org.apache.xerces.jaxp.SAXParserFactoryImpl@633b2b95
Sep 10, 2012 8:40:54 PM org.java.plugin.registry.xml.PluginRegistryImpl configure
Information: configured, stopOnError=false, isValidating=true
Sep 10, 2012 8:40:54 PM org.java.plugin.registry.xml.PluginRegistryImpl register
Information: plug-in and fragment descriptors registered - 1
Sep 10, 2012 8:40:54 PM org.java.plugin.standard.StandardPluginManager activatePlugin
Information: plug-in started - org.openstreetmap.osmosis.core.plugin.Core@0.0.0.41-4-ge47c386
Sep 10, 2012 8:40:54 PM org.openstreetmap.osmosis.core.Osmosis run
Information: Preparing pipeline.
Sep 10, 2012 8:40:54 PM org.openstreetmap.osmosis.core.Osmosis run
Information: Launching pipeline execution.
Sep 10, 2012 8:40:54 PM org.openstreetmap.osmosis.core.Osmosis run
Information: Pipeline executing, waiting for completion.
Sep 10, 2012 8:41:19 PM org.springframework.beans.factory.xml.XmlBeanDefinitionReader loadBeanDefinitions
Information: Loading XML bean definitions from class path resource [org/springframework/jdbc/support/sql-error-codes.xml]
Sep 10, 2012 8:41:19 PM org.springframework.jdbc.support.SQLErrorCodesFactory <init>
Information: SQLErrorCodes loaded: [DB2, Derby, H2, HSQL, Informix, MS-SQL, MySQL, Oracle, PostgreSQL, Sybase]
Sep 10, 2012 8:41:19 PM org.openstreetmap.osmosis.core.pipeline.common.ActiveTaskManager waitForCompletion
Schwerwiegend: Thread for task 1-read-replication-interval failed
org.springframework.dao.DuplicateKeyException: PreparedStatementCallback; SQL [INSERT INTO actions(data_type, action, id) VALUES(?, ?, ?)]; ERROR: duplicate key value violates unique constraint "pk_actions"
  Detail: Key (data_type, id)=(N, 1908829783) already exists.; nested exception is org.postgresql.util.PSQLException: ERROR: duplicate key value violates unique constraint "pk_actions"
  Detail: Key (data_type, id)=(N, 1908829783) already exists.

mit --simc

walter@wno-server:~/osm/db/diff$ ./update-git
Mo 10. Sep 20:43:47 CEST 2012
[2012-09-10 20:43:47] 6259 starting osmosis
Sep 10, 2012 8:43:47 PM org.openstreetmap.osmosis.core.Osmosis run
Information: Osmosis Version 0.40.1-159-g9107173
Sep 10, 2012 8:43:48 PM org.java.plugin.registry.xml.ManifestParser <init>
Information: got SAX parser factory - org.apache.xerces.jaxp.SAXParserFactoryImpl@633b2b95
Sep 10, 2012 8:43:48 PM org.java.plugin.registry.xml.PluginRegistryImpl configure
Information: configured, stopOnError=false, isValidating=true
Sep 10, 2012 8:43:48 PM org.java.plugin.registry.xml.PluginRegistryImpl register
Information: plug-in and fragment descriptors registered - 1
Sep 10, 2012 8:43:48 PM org.java.plugin.standard.StandardPluginManager activatePlugin
Information: plug-in started - org.openstreetmap.osmosis.core.plugin.Core@0.0.0.41-4-ge47c386
Sep 10, 2012 8:43:48 PM org.openstreetmap.osmosis.core.Osmosis run
Information: Preparing pipeline.
Sep 10, 2012 8:43:48 PM org.openstreetmap.osmosis.core.Osmosis run
Information: Launching pipeline execution.
Sep 10, 2012 8:43:48 PM org.openstreetmap.osmosis.core.Osmosis run
Information: Pipeline executing, waiting for completion.
Sep 10, 2012 8:44:49 PM org.openstreetmap.osmosis.core.progress.v0_6.ChangeProgressLogger process
Information: Processing Way 87851280 with action Modify, 173.59759040154427 objects/second.
Sep 10, 2012 8:45:38 PM org.openstreetmap.osmosis.core.progress.v0_6.ChangeProgressLogger complete
Information: Processing completion steps.
Sep 10, 2012 8:45:39 PM org.springframework.jdbc.core.JdbcTemplate extractReturnedResults
Information: Added default SqlReturnResultSet parameter named #result-set-1
Sep 10, 2012 8:45:39 PM org.openstreetmap.osmosis.core.progress.v0_6.ChangeProgressLogger complete
Information: Completion steps took 0.094 seconds.
Sep 10, 2012 8:45:39 PM org.openstreetmap.osmosis.core.progress.v0_6.ChangeProgressLogger complete
Information: Processing complete.
Sep 10, 2012 8:45:39 PM org.openstreetmap.osmosis.core.Osmosis run
Information: Pipeline complete.
-snip-
walter@wno-server:~/osm/db/diff$

so, und nur so klappt es bei mir.

Seit ca 2 Jahren

Gruss
walter

Last edited by wambacher (2012-09-10 19:49:43)

SunCobalt · 2012-09-10 19:57:09

komisch. Hier gings ohne simc. Okay, war nicht alles drin, aber das ist ja ohne Belang für die Replikation....geschrieben wird ja doch alles, was als Change reinkommt.
so:
osmosis --rri workingDirectory=$ROOT_DIR/data/replication --log-progress-change --buffer-change bufferCapacity=6666 --write-pgsql-change authFile=$AUTH_FILE

edit: oh, doch. Einzelne Länder waren auch komplett drin

Last edited by SunCobalt (2012-09-10 20:02:40)

wambacher · 2012-09-10 22:05:06

SunCobalt wrote:

komisch. Hier gings ohne simc. Okay, war nicht alles drin, aber das ist ja ohne Belang für die Replikation....geschrieben wird ja doch alles, was als Change reinkommt.
so:
osmosis --rri workingDirectory=$ROOT_DIR/data/replication --log-progress-change --buffer-change bufferCapacity=6666 --write-pgsql-change authFile=$AUTH_FILE
edit: oh, doch. Einzelne Länder waren auch komplett drin

Das ist ganz einfach mit dem simc. Es hängt, wie bei so vielen Sachen, von genauen Umfeld ab.
Wenn man ein Diff als ein File vom Replication-Server abholt, brauch man natürlich kein simc. Wenn man aber in einem Update-Vorgang mehrere Diffs abholt, müssen vor dem eigentlichen Update der DB die "Doppelgänger" raus. Doppelgänger sind hier Objekte, die mehrfach kurz hintereinander geändert wurden.
Mein configuration.txt sieht so aus:

baseUrl=http://planet.openstreetmap.org/redaction-period/minute-replicate
maxInterval=3600

Damit holt mein Rechner vom Replication-Server die minütlichen Diffs maximal einer Stunde ab (maxInterval=3600 Sekunden), merged die automatisch und schmeisst dann die Doppelgänger raus (dafür das simc).
Somit bekommt der Update seine Daten in akzeptablen Happen (maximal 1h) und später klappt das ohne irgendeine Änderung der Konfiguration auch im minütlichen Abstand.
Konkret bei mir: Morgens Kiste anschmeissen und nach einiger Zeit ist die DB top aktuell. Sollte ich während des Updates mal rebooten müssen, verliert der Update maximal 1H und setzt vollautomatisch neu auf.
Und das ganze ohne Hexerei. Das macht die Replication-Software von Osmosis ganz alleine - wenn man sie freundlich drum bittet.

Die Grafik kennst du ja schon:

Die "Treppenstufen" sind immer die Daten einer Stunde, die er dann in einigen Minuten drin hat. Die nächlichen Daten sind geringer als die täglichen, daher geht es unterschiedlich steil "bergab"

Gruss
walter

Last edited by wambacher (2012-09-10 22:08:49)

SunCobalt · 2012-09-10 22:10:23

also wenn Du maxInterval=3600 von einer Stunde auf 48 Stunden stellen würdest, bräuchtest Du simc auch nicht sofern Du mindestens alle 48 Stunden ein Update machst. Okay, verstanden. Ich hatte mein maxInterval schon immer recht hoch, was erklärt, warum ich nie ein Problem mit simc hatte. Wobei mir simc sehr sinnvoll erscheint.

wambacher · 2012-09-10 22:56:49

SunCobalt wrote:

also wenn Du maxInterval=3600 von einer Stunde auf 48 Stunden stellen würdest, bräuchtest Du simc auch nicht sofern Du mindestens alle 48 Stunden ein Update machst. Okay, verstanden.

Leider nicht
Dir ist eventuell entgangen, dass ich die minütlichen Diffs abhole - bei maxintervall=3600 also theoretisch bis zu 60 - bei 48h also bis zu 2880. Real sind das weniger aber so ca 30 sind es schon. Und sobald beim Download auch nur 2 Files kommen können, muss simc aufräumen. Ist reine Glückssache.

Ich hatte mein maxInterval schon immer recht hoch, was erklärt, warum ich nie ein Problem mit simc hatte. Wobei mir simc sehr sinnvoll erscheint.

Es hängt von den Zusammenspiel der Komponenten und deren Timing zusammen. Wenn du einen Daily Diff verarbeitest und dann in einem zweiten Lauf den nächsten, ist alles "ganz einfach" - ich liebe aber keine einfachen Lösungen
Ich möchte jedenfalls nicht den täglichen Update-Lauf anschmeissen und dann den Rechner die nächsten 6-8 Stunden nicht anfassen dürfen - oder bei einem Stromausfall von vorne anfangen müssen (da war doch was, gell?)

Machen mer's kurz: mit simc geht es immer, ohne simc manchmal nicht.

Gruss
walter

moenk · 2012-09-10 23:14:45

wambacher wrote:

und wie ! simc fehlt noch, nur warum in zwei Schritten?

Walter,

danke für den Hinweis! Und um die Frage zu beantworten: Weil das alles so unsäglich dokumentiert ist. Statt diesem Fall den jeder wissen will findet man alles mögliche im Wiki. Zwei Befehle fürs Setup, einer fürs Update, das ist schon alles! Aber was solls, ich kann ja im Forum fragen ;-)

LG,

-moenk

moenk · 2012-09-12 09:50:27

Moin,

um noch auf mal auf mein tägliches Update zurückzukommen ;-)

In /etc/cron.daily liegt nun eine osmosis.sh und die sieht so aus:

#! /bin/bash
export JAVACMD_OPTIONS=-Xmx8G
cd /home/osm
osmosis/bin/osmosis  --read-replication-interval  --simc --lpc interval=3600 --write-pgsql-change user="postgres" database="osm"

Aber ich denk doch mal der Wert für das Interval müsste höher sein? Was nehmen wir da denn mal?

LG,

-moenk

Announcement

#1 2012-09-10 14:40:43

Updates mit Osmosis abholen ok, aber wie in PostGIS einspielen?

#2 2012-09-10 14:56:38

Re: Updates mit Osmosis abholen ok, aber wie in PostGIS einspielen?

#3 2012-09-10 18:13:58

Re: Updates mit Osmosis abholen ok, aber wie in PostGIS einspielen?

#4 2012-09-10 18:56:17

Re: Updates mit Osmosis abholen ok, aber wie in PostGIS einspielen?

#5 2012-09-10 19:46:35

Re: Updates mit Osmosis abholen ok, aber wie in PostGIS einspielen?

#6 2012-09-10 19:57:09

Re: Updates mit Osmosis abholen ok, aber wie in PostGIS einspielen?

#7 2012-09-10 22:05:06

Re: Updates mit Osmosis abholen ok, aber wie in PostGIS einspielen?

#8 2012-09-10 22:10:23

Re: Updates mit Osmosis abholen ok, aber wie in PostGIS einspielen?

#9 2012-09-10 22:56:49

Re: Updates mit Osmosis abholen ok, aber wie in PostGIS einspielen?

#10 2012-09-10 23:14:45

Re: Updates mit Osmosis abholen ok, aber wie in PostGIS einspielen?

#11 2012-09-12 09:50:27

Re: Updates mit Osmosis abholen ok, aber wie in PostGIS einspielen?

Board footer