Every map begins with a simple question: how can any position on Earth be represented consistently, divided into manageable areas, and retrieved without searching an entire dataset? For NDS.Live, an automotive map data standard used across modern navigation ecosystems, the answer starts with a shared coordinate system and a fixed global tiling scheme.
These foundations are now open. Developers can read and implement the coordinate encoding, Morton code, tiling scheme, and packed tile ID without signing up for the NDS.Live Developer Portal. Open source reference implementations covering NDS mathematical concepts, such as coordinate encoding and tiling, are now available on GitHub in multiple programming languages.
NDS.Live uses WGS 84, the World Geodetic System 1984, as its standard coordinate reference system for latitude and longitude. WGS 84 provides a fixed global frame for geodesy and navigation, allowing almost every point on Earth to be identified by two values: x for longitude and y for latitude.
The origin lies at the intersection of the WGS 84 prime meridian and the equator. NDS.Live also represents height relative to the WGS 84 ellipsoid. This differs from NDS.Classic, which uses EGM96 for height information.
Geographic coordinates are usually written as floating-point degrees. NDS.Live converts them into integers so they can be stored, compared, and processed efficiently and consistently across implementations.
The scaling is chosen so that 360° corresponds to 232, using the full range of a signed 32-bit longitude value. One NDS coordinate unit therefore equals 90 / 230 degrees of longitude or latitude.
x = floor(longitude° × 230 / 90) // −231 ≤ x < 231
y = floor(latitude° × 230 / 90) // −230 ≤ y < 230
As an exception, the latitude value +2³⁰ is permitted when the North Pole must be represented.
Several rounding strategies are possible. Floor always rounds down; truncate rounds toward zero; and round selects the nearest integer. NDS recommends the floor operation because it consistently rounds in one direction and aligns better with the tiling schema.
Coordinates use two representations. Longitude is stored as a signed 32-bit value. Latitude requires 31 bits, and its value can be derived with ordinary 32-bit integers by masking the most significant bit. For example, −273788154 is 6fae5306 as a 31-bit integer and efae5306 as a 32-bit integer after sign extension.
Once longitude and latitude have been encoded as integers, NDS.Live can combine them into a Morton code. The method interleaves the bits of x and y, mapping a two-dimensional position to one ordered 63-bit value.
c = x₃₁ y₃₀ x₃₀ … y₁ x₁ y₀ x₀ // 0 ≤ c < 263
When c is stored in a 64-bit integer, a leading zero keeps it positive. Ordering positions by this value produces Morton order, also known as Z-order. This matters because nearby positions remain meaningfully grouped while the coordinate can be handled as a single number.
Like most map formats, NDS.Live organizes geographic data into tiles: bounded areas that can be requested and cached independently. A tile contains the data that logically or geographically belongs to it and is addressed through a single numeric tile ID.
The important part is that the grid is fixed and common to every NDS.Live map. Given a coordinate, an implementation can calculate the corresponding tile directly in constant time O(1) without a spatial index, search, or lookup table. The packed tile ID is derived from the same coordinate encoding, connecting location and data access through one deterministic scheme. These openly documented concepts give developers a practical entry point to implementing the foundations of an open-source map data format.
The tiling scheme divides the Earth with borders of constant latitude and longitude. If a tile has a southwest corner (x₁, y₁) and a northeast corner (x₂, y₂), every position satisfying x₁ ≤ x < x₂ and y₁ ≤ y < y₂ belongs uniquely to that tile.
Because tile dimensions are equal in coordinate units rather than meters, their areas appear approximately rectangular in the coordinate grid but form trapezoids on the Earth’s curved surface. The effect becomes more pronounced toward the poles.
NDS.Live defines levels 0 through 15. Level 0 is the broadest view and contains two tiles. At every following level, each tile is divided into four equal parts, creating a hierarchy from global coverage to increasingly fine detail. A service does not need to provide every level; tile-based NDS.Live services declare which levels they support.
At level 0, tile assignment is determined by the most significant longitude bit, x₃₁. Tile 0 covers longitudes from 0° inclusive to 180° exclusive, while tile 1 covers −180° inclusive to 0° exclusive. The level-0 tile number is therefore the most significant bit of the position’s Morton code.
At level 1, tile numbers use the three most significant Morton-code bits. Each label carries the parent tile number as a prefix, and the same principle continues through level 15. This makes the hierarchy visible in the identifier itself.
To produce the label 0-00-00-00-xx at the equator and prime meridian, level 1 follows an original Z-order beginning in the northwest. From level 2 onward, the Z is rotated to begin in the southwest.
Within each tile, discrete locations are addressed by row and column. All tiles at the same level have the same number of rows and columns. For a level k tile, each side contains 2³¹⁻ᵏ cells in coordinate units, while the complete level contains 2²ᵏ⁺¹ tiles.
The tile number is formed from the most significant 2k+1 bits of the Morton codes covered by that tile. The anchor point lies at half the number of rows and half the number of columns. One boundary condition remains: the final column at the 180° meridian is empty because the NDS coordinate encoding does not allow an absolute value to be calculated from that column.
A tile number alone is not enough because number ranges overlap between levels. NDS.Live therefore combines the level and tile number in a single 32-bit packed tile ID.
Level 0 needs one bit for its two tile numbers. Each lower level adds two more bits, reaching 31 tile-number bits at level 15. The remaining bit pattern marks the level. For level n, the marker is 2¹⁶⁺ⁿ; a bitwise OR combines it with the tile number.
packedTileId = 216+n | tileNumber // level 0 marker: 216 = 65536
NDS stores the packed tile ID as a signed 32-bit integer. At level 15, the level marker occupies bit 31, the sign bit, so every level-15 tile ID appears negative when interpreted as int32. This is a long-standing design choice rooted in programming languages without unsigned integer types, notably Java. Treat the ID as a raw 32-bit pattern rather than a signed magnitude; the ndslive-math implementations handle this behavior.
The coordinate and tiling concepts are now accompanied by code that developers can inspect, test, and implement directly. The open-source ndslive-math repository covers NDS ↔ WGS 84 coordinate conversion, Morton-code encoding and decoding, and NDS packed tile IDs.
Explore ndslive-math on GitHub for reference implementations in C++, Python, Java, JavaScript/TypeScript, Go, and Rust.
Opening these foundations makes it easier to understand how NDS.Live works, compare implementations, and start building without reproducing low-level coordinate and tiling logic from scratch. More topics will follow as further parts of the format are opened.
Looking for the complete NDS.Live format, including modules, Smart Layers, services, and tooling? Continue with the NDS.Live Developer Portal.
Back to news →