What is NDS? NDS.Live Join Us News & Updates Contact

Nine Conceptual Differences between NDS.Live and NDS.Classic

24. October 2024

We have already discussed our two standards NDS.Classic and NDS.Live several times in our blog. Logical, because after all, they are the heart of the NDS Association. Today, however, we would like to take a closer look at nine conceptual differences between the two. The focus here is on very specific questions that the developer community keeps asking us. So let’s go!

As we all know, NDS.Live and NDS.Classic are both standards developed by theNDS Association, to provide a framework for storing and exchanging digital map data used in navigation systems and other in-vehicle technology. The key difference between the two lies in their design and approach to handling and delivering map data, with NDS.Live being the more modern, cloud-based solution, while NDS.Classic is the older, more static, device-based format.

NDS.Live offers significant advantages over NDS.Classic for navigation development purposes due to its cloud-native approach, real-time capabilities, scalability, and flexibility in data handling. It aligns more closely with current and future trends in connected navigation systems and is better suited for applications requiring dynamic updates, real-time processing, and seamless integration with other cloud-based services. Read on to find out about some of the conceptual differences.

NDS.Live and NDS.Classic are both standards developed by theNDS Association. In this blogpost you can read about differences between the two that have been collected based on frequently asked questions.
Source: Bing AI

    The road model and the lane model in NDS.Live are independent from each other. In NDS.Classic, a lane group is a flexible attribute that is assigned to a link, but in NDS.Live lanes and lane groups are independent features. There is no direct way to refer from the road model to the lane model, and vice versa. One of the biggest challenges in NDS.Classic is to map road attributes to lanes. In NDS.Live, all attributes can be assigned to roads as well as lanes. Therefore, no mapping is required. Lane coverage is often incomplete in the source data, that is, HD and SD map have different coverage or the SD model has limited lane information. As a result, lane data is not available everywhere in the NDS lane model. To avoid having to switch back to the road model in areas with missing lane data, NDS.Live provides artificial lane groups. They allow to stay within the lane model for all relevant use cases.

    One of the biggest challenges in NDS.Classic is to map road attributes to lanes. In NDS.Live, all attributes can be assigned to roads as well as lanes.
    Source: Open AI

      In NDS.Live, tiles are fully self-contained. There are no references between adjacent tiles or tiles on different levels. That way, avalanche effects during updates can be avoided, which can happen with NDS.Classic. To connect road and lane topology between adjacent tiles, NDS.Live provides artificial intersections. These intersections are placed on the tile border between adjacent tiles and are duplicated in adjacent tiles at the same position. Applications stitch together roads across tile borders based on the coordinates of the intersection. At lane level, the same is achieved using lane group connectors. Connected lane groups share the position of their lane group connectors on the tile border. In addition, special border lane groups are introduced to support lane connectivity across tile borders.

        NDS.Classic provides explicit upward and downward references to connect links on different levels. Upward references are used for route calculation, downward references to level 13 are required for route guidance. Instead of explicit references, NDS.Live uses intersection positions to connect roads across different levels. These positions act as virtual upward and downward references. The application can create virtual upward and downward references by relating all intersections that have the same position on different levels. If a merge history for the references is required, it can be stored in a custom layer.

        In NDS.Classic, the position of each intersection must be read from the corresponding intersection feature and be added to the shape points of a link or road geometry line for rendering and attribution. In NDS.Live, the position of an intersection is also stored in the relevant road geometries and is independent of the position of the corresponding intersection feature. That way the coordinates of intersection features can be kept stable across a map’s lifetime to ensure stability and connectivity across tiles because the intersections are irrelevant for road geometry usage. If the road shape changes, the intersection position only needs to be changed in the geometries of the connected roads and the topology remains stable.

        NDS.Live separates attributes that can be assigned to a position on a feature from attributes that can be assigned to ranges on a feature, for example, a road, lane, or display line. The schema enforces this using separate attribute maps with their own validities. This approach simplifies the definition of validities and leaves less room for interpretation than the NDS.Classic specification.

        NDS.Live clearly distinguishes attributes from attribute properties and conditions. Attribute properties extend attributes in a specific way, while conditions define under which circumstances an attribute is valid. All secondary flexible attributes from NDS.Classic are represented as attribute properties or conditions. Conditions are globally applicable to all attributes unless specified otherwise in a dedicated rule. Attribute properties are either defined globally in the Core module or locally in a specific module. Global attribute properties can be used with any attribute while local attribute properties are only available for the attributes from the same module. Further restrictions are imposed using dedicated rules, for example, if an attribute property shall only be used with a specific attribute.

        The schema does not prescribe which coordinate shift is used to reduce coordinate resolution. In NDS.Classic the addressable coordinate resolution is tied to the level on which the coordinate is used. NDS.Live keeps the tile sizes and tile boundaries of NDS.Classic, but within tiles the coordinate shift and resolution can freely be chosen, although the shift should be the same in all tiles on the same level.

        In NDS.Classic, links on level 13 are mandatory, but NDS.Live does not have such a requirement. Every application shall be able to determine which levels are available from the metadata of a service and support processing the features from that level. There are no differences between the levels in terms of attributes that can be assigned to a feature nor any other restriction.

        In NDS.Classic, the flexible attribute ROAD_AREA is not designed to overlap with the space of a lane. In NDS.Live, road surfaces can be modeled completely independently without information from the lane layer. Because of that, road surfaces can overlap with lanes and are intended to do so. Road surfaces can also overlap if they are of different types, for example, a pedestrian crossing can overlap a drivable surface. Road areas can be modeled with or without holes, as required. Road surfaces are modeled as 3D polygon meshes instead of simple polygons. Therefore, they can be used to very precisely model any surface.

        Would you like to find out more?

        In the NDS.Live Developer Portal you can read about more conceptual differences between NDS.Live and NDS.Classic.

        Back to news →