UUIDs? about hecate HOT 5 CLOSED

@apendleton good call - Full UUIDs would be unsupported by JOSM :(

Ref: https://github.com/openstreetmap/josm/blob/f056eebb8f114b06b8c994a92d4ddb698dfd7f7e/src/org/openstreetmap/josm/data/osm/User.java#L25
Ref: https://docs.oracle.com/javase/tutorial/java/nutsandbolts/datatypes.html

But a 64 bit UUID like feature should be plenty unique for the foreseeable future. thoughts?

from hecate.

Sure, would be easy to implement. You'd lose lots of collision resistance though; you start to get into birthday paradox situations faster than you'd expect if you have lots and lots of features. I bet it would work though? Especially if, at insert time, you tried generating a random one and were willing to retry if you happened to hit a collision.

from hecate.

Oh @apendleton are you referring to UUIDs for Deltas, Features or UUIDs for users? I was referring to users in the above post where the utilization rate would be much smaller.

from hecate.

@ingalls I was thinking for features, so that you could initially start two instances for different classes of features (parts of the world, layers, etc.), and later combine those databases without ID collision. Not sure if this is a usecase we want to support...

from hecate.

I think for now we're going to take the approach of allowing the UI to connect to multiple instances, combining features at the vector tile layer. This avoids the problem of having to worry about UUIDs conflicting between servers.

from hecate.