[OSM-dev] osm2pgsql for 64-bit IDs
igor.brejc at gmail.com
Sat May 21 02:53:51 BST 2011
Can you give some rough estimates on how much time we still have until this
64bit issue comes up?
On Fri, May 20, 2011 at 10:42 PM, Frederik Ramm <frederik at remote.org> wrote:
> not long now and we'll have our nodes IDs exceed the magical 2^31-1
> limit, a time at which many applications will doubtless experience their own
> little version of the year 2000 problem ;)
> I have modified osm2pgsql to support 64 bit IDs (int8/bigint on
> PostgreSQL). The modified version is a branch called osm2pgsql-64, in the
> same directory as the original osm2pgsql source code.
> I didn't dare to simply commit my changes to osm2pgsql proper but in
> theory, if you don't set the OSMID64 compile flag, the new version should
> behave exactly as the old.
> osm2pgsql used to make use of the "intarray" contrib module in slim mode,
> Since that module does not support the int8/bigint data type, I had to
> change things to use PostgreSQL's built-in array capabilites.
> For reasons I do not fully understand, the intarray module is now actually
> harmful to this new version of osm2pgsql because it seems to keep the
> built-in array methods from using indexes. This means that while the old
> osm2pgsql required that you load _int.sql, the new osm2pgsql will actually
> complain if you have done that.
> It would be great if a few people could test-drive the new osm2pgsql (in 32
> or 64 bit ID mode), and fix/report any bugs they might find. I hope that
> everything is fine, I made no major blunders, and we can soon replace the
> existing implementation with the no-intarray 64-bit-capable version.
> dev mailing list
> dev at openstreetmap.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the dev