[osmosis-dev] Problem creating pbf data with osmosis 0.39

[Michael Prinzing]

On Fri, 23 Sep 2011 18:37:46 +0200, Igor Podolskiy wrote:

Hello Igor,

>I must admit that I don't know anything about the mkgmap splitter (I 
>barely knew that it even exists ;)). I just looked at the sources and it 
>very well might be that the splitter's BinaryMapParser has the same bug. 
>The function parse(Osmformat.Headerblock) there [1] looks suspiciously 
>similar to what Osmosis did before the fix in OsmosisBinaryParser :) 
>IMHO there should be a check for hasBbox(), too... but as I said, I 
>might be looking at the wrong sources for all I know. Any mkgmap people 
>here? :)

Oh, thanks for looking into it. I'll go back to the mkgmap list and
report it there.


>I can think of another reason why you might see those empty bounding 
>boxes in your data, though. If you have a file no-bb.osm.pbf without a 
>bounding box set and a following trivial osmosis pipeline:
>
>osmosis --read-pbf no-bb.osm.pbf --write-pbf x.osm.pbf
>
>then the following happens: the PBF reader reads the input file, emits a 
>spurious bounding box and passes it down the pipeline. The PBF writer 
>gets the bounding box from the pipeline and dutifully writes it into 
>x.osm.pbf since it doesn't know that the bounding box has been 
>spuriously generated by the PBF reader. Now you have an x.osm.pbf with a 
>proper bounding box explicitly set to 0,0,0,0. This bbox will of course 
>pop up in every PBF reader since it is actually written to the file.
>
>Is there any chance that the files in question have been generated by an 
>Osmosis pipeline which involves both reading and writing a pbf file 
>without a bbox? :)

No, usually I am not reading pbf files with osmosis. I am just
converting data from xml format to pbf in order to give it to the
mkgmap splitter. The conversion back to xml was just a test to see if
the problem I had with the splitter also occurs when I would read the
pbj data with osmosis. And it did :)


>Hope that helps

Yes, thank you very much for your explanations.

Michael