You can't use a hash to store coordinates (or any other data for that matter) because different inputs can result in the same hash. You can start with a value and get its hash, and thus compare if a hash and value are equivalent. But you can't start with a hash and walk backwards to get the value that created it.
The point wasn't to only store the hash, it was to use it as comparison criteria for a tree structure. The object itself stores its own coordinate, as well as the coordinate's hash.
I'd recommend using a quadtree* arrangement. Sort into 4 "buckets" based on the highest bit, then in each of those buckets, sort into 4 more buckets based on the next highest bit. Obviously, this needs to be a sparse tree, either lock it off at some specific level, and do a linear comparision of things in a region, or have a dynamic scenario where buckets are added or deleted depending on whether there's anything down that branch.
* for 2D data. To store sorted 1D data, it's a binary tree (e.g., a heap. but heap balancing won't work in 2D), and for 3D it's an octree. Either way it's largely the same algorithm.
Wow, that's not something I thought of until now. I guess that would definitely prevent any collisions between coordinates that aren't actually equivalent. I'll need to think of how I could implement that.