-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi,
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 used." ...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 useless? >> 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: <http://planet.openstreetmap.org/> And the fact that protocol buffers probably would make the API far more efficient. >> 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. Stefan -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEAREKAAYFAkz1YXQACgkQYH1+F2Rqwn2+UwCglRWja5rs5jYs4iFp9C/PgJuE Vw8An01ZXFsY6XFcFhEDDC9NP4B705W6 =l28+ -----END PGP SIGNATURE----- _______________________________________________ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
