[OSM-dev] Final kinks in osmosis planet dumping

Frederik Ramm 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
expressions ;-) 

> **** 4. Additional indenting whitespace.
> osmosis is currently using 4 space indenting, planetrb is using 2 space 
> indenting.
> 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). 

Yes, definitely.

> 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
only 1.5?


Frederik Ramm  ##  eMail frederik at remote.org  ##  N49°00.09' E008°23.33'

More information about the dev mailing list