[OSM-dev] New OSM binary fileformat implementation.

Scott Crosby scrosby06 at gmail.com
Sat May 1 15:47:49 BST 2010

> Initial thoughts from my end (as main developer of Osmosis) is that it
> would be best to keep it separate until you've let it evolve somewhat.  If
> you can develop it as a plugin for now it will let us (ie. Osmosis core, and
> osmosis bin format) remain independent until it matures and stabilises.  If
> it has a wide enough audience (ie. useful to more than a small handful of
> people) then we can look at incorporating it into the core of Osmosis.  At
> that point it will need to meet the current Osmosis code quality checks (eg.
> checkstyle), have unit tests, and pass a code review.  None of that is too
> difficult, but I need to ensure it doesn't add a maintenance burden.
I agree wholeheartedly with letting it evolve and I'm interested in hearing
yours (and others) thoughts on what additional features to include or

> I can possibly help with some ant and ivy advice in terms of how to
> incorporate it with Osmosis.  It should be possible to make the existing
> osmosis library an Ivy dependency of your library.  It might make sense to
> split your library in two parts, the generic re-usable code, and the Osmosis
> specific tasks.  But I'm only speculating until I understand what you've
> done.
Thanks, I'd appreciate that advice. The code is already segregated into
osmosis independent and osmosis dependent packages; the independent code is
already reused in my patches to the mkgmap splitter to read the binary

> Longer term I'm open to suggestions on how Osmosis should incorporate new
> features like this.  It may actually make more sense to pull some existing
> features out of Osmosis and make them plugins also, or it may be simpler to
> just keep adding to the core.  But these questions are more suited to the
> osmosis-dev list.
You've got a nice architecture; it was very easy to figure out how to get my
code to tie-in to your design, at least as a built in. Making it work as a
plugin will be more effort.

My biggest wish is that there should be a common library used by the
different OSM software for representing lowlevel concepts such as points,
bounding boxes, entities, etc, or at least define an baseline interface that
the different OSM software offers for accessing their different entity
implementations. I could target that. mkgmap, osmosis, the splitter, and
josm all have 'Node' and 'Way' defined in semantically identical fashions,
yet are incompatible types. To support all 4 of them requires reimplementing
the binary serializer and deserializer 4 times, quadrupling the chances of
having a bug. Such an interface would make it possible to have a shared
XML-entity parser/writer implementation and make code more reusable across
these applications. For instance, I'm interested in reusing josm's quadtree
implementation in osmosis. I have a local patch that refactors it to support
anything that has a getBBox() and isUsable() functions, but using it
requires importing josm's notion of bounding boxes and coordinates into
osmosis along with refactoring out dependencies on
java.awt.geom.Rectangle2D, and org.openstreetmap.josm.Main (via LatLon).

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/dev/attachments/20100501/bd618dad/attachment.html>

More information about the dev mailing list