UUIDs?

[apendleton]

We've had discussions in the past about running multiple internal instances of the OSM stack for different data projects, and I imagine we might want to do the same with this tool. It would be nice if you could then later combine the contents of two such servers and not have their IDs collide. Could we consider UUIDs instead of autoincrementing integers? (Not sure this would play nice with JOSM 🤔 )

[ingalls]

@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?

[apendleton]

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.

[ingalls]

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.

[apendleton]

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

[ingalls]

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.