Working with NDS delta updates of map tile services

15. September 2025

The Navigation Data Standard (NDS) introduces an efficient approach to keeping digital maps up to date through delta encoding. Instead of transmitting a full map update, only the changes (deltas) between the old and new versions are delivered to the navigation system. This significantly reduces data transfer, making it especially valuable for streamed and over-the-air (OTA) updates.

At the core of this process lies the NDS data structure, organized into modular tiles and layers. A vehicle’s onboard navigation database stores these tiles, allowing for precise updates at the tile level rather than replacing the entire map.

How delta encoding works in NDS maps

When a user first installs a map, the vehicle receives the complete dataset, which forms the foundation for all subsequent updates. From that point onward, the NDS format relies on a consistent versioning system that allows cloud services to track exactly which map version is stored in each vehicle. This approach ensures that updates are always applied correctly and in sequence.

Once a new map update becomes available, the system begins a tile-by-tile comparison between the updated data and the version already stored in the vehicle. Because NDS maps are organized into modular tiles and layers, this process is both efficient and precise, focusing only on the areas that have changed rather than the map as a whole.

To create the actual update package, a differencing tool generates a compact “delta” file. Instead of duplicating entire map sections, this file contains only the differences that means adding new features, removing outdated ones, or modifying existing data such as speed limits, traffic signs, or road geometry.

The advantage of this method is clear: vehicles download only the delta-compressed data, cutting transfer volumes by as much as 75%. This makes the approach especially valuable for over-the-air updates and cloud-based navigation, where cellular bandwidth and cost are critical considerations.

Finally, the delta is applied directly to the local map stored in the vehicle’s onboard database. This integration happens on-the-fly, ensuring that updates are incorporated seamlessly without disrupting map streaming, navigation accuracy, or overall performance.

Benefits of delta format in NDS maps

One of the most significant advantages of the delta format is its efficiency in data consumption. Because vehicles only download the differences between the old and new map versions, the amount of cellular data required for updates is drastically reduced. This not only lowers costs for automotive manufacturers managing large fleets but also benefits end-users who rely on mobile data connections.

The reduced data size also translates directly into faster updates. With less information to transfer, vehicles can download and apply changes much more quickly, ensuring that drivers always have access to the most current map information without long wait times.

Another important benefit is the ability to deliver incremental updates. Instead of depending on large, infrequent downloads, NDS enables continuous, small-scale updates that keep maps “alive” and consistently in sync with real-world conditions. This approach enhances reliability and ensures that navigation systems reflect up-to-date information at all times.

The delta format helps optimize storage requirements on the vehicle’s hardware. Since only compact update files are transmitted and stored temporarily, the system reduces the overall storage footprint, making the process more cost-effective and efficient for manufacturers and drivers alike.

NDS tile services

Tile services form a core element of the NDS.Live specification, enabling navigation systems to work with compact, geo-referenced portions of map data referenced as “tiles.” By breaking the map into these modular units, navigation systems can request and update only the areas that are actually needed, whether for real-time streaming or localized updates. This modular structure makes it possible to deliver precise, on-demand information while keeping performance efficient and scalable.

Core concepts of NDS tile services

Modularity and layering

• Data layers: NDS map data is structured into multiple layers, each dedicated to a specific type of information such as road topology, lane geometry, or speed limits.
• Tile-based structure: The data is divided into discrete, independent tiles, which serve as the fundamental delivery units. In NDS.Live, each tile is fully self-contained, avoiding cross-references to neighboring tiles and preventing so-called “avalanche effects” during updates.
• Smart layers: A Smart layer in NDS.Live is a pre-configured bundle of data layers optimized for a particular use case. For example, a Smart layer for Intelligent Speed Assistance (ISA) combines the basic road network with speed limit data to provide a ready-to-use dataset.

Optimized operations

• On-demand streaming: NDS tiles are delivered only when needed. Instead of downloading an entire map, the vehicle requests tiles relevant to its current position or route.
• In-vehicle cache: Once downloaded, tiles are stored locally in the system’s memory cache, allowing instant access without repeated downloads.
• Independent tile updates: Because NDS.Live tiles are fully self-contained, providers can update a single tile without affecting others. This minimizes data transfer and streamlines the update process.

Delta compression

• Incremental updates: Tile services are optimized for continuous updates. When minor changes occur-such as a new speed limit sign-only the compressed “delta” between the old and new tile is transmitted.
• Bandwidth reduction: By sending only differences instead of full tiles, delta compression cuts cellular data consumption, reduces costs, and accelerates update delivery.

NDS.Live and tile services

NDS.Live takes tile services a step further to meet the requirements of autonomous driving and highly dynamic data. One of its strengths lies in the flexibility of data delivery. Depending on the use case, data can be provided as SmartLayerTiles, which represent individual map tiles, SmartLayerObjects, which focus on specific map features, or SmartLayerPaths, which deliver data along a defined driving route.

To guarantee seamless navigation across map sections, NDS.Live also introduces intelligent tile-border handling. At the edges of tiles, the system inserts “artificial intersections” that allow applications to stitch together roads and lane topologies without gaps or inconsistencies. This approach ensures that users experience smooth transitions as they move across tile boundaries.

Underlying all of this is a cloud-based, service-oriented architecture. A central Registry Service helps applications discover available data services, while Smart Layer Services handle the delivery of the required tile data. Together, these components enable a highly scalable and responsive system designed for the connected and automated mobility ecosystem.

The process of delta updates for versioned tiles

• Unique tile identification and versioning: Each map tile is defined by its geographic coordinates and zoom level, with a version identifier assigned to both the tile and its data layers. Whenever data changes, the server creates a new version of the affected tile. 

• Server-side delta generation: The server runs a diffing algorithm to compare the old and new versions of a tile. It identifies changes at the byte or feature level and produces a compact delta file containing only those differences. 

• On-demand delivery: When requesting an update, the client sends the server its current tile version. Based on this, the server either delivers the complete updated tile (if the client’s version is too old or no delta exists) or a smaller delta file (if the version is recent enough). 

• Client-side patching: The client applies the delta to its cached tile using a patching algorithm, reconstructing the updated tile locally without downloading the full file. 

• Offline continuity: Because the full map is cached, the device remains functional even without connectivity. Delta updates mainly streamline transitions between versions, reducing the data needed when the network is available. 

Working with delta updates of versioned tile data

To better illustrate how NDS data layers and updates work in practice, let’s look at a simplified example. Imagine a map provider that delivers just a handful of key data layers:

• Road layer
• Road characteristics layer
• Road rules layer A (basic driving rules such as prohibitions)
• Road rules layer B (speed limits)

In this setup, the first three layers are updated monthly, while the speed limit layer (Road rules B) is refreshed every week. Importantly, version numbers only change when there’s an actual update in the content. For the sake of this example, we can assume that the monthly layers receive a new version number once each month.

To deliver these updates, the SmartLayer service is implemented through a static file service, such as a CDN or Cloud Blob Storage. All files are prepared in advance when an update is released, meaning the application server doesn’t need to manipulate files or dynamically stitch data together. In other words, SmartLayers are not generated on the fly.

This approach prioritizes simplicity and efficiency: relying on static access reduces computational overhead, under the assumption that storage costs are cheaper than the CPU resources required for real-time generation. Of course, the actual cost balance may vary depending on how many requests are expected and other operational factors, but the principle remains the same, static delivery can make updates lighter, faster, and more predictable.

When the map is first generated, all data layers start at version v1. At this point, a SmartLayer header (h1) and a corresponding SmartLayer BLOB called “latest” are created. This BLOB contains the header plus all the data layers, and it is delivered through the getLayersByTileId() method of the SmartLayer service.

From there, updates follow a predictable rhythm. Each week, new speed limits are added to Road Rules Layer B. Every time this happens, its version number increases, a new header is created, and a fresh SmartLayer is compiled. This new SmartLayer includes the updated speed limits layer along with all the other unchanged layers, and it always replaces the previous “latest” version. Older SmartLayers are not served via the getLayerByTileId() interface.

On a monthly basis, all data layers are refreshed together. A new header is generated, a full SmartLayer is built, and—once again—the latest version replaces the old one.

With this mechanism, the client always receives the most up-to-date SmartLayer containing the newest set of data layers available at that moment. However, there’s a drawback: the client must download the entire set of data layers each time, even if only one layer (like speed limits) has changed. For a client that already has version v1 cached, downloading the same unchanged data repeatedly creates unnecessary overhead.

The solution? A SmartLayer service that supports delta updates. By transferring only the differences between versions, clients can avoid redundant downloads, reduce bandwidth usage, and update their maps far more efficiently.

To support full updates and delta updates at the same time, the service needs to provide both of the following:

• Complete smart layer tiles for clients that have no data in the cache.
• Updated tiles with delta versions of the data layers for clients that already have older versions of the tile in the cache.

Smart layer header for delta updates

For version v2 of the rules layer with updated speed limits, the server generates both the complete data layer and the delta versions: the rules layer (v2∆) and the smart layer header (H2∆). The corresponding SmartLayer tile then contains only the delta header and the delta rules layer. Unchanged layers are not included—meaning their layer.ExternDescriptor fields are left empty, and their layer.data fields remain blank.

Downloading and applying delta patches

To efficiently update map data, the client and server follow a series of steps to download and apply delta patches:

• Initial Download: The client first calls the getLayerByTileId() method to retrieve the initial smart layer tile, version v1. 

• Caching the Data: Once received, the client unpacks the smart layer tile and stores each data layer and the header separately in a local cache in their serialized binary form. It is important not to further unpack the data layers, as the delta application mechanism works directly on the binary level. The original smart layer BLOB can be discarded since the container is no longer needed once the data layers are cached. 

• Checking for Updates: When looking for updates to the cached data, the client has two options. First, check the headers to decide whether downloading an update is necessary. Second, directly request a delta update without checking headers. In this example, the client always calls getDeltaLayerByTileId(), because it always requires the latest update regardless of what has changed. 

• Requesting a Delta: In the request for getDeltaLayerByTileId(), the client includes the requested tile ID and the details of the cached data layer version onto which the delta should be applied. This information comes from the smart layer header stored during the initial download. 

• Server Response: The server maps the request to the corresponding delta smart layer and returns it. If no update is available for the requested tile, the server returns a confirmation smart layer, which contains only header information indicating that all data layers remain at the same version, with DeltaEncodingType set to NO_UPDATE. 

• Applying the Delta: The client unpacks the delta smart layer and applies it to the cached version v1 of the data layer using the patch method defined in the data layer packaging (e.g., VCDIFF). The resulting complete data layer, now version v2 is stored in the local cache. 

• Updating the Header: The client then generates a new local smart layer header by combining the original header (h1) and the delta header (h2∆). This produces header h2, which is identical to what the client would receive if it called the getHeadersOnly() method. 

• Ready for Next Update: With the updated data layer and header in place, the client can efficiently request future delta updates as needed. 

Return full tiles instead of deltas

When you call getDeltaLayerByTileId, the server usually sends just the changes (deltas) for a data layer. Sometimes, however, it sends the entire layer instead. In that case, the layer’s update type is marked as NO_DELTA.

If this happens, the application simply replaces the old layer with the new one. The server might do this for a few reasons:

• The changes are almost as big—or even bigger—than the full layer.
• The server doesn’t have a delta available for the version you requested, often because too many updates have happened since the last one.

No delta found scenario

Sometimes, the client might not find a delta update at all. This can happen if the server only keeps deltas for a limited number of versions and doesn’t support sending the full data layer. In such cases, the server will return a “not found” error—like a 404 response in HTTP. When this happens, the client can simply call getLayerByTileId to download the latest full tile instead.

Delta updates offer a smart and efficient way to keep map data up to date without requiring clients to download entire tiles every time. By delivering only the changes between versions, they save bandwidth, speed up updates, and ensure near-real-time accuracy for map features. We’ve covered how smart layers are generated and versioned, how clients can apply delta patches, and what to do when no delta is available. Whether updating a single data layer or a full tile, the system is designed to provide flexibility while minimizing unnecessary downloads.

To explore more about delta updates for tile services and get detailed implementation guidance, visit the NDS Developer portal.

Back to news →