Reference systems, transformations, geoids and other geodetic stuff – exemplified by Minecraft

When representing the real world in a computer game one will face the same problems map-makers have dealt with for centuries! Here is a little technical insight into how we get a somewhat spherical reality into a flat playable world.

The Washington Family by Edward Savage. Martha Washington is pointing with her fan on a map on an avenue later known as Pennsylvania Avenue. Source: National Gallery of Art.

Maps have been a source of fascination and inspiration since explorers went travelling and sketched visited locations for others to learn from. Maps are models of the real world presented in a way, so we can reconstruct it in our imagination without actually being there –  a predecessor for modern time’s virtual reality systems like Microsoft HoloLens and Occulus Rift.


The Hunt-Lenox Globe. Here be dragons! Source:

Today most of our maps are digital. A road is no longer a line drawn with a pencil on a piece of paper but is now a digital object in a database with attributes attached (eg. name of the road, pavement type, ownership etc). This kind of data is known as GIS data (GIS: Geographic Information System) .

Minecraft worlds created by GeoBoxers are made by compiling a vast array of GIS data into a special binary format used by Minecraft. The GIS data can either be in the form of traditional digital maps featuring building polygons, road centre lines, fences and many other objects or other types of data such as height data i.e. contour lines or airborne laser scans.


GIS data for an urban area (Aarhus, Denmark). Data source: Agency for Data Supply and Efficiency.

Representing real world geographic data in Minecraft sets the challenge of choosing a transformation between the coordinate system in which the GIS data is given and Minecraft’s somewhat peculiar 3D coordinate system.

The real world is not flat – on a large scale it’s pretty much ellipsoidal. However, we often want to represent a part of the surface of the Earth on a map (on paper or on a computer screen) – so we use map projections to map from the curved surface of the ellipsoid onto a flat surface (2D).

We also agree that our landscape is not really a positively curved, rotationally symmetric ellipsoid. There are hills, valleys, buildings and so on. We get around that with the help of so-called height models, which represent the surface in a coordinate system which is a combination of a flat 2D planar system and a height axis. The height axis can represent height above the ellipsoid, a truly geometric concept, or the height above a geoid, that carries the important geophysical information that water tends to run downhill!


1. Ocean, 2. Reference ellipsoid, 3. Local plumb line, 4. Continent, 5. Geoid. By MesserWoland (Own work) [GFDL, CC-BY-SA-3.0 or CC BY-SA 2.5-2.0-1.0], via Wikimedia Commons.

The surface representation we get from a gridded height model, i.e. one surface height for each cell in a regular grid, is not able to capture all possible surfaces, topologically and geometrically. However, this simple representation is good enough for many purposes, for example as a base for constructing a recognizable terrain in Minecraft.   


The National Danish Elevation Model, DK-DEM 2016. Data source: Agency for Data Supply and Efficiency.

Of course, since we all agree that the world is (at least) 3-dimensional, we could also make the more drastic choice of representing our geodata (combined GIS and height data) in a true 3D XYZ coordinate system with origo in the center of mass of the Earth. This would rid us of a lot of the problems with map projections, e.g.: not being able to represent the whole Earth in a single 2D map, distortions of geometry which are unavoidable (Gauss, and having to maintain an abundance of transformations between different map projections.

But choosing a true 3D system would give us other problems, like not being able to plot the world on a traditional paper map or the computer screen equivalent. And that’s probably the historic reason for not going down that road. However, given today’s computer power and smart 3D visualisation software (like game engines), perhaps it’s about time? But that’s a whole different story, which we’ll leave for now.

Minecraft’s 3D coordinate system

Minecraft operates with a 3D XYZ coordinate system. The X-axis is pointed towards east, so far so good. But to make things interesting, the Y-axis points up while the Z-axis points south, hmmm… No problem, an orientation preserving transformation to the rescue! Admittedly, we only realized this after trying to navigate in a mirrored version of a first small prototype of Denmark in Minecraft.

For the planar XZ-part, Minecraft worlds are in principle endless, only limited by available disk space. But for good reasons storage, format handling etc., a height limit for the “buildable” region of the XYZ space has been imposed – currently this is ranging from 0 to 255 (a single byte) in height (the Y-coordinate).

In Minecraft’s 3D coordinate system it would actually be possible to geometrically represent a chunk of the curved 3-dimensional Earth in true 3D. However, the height limit of 256 blocks would quickly bound the size of a region representable in scale 1:1. And the built-in gravitational system along the Minecraft Y-axis would be quite off. So we go with a 2.5D system as briefly discussed above.

Given our geodata in such a 2.5D system, let’s call a coordinate (E,N,H) (easting, northing and ‘height’), we need to find a good transformation to Minecraft’s XYZ-system to map an object into Minecraft blocks. And it better be a transformation that makes the geometry in Minecraft look about right – we are going to walk around in the hills and valleys and enter the buildings, and want it to look true to reality.

That’s actually a difficult problem, getting a faithful representation of the geometry. As we know, in a 2.5D system there will be geometric distortions – a flat map cannot truly represent all distances (Gauss again). But if we cleverly choose a map projection, in which the distortions are not too disturbing for the area of interest, we might be able to do with a simple linear transformation to get to Minecraft coordinates.

For the Denmark in Minecraft project we worked with geodata in the UTM zone 32 projection (EPSG:25832 for geo-nerds), which covers Denmark with a tolerable distance distortion (up to 40 cm per kilometer in the most eastern region, the island Bornholm).  

For the height component our geodata were given in the Danish height system DVR90, whose zero-level is adjusted to the mean sea level around the year 1990. We made the choice to place the DVR90 zero level in Minecraft coordinate Y=20, to leave some underground room for sea and Minecraft minerals. Luckily, the height range of the Danish landscape fits well into these bounds. With the highest point being approximately 178 m above sea level, and not too many regions below sea level, there was enough space within the 256 m limit to leave space for buildings on top of hills and ground below one’s feet. To our knowledge, only one deep hole on the rocky island of Bornholm had to be truncated (this was done automatically in our code, of course).  

Benefits of doing it right!

By using a well-defined map projection we are able to calculate back and forth between our Minecraft coordinate system and real-world coordinates. And this is where the “fun” becomes usable.

  • With our tools it is a trivial task to extract user creations to city planners and embed in proposals for decision makers.
  • Almost all architects work in 3D and use digital tools. An architect’s vision can be converted to Minecraft for citizens and decision makers to review – even add their own input.
  • All kinds of geographically related data can be shown in the Minecraft worlds.

For a very live example be sure to check out Vibcraft and read our article on change detection. Vibcraft, Denmark in Minecraft and other of our projects are only possible when the foundation of maps – the geodesy – is treated correctly.