Update planet using Osmosis during redaction period

During the redaction period which started at April 1st only one planet dump has been made available and the usual daily changeset publication has stopped as well.

I would like to keep a local planet up to date using Osmosis and daily changesets but don’t know how to configure Osmosis to use the redaction period changesets.

Anyone have tips how to do this?

Unfortunately only in German language, but here http://forum.openstreetmap.org/viewtopic.php?id=14997 seem to be some questions and answers you are looking for.

Does this help?

This is what I’ve done:


When I run the resulting planet through Splitter (a Mkgmap companion application) the result is only 95 tiles that are incomplete (~1.8 GB) while I expect about 1800 tiles (~30 GB).
Using a planet created by osmupdate the first splitted tile contains: 657.265 nodes, 62.385 ways, 571 relations.
Using the latest official planet the first splitted tile contains 1.292.878 nodes, 120.402 ways, 2.531 relations.

Apparently osmupdate does not create a valid enough planet that Splitter can handle properly.

Therefore I would like to use Osmosis again as I have without problems before the freeze in normal changeset publications on April 1st. So the question is: does anyone know how to use Osmosis in combination with the redaction changesets?

Below is the Splitter command:
java -Xmx3000m -ea -jar ~/garmin/utils/splitter/splitter.jar

Hi Lambertus!

A few days ago another user had problems with the planet “120508”. We found out that his version was corrupted. Please check this file, e.g. via
./osmconvert ~/planet.openstreetmap.org/planet-120508.osm.pbf --out-statistics

Please ensure to have the newest versions of osmconvert and osmupdate.


I downloaded the osmconvert and osmupdate utilities on the 4th of June, those are the latest versions? The 32bit Linux version of Osmupdate/convert are used on 64bit Linux (there is no 64bit version available), this should not cause problems?

The planet 120508 is fine for splitter. I also have the same problem for the 120401 planet which splitter handles normally. Whatever source planet file I’m using, it is the result from osmupdate that does not parse well with Splitter.

But I’ll post the osmconvert statistics later.

Original planet 2012-05-08 (parsed OK by Splitter):

Updated planet 2012-05-08 using osmupdate (parsed incorrectly by Splitter):

Original planet 2012-04-01 (parsed OK by Splitter):

Finally managed to update the latest official planet (2012-05-08) using Osmosis. Resulting planet is smaller (no meta info) that the original. Osmconvert results:

Let’s see what Splitter thinks of it…

The planet updated with Osmosis is processed fine by Splitter. So it seems that osmupdate produces a planet in PBF format that is incompatible with Splitter.

That’s really unfortune.
Did you open a ticket for Splitter? There might be an error in Splitter’s PBF parser…