In the second part of our article series on NDS.Live, we have established that NDS.Live breaks down map data into bite-sized chunks that can be easily and quickly shared, updated, and pieced together to form one precise model of the roads and their environment. This well-designed structure and granular categorization lay the foundation for a distributed ecosystem of map data providers.
The key advantage of an open standard like NDS.Live is that map data can be spread among different services, even originating from different suppliers. To make this work, NDS.Live is focused on service interfaces which deliver not only map data, but also all related information necessary to correctly filter and use it. The services implementing these interfaces may reside anywhere, in the car, in the cloud, etc. The format does not specify where and how exactly map data should be stored. Instead, it defines how it has to be delivered from one participant in the ecosystem to the other.
For this purpose, NDS.Live describes service interfaces using the schema language zserio, an open-source interface definition language. The schema defines the exact data layout of each request and response within the system. Thereby, interoperability on the interface level is reached. NDS.Live does not specify a physical storage format for the map data, such as a file format. It is left to each node in the NDS.Live ecosystem to persist data in a way that best suits its requirements, optimizing storage based on the environment it is running on (embedded, cloud, etc.). This gives map and traffic data providers an unprecedented amount of flexibility with regard to managing and deploying their data. Developers of navigation and HAD systems as well as carmakers enjoy the possibility to combine the best data sources into a solution that delivers an optimal driving experience to their clients. And last but not least, it carries forward the tradition of NDS’ interoperability – a major advantage over proprietary formats.
Any networked system is made up of nodes, which provide connection endpoints from a client (e.g. a vehicle) perspective. Each endpoint is reachable under a certain physical address, under which a client may access an arbitrary service running on the node.
A trivial system might provide an infrastructure where each node is directly associated with a specific service. For example, there might be three nodes, one strictly serving map display data, another one for road network data, and a third one for live traffic data. However, this is not desirable for multiple reasons:
NDS.Live is designed with opposite qualities in mind:
Let’s look into some more details on how NDS.Live is taking up the challenge to achieve these qualities so that sharing data becomes easier. Among definitions of online electronic horizon, routing or search services, the following three concepts carry most of the load:
In this structure, you can recognize several principles known from the internet, such as the concept of registries or the modularization of content. Even more important is the ability to adapt to new sources of information, new kinds of content and new use cases. In our next blog article, we will discuss how exactly NDS.Live data employs modules, registries and SmartLayers to form a true internet of map data.Back to news →