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. On 10th July 2016, they reacheded 4,294,967,295 (232 − 1), which is the limit for a 32-bit unsigned 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.
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 started breaking in July 2016 when new node IDs >= 232 are not even representable as negative signed 32-bit values but 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) - Additional Hotfix needs to be applied for full 64bit compatibility. Affects all versions from 0.7.1 up to and including 0.7.52. See Github issue. Although the Github ticket mentions that the issue is fixed, this does not apply to releases provided via dev.overpass-api.de/releases. If you run your own instance of Overpass API, you either have to apply the hotfix or wait for the next release. In any case, a full database reimport is necessary due to database corruption.
- 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.