How to get working with JOSM?

[gmaclennan]

JOSM using Integer.parseInt when interacting with the API for parsing the ID of a newly created changeset and parsing the new version number of an updated entity.

Java parseInt is 32 bits, so osm-p2p ids throws NumberFormatException.

I'm not sure where else 32 bit numbers are used. Should we send a PR to JOSM, or figure out a way for dealing with clients that use 32 bit ids? There might be other challenges with JOSM - we don't yet know how it will handle non-sequential version numbers.

How might we get JOSM and other potential clients working with osm-p2p? One option would be creating some type of temporary 'mapping' for each client between internal ids and ids exposed to a particular client, but this seems like it could be very fragile.

[ghost]

Right now ids use 64-bits (8 bytes). For 100,000 documents, the odds of a collision are acceptably low:

> var x = Math.pow(2,64), p = 1; for (var i = 0; i < 100000; i++) p *= (x-i) / x; 1-p
2.7104440913916505e-10

However, if we reduced the ids to fit in 32 bits, the odds of a collision become very likely:

> var x = Math.pow(2,32), p = 1; for (var i = 0; i < 100000; i++) p *= (x-i) / x; 1-p
0.6878122819637014

I think it might be better to push upstream against JOSM to accept larger IDs.

[gmaclennan]

Ok, so someone needs to scour the JOSM code for Integer.parseInt when it is used for ids or version numbers.

https://github.com/openstreetmap/josm/search?utf8=✓&q=parseInt

JOSM already handles 64-bit ids for entities, but not for other records like changesets. We should open a ticket for this on JOSM