Unlike the picture, the earth "potatoe" (the earth is a
http://en.wikipedia.org/wiki/Geoid, not a ball) would then not be mapped onto a cube, you rather propose something like a 3D coordinate system (with a weird way to number coordinates) that is leaving earth in it's shape as it is and you just say "I am approx. at cube xxx and want to get to cube yyy" and some engine or so could then check (for a plane for example) which cubes belong to free airspace where I am allowed to travel and then suggest a route.
Issues I have with your approach:
Cube numbering. - Why not use either the center of mass or an imaginary point somewhere out in space as reference and state you're (x/y/z) meters away from this point?
21 million meters squared. - Why exactly 21 million meters?
Using cubes to map a (more or less) ball. - There are 8 corners where you can map cubes far further out into space than elsewhere.
No clear conversion from existing coordinates. - Converting from existing standards seems like a nightmare. Also, where is the Mt-Everest cube if you only have it's latitude and longitude? On the peak? On the surface of the Geoid and the peak is some 1000 meters above that?
1 cube off = huge jump. - You say it makes for great error checking, I say entering a number where each digit matters a lot is difficult. Also current WGS-84 coordinates require far fewer digits to be more precise (even if you would include elevation)
Cubes are not perpendicular to the ground except at the poles and the equator. - In the places where most people live, cubes are actually at an angle towards the ground. Mapping single cubes to buildings for example will be really hard and probably will require decimeter or even centimeter resolution in narrow streets.
What about cubes that are outside of the 21 million cubic meters? Where is the moon right now in your cube system? The sun? Alpha centauri?
http://www.wolframalpha.com/input/?i=ld%2821000000^3%29 <-- your number of blocks requires at least 73 bits. This is too much for fast computation currently... I mean yes, it's possible of course but unless you have VERY good reasons ("Bitcoin has 21 million units" is NOT a good reason!) it's unlikely that anyone is happy with this amount of digits (digits in the binary system that is).
Please explain me in detail how your system is better than using latitude/longitude/elevation + timestamp and what problems you currently face that will be solved with this approach.
Also please code up some examples, I want to be able to enter a location on google maps and get the cube number for my doorstep...
As I understand it:
Center of mass is Cube #0
You slice the earth from north pole to south pole along the 90°/270° meridian and number cubes starting from the middle like this:
Where does cube #10 belong now? On top (north) of #9 or on top (north) of #2? both would be logical placements, however you said "spirals", so I guess it's above 9, like this:
25 10 11 12 13
24 9 2 3 14
23 8 1 4 15
22 7 6 5 16
21 20 19 18 17
Anyways, as you will find out this way you won't be able to number 21 million squared cubes nicely, as they don't have a clear center piece (only uneven numbers would work).
This means after a full square of 20999999x20999999 cubes has been filled, you add another row on the top and in the "east" (to the right) to get to 21 million, no bottom or left row.
Then you start with the cube #441000000000001 next to cube #1 (imagine it being in front of the screen or sticked right onto it, if north is up) and play the same game, then cube #882000000000001 gets glued on the other side (behind the screen with the first 441000000000000 cubes) etc.
To get the cube coordinates of any point on earth you just need it's polar coordinates (latitude longitude + distance from COM of the earth -
http://en.wikipedia.org/wiki/Spherical_coordinate_system). Then you can already immediately know which slice you're going to end up on, so the first 11 digits are already known, but because of the spiral numbering you need to do a bit of magic for the last part.
For this one just looks at the slice you're going to end up on, project the angles onto a 2D surface and voilá, you have a vector from [11digits known]00000000001 to your desired end point. Then you just need to either know or generate a square with these numbers that's large enough to contain this specific point, get the remaining up to 11 digits of the point and you're done.
This would be far easier if they would be numbered in a more sane way (not spiralling), but maybe there are even some mathematical models out there that can quickly handle this spiralling thing as well (e.g. all uneven square numbers are on the center to northwest line, once you know the cartesian coordinates of a point you know between which 2 square numbers it MUST lay...).
