NDS.Live: Finding the best map data structure

As we have learned in our introduction post on NDS.Live, it is being developed with one goal in mind: Enable vehicles to access the most current and precise map data where they need it, when they need it. Nowadays, map data moves from in-car storage to the cloud and to distributed systems like V2X. This means that the relevant data can be processed on high-performance computers with far more power than in-car systems. Vehicles can then consume the data as needed – downloaded or streamed. But of course, they cannot download a full map every few minutes just because the weather has changed. So we need to find a compartmentalized map data structure, breaking the map up into bite-sized chunks that can be streamed quickly and without straining the cellular network.

Now, does this mean map data should be fully online rather than stored in the vehicle? Not at all: We, the NDS Association members, believe that some data is better kept in the vehicle. This way, we ensure those systems that need data at all times are not dependent on a working data connection.

In a nutshell, NDS.Live gives us the best of both worlds: Map data stored in the vehicle enables basic functionalities at all times. This system is complemented by any up-to-date, detailed information the various driver assistance, automated driving or infotainment systems need.

However, the question remains: How do we structure such amazingly complex, highly detailed data? How do we make sure that every point of data is updated as often as needed to ensure it’s reflecting reality but as seldom as possible to save on data transfer?

For the NDS.Live map data structure, we considered different requirements concerning the recency of data and different update frequencies for various types of data. Speed limits and warning signs, for example, can be dynamic and change many times per day, and so do parking spaces or EV charging availability. Therefore, this data must be updated with high frequency. Then there is data that changes more often but not daily, such as POI data. A third type of data rarely changes, like the digital terrain model or 3D landmarks, for which a slower update frequency is sufficient.

Data Lifetime and Reception

Data lifetime is one way to categorize map information in an advanced map format. The other one is data reception, which basically means distributing the data on a “need to know”-basis. Let us look how NDS.Live understands these categories:

Lifetime determines when and for how long data can be considered valid and useful. It provides the answer to the question: “How long will the data be valid?” The concept of NDS.Live includes three main lifetime, or “freshness”, types:

• Static lifetime: Data that stays valid for long periods of time, with typically only small fractions changing over time. This is what classic map data is about.
• Dynamic lifetime: Variable data with a limited temporal validity of days or even hours. Age checks must be used to determine if the dynamic information can be applied.
• Live lifetime: Short-lived data with momentary validity. For example, such data may be a vehicle’s state or electronic horizon, a route, or a search result. Applications either use it right away or discard it.

The reception aspect answers the question:“Who is this data for?”
NDS.Live defines three types of data for this category:

• Universal reception: Data that is generally relevant for all road users, such as the road network.
• Collective reception: Data is relevant to a specific group of road users. Examples for this are vehicle classes (cars vs trucks) and engine types (electric vs fuel based).
• Individual reception: For specific road users, data can be generated or bundled based on individual requests, for example points of interest along a specific route.

Although the name “NDS.Live” sounds like the focus is on live data, it will cover all the lifetime and permanence types described here as well. The following table shows data reception and lifetime types for a variety of use cases:

This matrix allows for a very precise categorization of data and for a clean map data structure in NDS.Live. This easy compartmentalization is so important because NDS.Live is not a monolithic database. It is a distributed ecosystem of map data providers, which means that vehicles can pull data from different providers and merge it into a very precise, high-definition model of the world around them.

We will discuss exactly how this is done in our next blog article.