On 9th of February, 2013, node identifiers surpassed 2,147,483,647 (231 − 1), which is the highest number that can be stored as a 32-bit signed integer. Software that uses such variables will break, so it is important that everyone has latest versions of every tool in their toolchains. This is a list of minimum version numbers of different software, frameworks and APIs that support 64-bit identifiers (or unsigned 32-bit identifiers for some cases).
OSM core tools
- JOSM: any version
- Potlatch 2: any version
- Merkaartor: probably any version
- iD: any version
- Potlatch 1: any version
- Vespucci: r418 (14th of February, 2013)
- POI+ 1.5.1 (15th of February, 2013)
- iLOE 1.9.4 (30th of June 2011, no longer maintained); probably also earlier versions
- FreieTonne broken (cuts IDs to 231-1 when modifying nodes beyond that limit)
- QGIS 2.0+ (OSM import part of core functionality)Bug 10790 You can still import to QGIS but it will show negative values for ids >= 231. Imports to QGIS will start breaking soon in early 2016 when new node IDs >= 232 will not even be representable as negative signed 32-bit values but will collide with unrelated nodes ; unless a new 64-bit ready version will be released, QGIS will no longer be usable with newer OSM data spreading all over the world.
- QGIS OSM Plugin pre-2.0 QGIS (OSM plugin)
- OSM2Go: since 18th of February. Now maintained by AMDmi3 here.
General OSM processing
Tools, frameworks, libraries - data conversion, database interaction, APIs, whatever.
- osm2pgsql: 0.81.1 (13th of September, 2012) and previous versions with 64bit id space enabled
- Osmium: since 4th of January, 2013
- Overpass API: since 0.7.1 (10th of December, 2012)
- Osmosis: 0.42 (16th of February, 2013)
- Recent versions before 0.42 will also work in most cases, with the following exception: the options --used-node or --used-way will, in general, fail, unless the additional option idTrackerType=Dynamic is supplied; same if idTrackerType=Bitset or idTrackerType=IdList is specified explicitly.
- osmconvert, osmfilter, osmupdate: any version; do not use IDs lower than −259 or higher than +259 − 1
- GDAL/OGR: 1.10.0 (29th of April, 2013)
- Splitter: all versions
- Srtm2Osm: 1.10 (27th of October, 2012)
- Revert scripts: all versions (perl supports integers up to 253)
- Imposm: 2.4.0 (30th of March, 2012)
- imposm.parser: all versions
- planetdump: since 14th of February 2013
- Mapnik: 2.2 (4 June 2013); the standard osm2pgsql setup was not affected
- Maperitive: 1.1.2001 (October 2011)
- Mkgmap: r33 (19 Dec 2006)
- OSM2World: any version
- Map Composer: 0.91
- Smrender: all versions
- Routino: all versions support true 32-bit ids (232), version 2.0.2 supports 64-bit ids after recompilation (details).
- OSRM: 4.9.0 (24th of December, 2015)
- gosmore: SVN 28847 (24th of October, 2012)
- CycleStreets: SVN r10282 (19/Feb/2013)
- Osm2pgrouting: converting IDs in signed int (tried to inform someone via the mailing list).
- the OsmAnd Mapcreator can process the 64bit test data from this page without errors, and Osmand app displays them correctly.
- ZANavi can process 64bit data from OSM.
Hints for developers
PHP needs a binary compiled for 64-bit (and must be running on a 64-bit hardware).  Test your server, for 64-bit it must return 8 bytes for the size:
<?php echo "PHP int size: ".PHP_INT_SIZE." which is max ".PHP_INT_MAX;
Or from the Command-Line:
php -r 'echo (PHP_INT_SIZE == 8 ? "64bit\n" : "32bit\n");';
When using a 32-bit PHP all IDs returned from postgres (BIGINT) are converted into a string. When doing numerical operations with the ID a lib like GMP is required.
Java tools processing OSM IDs must use the data type long to store it which will be 64-bit wide on all architectures.
You can test your software against test data (by Frederik Ramm).
Tom has bumped the database sequence numbers on master.apis.dev.openstreetmap.org to 232 - so if you have any code that talks to the API, you can use that service to see if it works with 64-bit IDs returned from the API.