[OSM-dev] Updating Planet and Reliability
andy at britishideas.com
Wed Oct 19 13:54:45 BST 2011
On 7/21/2011 9:19 AM, Andy Allan wrote:
> On Thu, Jul 21, 2011 at 9:07 AM, Andrew Ayre <andy at britishideas.com> wrote:
>> Keeping my copy of the planet up to date is a two-step process with
>> Osmosis. Get the latest changes and applying them. This takes about an
>> hour on my server which is enough time for some other user to reboot the
>> server without realizing/knowing.
>> What protection is there in Osmosis to recover from this without missing
>> any changes? If none, how are people solving this in their scripts?
> It depends if you run things as two separate stages or not. I try to
> combine anything involving the updates into one command, so that if
> it's interrupted then the state file hasn't changed and can simply be
> run again.
> So that means doing something along the lines of --rri --simc --rx
> --ac --wx to fetch the changes, simplify, read the planet, apply the
> changes and write it out, all in one go. If you split this into
> multiple osmosis calls, then you'll need to approach it differently -
> perhaps testing whether or not the local changes.osm.gz exists, and if
> it does, skip downloading and go straight to applying it to the
Hello, I am still trying to get this to work properly. Some of the time
I end up with a state.txt that looks like this:
#Sat Oct 15 00:24:20 CEST 2011
The timestamp in the comment is correct. The timestamp on the last line
is not - it's stale.
On the next attempt to update the planet it fails and I end up with a
planet size of zero bytes. I don't know the error message because I
can't get it to always fail. It seems more likely to do this from a
cronjob I think...
I'm using osmosis 0.39.
/tools/osmosis --rri workingDirectory=/data/ --simc --read-bin
/data/planet-current.osm.pbf --buffer bufferCapacity=12000
--apply-change --buffer bufferCapacity=12000 --write-bin
Any ideas what I am doing wrong?
PGP Key ID: 0xDC1B5864
More information about the dev