As the others have said, there are too many bits used at the poles. You might be interested in sphere point picking: http://mathworld.wolfram.com/SpherePointP

As the others have said, there are too many bits used at the poles. You might be interested in sphere point picking: http://mathworld.wolfram.com/SpherePointPicking.html http://mathworld.wolfram.com/SpherePointPicking.html x = sqrt(1 - u^2) * cos θ y = sqrt(1 - u^2) * sin θ z = u θ ∈ [0,2π) u ∈ [-1,1] The idea is to pick θ and u uniformly instead of latitude and longitude, which ensures equal spacing anywhere on the globe (no squishing at the poles). If you visualize the areas of the side of a cylinder and a sphere: AreaOfSideOfCylinder = 2 * π * * r * h = 2 * π * r * (2 * r) = 4 * π * r^2 AreaOfSphere = 4 * π * r^2 You can see that the areas are equal, but if you think of the triangular sections of a basketball, a uniform distribution uses just over half the bits of lat/long. That’s because the sections bulge out, and also latitude isn’t as susceptible to pinching (perhaps someone who works with distributions can provide the exact ratio). So my guess is that this scheme would use perhaps 6 or 7 digits, depending on whether a checksum is desired. I've used the formulas on that page with great success for things like random stars in OpenGL. This is loosely related to quaternions but I don't have enough math to describe how exactly. Quaternions sweep uniformly, whereas Euler angles pinch and suffer from gimbal lock.