[OSM-dev] pbf2osm bug: way and relation timestamps in 1969

Scott Crosby scrosby at cs.rice.edu
Mon Nov 22 17:25:33 GMT 2010

On Mon, Nov 22, 2010 at 10:14 AM, Frederik Ramm <frederik at remote.org> wrote:

> Dear pbf2osm devs,
>   please consider this example:
> This file represents relation #882 as downloaded from the API with
> relation/882/full:
> http://www.remote.org/frederik/tmp/r882orig.osm
> I convert this to pbf using Osmosis (--rx then --wb)
> http://www.remote.org/frederik/tmp/r882orig.pbf
> Then I convert it back to osm with Osmosis (--rb then --wx), and the result
> is correct:
> http://www.remote.org/frederik/tmp/r882osmosis.osm
> However when I convert the pbf back to osm with pbf2osm, I get wrong time
> stamps for all ways and relations (not nodes). They are all in 1969:
> http://www.remote.org/frederik/tmp/r882osm2pbf.osm
> I'm using a current checkout from your git repository, or at least I think
> I do.
> Can it be fixed?

The problem is a 32-bit overflow. As a workaround, cast timestamp to a long
long in this macro.

  #define printtimestamp(attribute, timestamp) \
      char tsbuf[21]; \
      deltatime2timestamp((timestamp * pmsg->date_granularity) / 1000,
tsbuf); \
      fputs_unlocked(" "attribute"=\"", stdout); \
      fputs_unlocked(tsbuf, stdout); \
      fputc_unlocked('"', stdout);

The root cause is that I declared timestamp as an int32, not an int64 in my
osmformat.proto files. (Now fixed.) The generated C code declares timestamp
as an int, which, without promotion to an long long, causes this calculation
to overflow.

This is not a fileformat bug or incompatability. The osmosis writer code
will not generate any corrupt PBF files due to this issue because it does
not generate files with a timestamp granularity other than 1000ms.

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

More information about the dev mailing list