[OSM-dev] problem with osmosis to apply changeset to postgresql db
robot at ijo.me
Mon Dec 19 05:23:17 GMT 2011
Thank you for your explanation.
Before I apply command as below, I have one more question about your statement.
"If you don't need historic versions at all, then you might as well import the 17 December file anew instead of computing and applying an
I'm interesting to update data without any historic version.
Any explation how I can update my database without creating changeset? (And without any downtime)
Did you mean I have to drop the database/tables that consist of the 10 December data then reinsert all data from the 17 December file?
From: Frederik Ramm <frederik at remote.org>
Date: Sun, 18 Dec 2011 22:19:08
To: dev<dev at openstreetmap.org>
Subject: Re: [OSM-dev] problem with osmosis to apply changeset to postgresql
On 12/18/2011 09:23 PM, Oon Arfiandwi wrote:
> osmosis --read-xml-change file="asiadiff.osc" --read-pbf
> file="asia.10des.sorted.osm.pbf" --apply-change --write-apidb
> dbType="postgresql" database="osm" user="osm" password="xxx"
There is a logic problem here.
You have an OSM file O1 (10 December) and an OSM file O2 (17 December).
You compute a change file C so that O1 + C1 = O2.
Your database has O1 loaded.
You wish to update your database to O2.
The only thing your database needs, therefore, is C.
But above, you try and feed O1 *as well as* C into the database.
The correct way to apply file C to your database is
osmosis --read-xml-change asiadiff.osc --write-apidb-change
dbType="postgresql" database="osm" user="osm" password="xxx"
Be aware that an APIDB database records object history, i.e. it can have
old versions of each object, but the approach you are following does not
give you the full history - if an object was at version 1 on 10 December
and at version 5 on 17 December, then after updating your database will
only contain versions 1 and 5, not versions 1,2,3,4,5.
If you need all historic versions then you will have to find another way
to update your database, working from the "replication diffs" that you
can download. I have never done that and cannot say if/how well it works.
If you don't need historic versions at all, then you might as well
import the 17 December file anew instead of computing and applying an
Frederik Ramm ## eMail frederik at remote.org ## N49°00'09" E008°23'33"
dev mailing list
dev at openstreetmap.org
More information about the dev