Open gmaclennan opened 8 years ago
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.
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
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-p2pids
throwsNumberFormatException
.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.