[OSM-dev] Release candidate for OSM binary format is in osmosis trunk.

Kai Krueger kakrueger at gmail.com
Wed Sep 22 23:25:22 BST 2010

Frederik Ramm wrote:
> Making the excerpts basically occupies a whole big machine for half a day.
> It might be possible to do it on a weekly basis on
> planet.openstreetmap.org (not my call though) but very unlikely to be run
> daily.
Just to be clear, I'd like to say a huge thanks that Geofabrik has been
offering the resources to provide these extracts and I am sure those
resources are quite substantial. (Which is why they are so needed... ;-))

Imho, those extracts and their daily update cycle are one of the most
important things to make OSM data accessible to a more general audience
(i.e. not only companies that can afford 48Gb servers and the likes) and has
enabled many usages that would not have been feasible with only the unwieldy
10 Gb planet files that osmf currently offer. Which is why I was a little
alarmed at the prospect of them potentially "soon being removed" (or better
to say changed in an incompatible way).  Well, perhaps the ones that
Cloudmade still offer are sufficient, but the daily updated ones from
Geofabrik were just so much nicer.

Frederik Ramm wrote:
> What's your use case for .osm.bz2 assuming that osm2pgsql, osmosis, and
> mkgmap support the new format, and that anyone with Osmosis+Java installed
> can produce a .osm file from a .osm.pbf in less time than it takes to
> unpack an .osm.bz2 (and with 20% less data transfer volume)?

I think our toolchain is a little broader than just osm2pgsql, osmosis and
mkgmap by now.

The one I personally happen to know best is Osm2GpsMid. A converter to
create offline vector data for java phones for usage with GpsMid. It is
aimed at non tech-savy users. Even the current process is already often seen
as too much of a hurdle. So either asking people to use a 10gb planet file
or separately download osmosis, pipe everything through that and only then
run osm2gpsmid isn't really an option.

I do eventually, once I have time, intend to implement direct support for
osm.pbf format, as by the sounds of it, it offers some substantial
advantages, but it will take time. Furthermore, all the users then have to
update. With the current version having been downloaded about 20.000 times
that too will probably take some time. 

Similar things presumably apply to all the other consumer facing converters
like the navit one, the one for gosmore, maperative, or any other programs
that people use in order to do things with OSM data.  They all currently
take osm.bz2 country extracts and will first need to be adopted and secondly
then updated versions have to be pushed out the the thousands of users that
already use them today. Some of which might even be in software
repositories. So one can expect that those update cycles are in the range of
6 - 12 month.

So I would just like to see a proper "deprecation process" with ample of
time to adjust and the appropriate wide announcements be followed that were
discussed in respect to the gazetteer retirement to not have the same nasty





View this message in context: http://gis.638310.n2.nabble.com/Release-candidate-for-OSM-binary-format-is-in-osmosis-trunk-tp5499747p5561065.html
Sent from the Developer Discussion mailing list archive at Nabble.com.

More information about the dev mailing list