Then Ri, Di, R, D, and rotate top deck until docking commences.
Topic: Earth Cubic Spacetimestamp (ECS) (Read 4333 times)
Sweet, so to finish crossing the Atlantic I just do: Up, right, up inverted, left inverted, up, right inverted, up inverted, left.
Then Ri, Di, R, D, and rotate top deck until docking commences.
Then Ri, Di, R, D, and rotate top deck until docking commences.
Since your location numbers are seemingly quite random (at least for people on the surface of the earth) using these as ZIP code might not be very useful - just in my living room I have more than a dozen cubes that probably have VERY different decimal representations.
If you wanted you could cluster the counting a bit more widely so that each cluster of cubes corresponded to the usual zip codes that map our neighbourhoods. Then you would use prefixes, or other short-way pattern, to designate your succinct zip codes.
It would be a great challenge for architects to build interconnected buildings (with vertical and horizontal elevators) in the best places for interesting, aesthetical and intelligent reasons.
The future is exciting.
http://earth-cubic-spacetimestamp.blogspot.co.uk/ [Under serious construction]
Why this obsession with 22 digits (and no, I don't see 22 digit numbers as "unambiguous way of expressing a geolocation")? Actually you're using 11 digits for a slice ID and another 11 digits for a cube ID... also decimal is not everything, as I already said, binary representations matter too.
I have to correct myself by the way, the SliceID is also not easily guessable of course (441 (or 442?) possibilities), but it can be fixed after finding the correct cube in a slice.
"Pretty good number" is not convincing enough for me, sorry. GPS satellites are at ~20200 km altitude - add to this the ~6371 km radius of the earth and you cannot even map these satellite orbits with your system.
With fixed point in space I meant fixed above the surface, e.g. 1000 km above the north pole or whatever. With your added timestamp however one could even take the center of our solar system as reference point and just calculate planetary positions at certain times...
Calculations might take less than a second depending on the hardware used... Please code some examples that take the current (2008, 10km resolution) standard geoid data and convert GPS coordinates with/without elevation and return the respective cube number. It's not even that hard and without some examples people won't anyways take you seriously.
Since your location numbers are seemingly quite random (at least for people on the surface of the earth) using these as ZIP code might not be very useful - just in my living room I have more than a dozen cubes that probably have VERY different decimal representations.
I have to correct myself by the way, the SliceID is also not easily guessable of course (441 (or 442?) possibilities), but it can be fixed after finding the correct cube in a slice.
"Pretty good number" is not convincing enough for me, sorry. GPS satellites are at ~20200 km altitude - add to this the ~6371 km radius of the earth and you cannot even map these satellite orbits with your system.
With fixed point in space I meant fixed above the surface, e.g. 1000 km above the north pole or whatever. With your added timestamp however one could even take the center of our solar system as reference point and just calculate planetary positions at certain times...
Calculations might take less than a second depending on the hardware used... Please code some examples that take the current (2008, 10km resolution) standard geoid data and convert GPS coordinates with/without elevation and return the respective cube number. It's not even that hard and without some examples people won't anyways take you seriously.
Since your location numbers are seemingly quite random (at least for people on the surface of the earth) using these as ZIP code might not be very useful - just in my living room I have more than a dozen cubes that probably have VERY different decimal representations.
No,no,no,
sorry Sukrim, the image has nothing to do with my idea.
Please disregard that image. It is misleading!!!
My idea has nothing to do with the Shape of Earth or with mapping the surface of Earth to a cube.
And why 21 million meters as the edge of the Matrix cube?
Well, it works out it is a pretty good number given the size of Earth and atmosphere.
You could choose a smaller edge, but since you would use a number of cubes using 22 digits (cubes of 1 meter cube), 21 million meters works out to be a good number for the edge of the matrix cube. And it is also an interesting number because of bitcoin, so seems really a good choice.
A fixed point in space, would make the coordinates of a geolocation be changing all the time...
My system is just for Earth, hence the name of it.
You are wrong in thinking it would take great computational power to have a conversion tool from GPS coordinates to the corresponding cube number. It would probably take less than a second to calculate such cube number for any geolocation.
It is a very compact and unambiguous way of expressing a geolocation.
Could be used as zip code. And you can clearly see that a string of 22 digits is a very simple and unambiguous way of expressing a geolocation.
It has other advantages. See 'votecubecoin', for instance.
But using (x/y/z) meters from the center of mass, doesn't seem bad, comparing to my system. But is a different concept and I still like mine better.
Thank you for taking your time to think about it and discuss it.
sorry Sukrim, the image has nothing to do with my idea.
Please disregard that image. It is misleading!!!
My idea has nothing to do with the Shape of Earth or with mapping the surface of Earth to a cube.
And why 21 million meters as the edge of the Matrix cube?
Well, it works out it is a pretty good number given the size of Earth and atmosphere.
You could choose a smaller edge, but since you would use a number of cubes using 22 digits (cubes of 1 meter cube), 21 million meters works out to be a good number for the edge of the matrix cube. And it is also an interesting number because of bitcoin, so seems really a good choice.
A fixed point in space, would make the coordinates of a geolocation be changing all the time...
My system is just for Earth, hence the name of it.
You are wrong in thinking it would take great computational power to have a conversion tool from GPS coordinates to the corresponding cube number. It would probably take less than a second to calculate such cube number for any geolocation.
It is a very compact and unambiguous way of expressing a geolocation.
Could be used as zip code. And you can clearly see that a string of 22 digits is a very simple and unambiguous way of expressing a geolocation.
It has other advantages. See 'votecubecoin', for instance.
But using (x/y/z) meters from the center of mass, doesn't seem bad, comparing to my system. But is a different concept and I still like mine better.
Thank you for taking your time to think about it and discuss it.
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:
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...).
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:
Code:
9 2 3
8 1 4
7 6 5
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:
Code:
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...).
Allow me to silently bow out of this thread...
I wonder where is cube Pi: 3141592653589793238462 
No, but for instance helicopters would only have to tap 22 digits to assign their destiny. Very practical to track an object in 3D space.
Also the fact that contiguous numbers do not correspond to contiguous cubes make it good for error checking.
Also the fact that contiguous numbers do not correspond to contiguous cubes make it good for error checking.
I would be weird living on a juncture with four different zones. Would the preceding one take priority?
Earth Cubic Spacetimestamp (ECS): Matrix of 9261000000000000000000 cubes. Such Matrix cube measures 21 million meters cubed. It is centered in the center of mass of Earth, and oriented along imaginary axis of Earth.
The timestamp is then added after a colon, using the UNIX timestamp format, but if the first digit after the colon is zero, the number of seconds is negative, that is, past UNIX birth.
The original/natural order of the cell cubes would be this: the cube at the center of the matrix cube would be the 1st. The 2nd would be the one contiguous to it on top of it, on its North. Then the 3rd the next one right to it, on East, the 4th the cube next on the right to the center, on West. Then, the 5th, down, on South, and all around, 6th below the center, 7th left to it and 8th, on the left of the center, and all around in spiral till you have all the center layer. Then you would get to the center again but on the second layer, going towards the Greenwich Time Meridian, and go all around in spiral again the same way, covering all the second layer. Then the third layer would be the layer contiguous to the center layer but in the opposite direction to the Greenwich Time Meridian; and the fourth layer contiguous to the second layer, and so on, and so fourth, till the last layer.
Twenty two digits are used for cube number and twenty two digits can be usedfor seconds but if less digits are needed for time less digits will be used. Example, 123456789023456789012:012345 (ECS)
Jump to: