64-bit Identifiers

From OpenStreetMap Wiki
Jump to: navigation, search
Available languages
English

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).

Live info of largest node ID

Software list

Editors

OSM core tools

Third-party/niche products

  • Yes check.svg Vespucci: r418 (14th of February, 2013)
  • Yes check.svg POI+ 1.5.1 (15th of February, 2013)
  • Yes check.svg iLOE 1.9.4 (30th of June 2011, no longer maintained); probably also earlier versions
  • No-Symbol.svg FreieTonne broken (cuts IDs to 231-1 when modifying nodes beyond that limit)
  • No-Symbol.svg QGIS OSM Plugin
  • Yes check.svg OSM2Go: since 18th of February. Now maintaned by AMDmi3 here.

General OSM processing

Tools, frameworks, libraries - data conversion, database interaction, APIs, whatever.

  • Yes check.svg osm2pgsql: 0.81.1 (13th of September, 2012) and previous versions with 64bit id space enabled
  • Yes check.svg Osmium: since 4th of January, 2013
  • Yes check.svg Overpass API: since 0.7.1 (10th of December, 2012)
  • Yes check.svg 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.
  • Yes check.svg osmconvert, osmfilter, osmupdate: any version; do not use IDs lower than −259 or higher than +259 − 1
  • Yes check.svg GDAL/OGR: 1.10.0 (29th of April, 2013)
  • Yes check.svg Splitter: all versions
  • Yes check.svg Srtm2Osm: 1.10 (27th of October, 2012)
  • Yes check.svg Revert scripts: all versions (perl supports integers up to 253)
  • Yes check.svg Imposm: 2.4.0 (30th of March, 2012)
  • Yes check.svg jXAPI
  • Yes check.svg planetdump: since 14th of February 2013

Rendering

Validation tools

Routing

  • Yes check.svg Routino: all versions support true 32-bit ids (232), version 2.0.2 supports 64-bit ids after recompilation (details).
  • Yes check.svg OSRM: all versions; stores node ids in unsigned int (up to 232)
  • Yes check.svg gosmore: SVN 28847 (24th of October, 2012)
  • Yes check.svg CycleStreets: SVN r10282 (19/Feb/2013)
  • Exclamation.svg Osm2pgrouting: converting IDs in signed int (tried to inform someone via the mailing list).
  • Yes check.svg the OsmAnd Mapcreator can process the 64bit test data from this page without errors, and Osmand app displays them correctly.
  • Yes check.svg ZANavi can process 64bit data from OSM.


OSM History

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 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.