[OSM-dev] Final kinks in osmosis planet dumping
frederik at remote.org
Mon Sep 10 07:33:38 BST 2007
> **** 1. Different version number.
> Osmosis currently writes the following document element:
> <osm version="0.4" generator="Osmosis">
> This differs from planet.rb which writes:
> <osm version="0.3" generator="OpenStreetMap planet.rb">
That's because the planet file does not have user information which
was introduced in the 0.4 API.
For all *my* purposes, 0.4 is fine, even 0.4 without user information.
> **** 2. Lack of bound elements.
> planet.rb adds this element at the top of the file:
> <bound box="-90,-180,90,180"
> origin="http://www.openstreetmap.org/api/0.4" />
> osmosis doesn't have the ability to generate a <bound> element at the
> top of the file. Can we live without this? It is not a simple problem
> to solve and will require some rework inside osmosis to allow data
> destination tasks to receive bounding box information from data
> generation tasks. Currently the tasks at each end of a pipeline are
> fairly independent.
So difficult to add a fixed "header" on output? I certainly can live
without <bound>; it is used for JOSM etc. to show the downloaded area
(which is *not* identical to the min and max lat/lon in the file!) but
nobody will ever load the planet in JOSM...
> **** 3. Re-ordered attributes.
> osmosis is writing element attributes in a different order to planet.rb.
> planet.rb writes node attributes in the order id, lat, lon, timestamp.
> osmosis writes node attributes in the order id, timestamp, user, lat, lon
There will be regular expression-based parsers that break when you
change the ordering. But that's the price for using regular
> **** 4. Additional indenting whitespace.
> osmosis is currently using 4 space indenting, planetrb is using 2 space
> I can change osmosis to use 2 space indenting if it helps reduce file
> sizes. Should I drop it to 1 space indenting to further reduce file size?
Again, I can imagine some very simple regex parsers choking on this
but they'll have to be fixed anyway.
> **** 5. Inclusion of database password on command line.
> Currently the only way to provide a database password to osmosis is on
> the command line. Presumably this will allow other users on the same
> system to see the password (through the use of ps, top, etc).
> If this is a problem I'll have to update the database tasks to be
> able to read a properties file containing connection information.
I would very much recommend this. Passwords on the command line are
generally frowned upon I think.
> **** 6. Minimum of Java 1.6
> Dev currently has jdk1.5 installed preventing osmosis from running. The
> only code requiring 1.6 is the --bounding-polygon task.
I came across that yesterday when I wanted to run osmosis on a Debian
etch system. I had to downgrade to osmosis 0.11 because Java 1.6
wasn't readily available (although I would probably have been able to
install it using java-package).
> I have two options:
> a. Rework osmosis to only require 1.5 (either by temporarily deleting
> the polygon task, creating a branch without the polygon task, reworking
> the polygon task to use older features, etc).
> b. Upgrade dev to jdk 1.6.
> My preference is obviously b, but I can look into alternatives if that
> isn't feasible or straightforward.
I don't see a reason why we should not upgrade dev to 1.6; then again
the casual user would surely be happy to have a 1.5 compatible
version without the polygon task. I guess there's no magic way to
simply disable the polygon stuff when the user running osmosis has
Frederik Ramm ## eMail frederik at remote.org ## N49°00.09' E008°23.33'
More information about the dev