[OSM-dev] Compression types in PBF Format

Stefan de Konink stefan at konink.de
Tue Nov 30 20:41:24 GMT 2010

Hash: SHA512


Op 30-11-10 20:49, Frederik Ramm schreef:
> Stefan de Konink wrote:
>> This is the place for the 'too little, too late'. We are beyond the
>> point of 'what' the bitstream should look like: you ought to handle
>> what is defined now.
> This is not how we work in OSM. We don't have standards. 

For some reason we do, this is not a free form fight. And if we can
change the API every week, I wonder why we are still at XML then.

> We can change
> stuff at any time, and indeed I would not hesitate for a second to
> change something in the PBF format if it turns out to repair a design
> problem or bring great benefit. (If it were my call which it isn't.)

The only reason your friend/collegue Jochen started to ask about it is
because he found it difficult to implement 4 ways to encode/decode the
data, which are in principle the same. So what that your tool doesn't
support a specific extension? If that compression is often used, who are
you fooling? Are you suddenly caring about linking -lbz2?

> I really don't like your attitude. It's great that you took the time to
> write pbf2osm but it seems you expect to be revered for it. You give the
> impression of someone for whom coding something is only a means to climb
> onto a platform from where he can heap spite onto others. (I remember
> you derogatory comments about C++ while you wrote pbf2osm, and putting
> comments like "osmosis devs failed to read the specs" in one's code is
> not exactly a sign of maturity either.)

Whats your point? I also wrote the entire API 0.5 (R/W) and XAPI in a C
extention to a webserver. Ab-so-lu-te-ly nobody cares what I (or
probably anyone else) writes here, it was interesting that after 2 weeks
of publication Lennard came up with some detail that everyone who would
have checked the output could have come up with after the first day the
code was published here.

My point is pretty clear, you want the threat PBF as something that is
in flux, I observe that feedback was requested and (virtually) nobody
cared. Protocolbuffers is something that can be extended. If someone
would actually CARE baout removing certain compression techniques he
would benchmark the compressionalgorithms  on the data presented and not
start in a:

"I do care that it seems I am writing code that might never be

...so all code of Jochen should be used now? Get real. So exactly what
Scott suggest: why does nobody step in then, write code that nobody uses
afterwards and present a proper benchmark to show that bzip/gzip/lzma is

>> Then you probably also noticed that it is still a (huge) open question
>> to write a regression testsuite for all parsers and generators. And
>> since the general opinion is now that nobody wants to move until there
>> is a second implementation of osm2pbf (instead of actually switching),
>> everyone is waiting this greatly annoys me and probably not only me
>> but also the guy that actually took great effort to define the
>> protocol and review code of others and answer questions.
> What exactly is your problem? PBF is alive and kicking. I'm using both
> Osmosis PBF support and your implementation of pbf2osm on a daily basis,
> and many downstream users of Geofabrik do the same.

This is my problem:

And the fact that protocol buffers probably would make the API far more

>> I find it totally respectless that *you* are now doubting his
>> qualities but didn't step forward when feedback was asked.
> Excuse me, but discussing potential problems of a design is not a show
> of lack of respect - unless presented in a form like the aforementioned
> "osmosis devs failed to read the specs".

Oh dear, so because I actually feedbacked on Scott and asked questions,
and verified my code and implemented the specs I cannot complain osmosis
didn't? Sounds like we cannot bash IE6 anymore because it did an effort
to implement HTML rendering...

Why does this subject get me so angry? Because the request shows
lazyness and not an effort te show that something is useless because the
compression algorithm are not suited.

Version: GnuPG v2.0.16 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/


More information about the dev mailing list