Scale
1 centimetre pixels. This is an arbitrary size, based on the needs of drones and robots. Centimetre accuracy is sufficient for manoeuvring and docking, and any bumps in a path or road less than a centimetre in height won’t affect wheeled devices. A kerb several centimetres in height could be a problem, so it would need to be mapped.
The system should be designed to allow higher detail in the future, say 0.1 mm. That level of detail could occur within buildings within a decade. I cannot think of any need for going beyond 0.1 mm.
Too Big To Store
1 centimetre pixels means a lot of data if the entire planet is (eventually) mapped.
The surface of our planet totals 510,072,000 square kilometres. And there are 10 trillion square centimetres to a square kilometre. So thats 5,000 million trillion pixels if the map was 2D.
In 3D, the world’s tallest structure is 829.8m, so the map should go 900m high, and say 100m deep (to allow for basements). 1 kilometre is 100,000 centimetres, so that brings us to 500 septillion. Allowing 64 bits per pixel gives us 4 quintillion gigabytes. Or 4 quadrillion terabytes.
Google’s data centres currently hold 10 million terabytes (only 20,000 terabytes for all the Google Maps data). MapMerge would require 400 million times more than that, if every pixel was to hold unique information.
Two-thirds of the planet is water, so that brings us down to 133 million Googles.
Satellite-based efforts at mapping global urban extents fail to agree on the size and pattern of urban land use, with estimates ranging from 0.2% to 2.4% of terrestrial land surface circa 2000 [source].
So we will use 1%. That brings us down to 1.3 million Googles.
If the average building in the world is 5 metres high, then that’s only 0.05 of a kilometre, so that brings us down to 6500 Googles.
Video Game Level Design
Clearly storing information pixel by pixel is too difficult. So the solution will be wire-frame at the global level, with software filling in the gaps when it is rendered. Most likely converting a system used for designing levels in first-person shooters would be the way to go. It might be based on Google’s KML, or a whole new system.
Most of what will be captured outdoors will be grass, water, pavement and walls. The answer might be a combination of wire frame and photos. To describe a concrete wall, you just need the coordinates of the corners, and a sample of the surface to be used for texture mapping.
Another solution would be to vary the quality according to the level of interest. Times Square could be rendered at the highest level of detail, while a desert in Mongolia might only require a very low level. Initially levels of interest can be guessed at, and later based on actual numbers of virtual visitors.
I suggest that borders between different levels of detail are blended for a more pleasant experience.
Just Roads
It is worth doing the math for roadways, because Google is probably planning to map all the world’s roads at centimetre detail for self-driving vehicles.
The entire world has 64,285,009 km of roadways, and I guess that they average 10 metres in width. 642,850 square kilometres = six quadrillion square centimetres. Or 100 terabytes. So 2D storage of the roadways at centimetre level is well within Google’s capability.
The amount of 3D they need for mapping kerbs and speed bumps would be minimal.
Existing Mapping Systems
InterMap’s NextMap 30 has mapped the elevations of the entire planet. Albeit at a 30 metre scale.
OS MasterMap has detail down to about 1 metre, for all of the United Kingdom.
The GPS Problem
Standard GPS won’t have the accuracy MapMerge requires. It will certainly be part of the equation, but with additional accuracy provided locally. GPS positioning needs to be enhanced using existing technology like Differential GPS or mobile phone tracking, or something brand new. I envisage technology similar to Apple iBeacons, installed throughout cities. MapMerge will be as active as cell phone networks, so a purpose built physical infrastructure would make sense if there was no other way.
The beacons could be like trig stations, and combined with spawning points, which I suggest should have a physical presence in the real world.
Ideally the accuracy will be to a centimetre. That will be necessary for robots to navigate streets and doorways. Drones will also need high accuracy for landing.
By combining visuals with MapMerge, lesser accuracy might be acceptable, perhaps 10 centimetres. However cameras aren’t guaranteed to always work, and the lenses can become dirty or damaged. So having a backup navigational system via MapMerge is essential.