[OSM-dev] osm2pgsql for 64-bit IDs

Jukka Rahkonen jukka.rahkonen at latuviitta.fi
Tue May 24 10:04:25 BST 2011

Jochen Topf kirjoitti:
> On Mon, May 23, 2011 at 04:18:05AM -0500, Scott Crosby wrote:
>> On Sat, May 21, 2011 at 9:52 AM, Jochen Topf <jochen at remote.org> wrote:
>> >
>> > If we use unsigned ints we have some more time. Problematic would only
>> be
>> > a few cases where negative IDs are currently used (like in JOSM for
>> data
>> > thats not yet uploaded to the server). But it seems wasteful to me, to
>> go
>> > to 64bit a year or so earlier than needed to accommodate this case.
>> The 64 bit transition is unavoidable. I think this would double the
>> effort, because we'd all have to go through our software twice, once
>> to fix signedness bugs, and a second time to go to 64 bits. In
>> addition, the Java stack couldn't transition to unsigned ints anyways,
>> as Java lacks unsigned types. An unsigned int transition would be a
>> 64-bit transition.
> First: It has always been clear that sooner or later we will need the
> 64bit
> space for OSM IDs.
> The file formats used for exchanging OSM data already allow them. For XML
> there is really no limit on the size of the ID and for PBF the IDs are
> defined as sint64. So we are fine here.
> But in practice in their software people have often used 32bit IDs
> instead,
> because a) currently they are enough and b) they are often more efficient
> in
> space and/or time.
> I think it is up to the implementor of each software to decide what
> internal
> representation he uses for IDs. Implementors just have to be aware of all
> the issue involved.

More information about the dev mailing list