64-bit Identifiers

On 9th of February, 2013, node identifiers surpassed 2,147,483,647 (2³¹ − 1), which is the highest number that can be stored as a 32-bit signed integer. On 10th July 2016, they reached 4,294,967,295 (2³² − 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.

Live info of largest node ID

Software list

Editors

OSM core tools

JOSM: any version
Potlatch 2: any version
Merkaartor: probably any version
iD: any version
Potlatch 1: any version

Third-party/niche products

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
OSM2Go: since 18th of February. Now maintained by AMDmi3 here.
QGIS 2.18 (OSM import part of core functionality)
QGIS OSM Plugin pre-2.0 QGIS (OSM plugin)
FreieTonne broken (cuts IDs to 2³¹-1 when modifying nodes beyond that limit)
Amenity Editor see https://github.com/grundid/amenity-editor/issues/3

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), full compatibility since 0.7.53 (Sept. 2016)
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 −2⁵⁹ or higher than +2⁵⁹ − 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 2⁵³)
Imposm: 2.4.0 (30th of March, 2012)
- imposm.parser: all versions
jXAPI
planetdump: since 14th of February 2013

Rendering

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

Validation tools

coastcheck: SVN 29238 (8th of February)
OSMCoastline
OSM Inspector: since 13th of October, 2013

Routing

Routino: all versions support true 32-bit ids (2³²), 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)
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.
Osm2pgrouting: can process 64bit data from OSM.

OSM History

osm-history-splitter with recent osmium
osm-history-renderer with recent osmium

Hints for developers

Web applications

PHP needs a binary compiled for 64-bit (and must be running on a 64-bit hardware). [1] 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

Java tools processing OSM IDs must use the data type long to store it which will be 64-bit wide on all architectures.

Test data

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 2³² - 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.