目前，导航产品已经被人们广泛使用，其中，便捷的POI检索、最优路径规划、智能语音引导、3D地图等功能给人们的日常出行带来了诸多便利。在之前的新知栏目中，我们已经或多或少地介绍过一些地图采集制作的流程和方法，但是新鲜出炉的地图数据可以直接装载到导航产品上供大家使用吗？答案是否定的！想要把统一格式的地图数据分别支持不同的用户使用，这中间还需要经过一个非常关键的环节，那就是地图编译。那么什么是地图编译呢？为什么需要编译环节？导航圈内经常提到的NDS格式又是什么？地图编译经历了什么样的发展历程，现今又处在一个什么样的阶段呢？本文带你一探究竟。
现如今，导航软件对于驾驶者的重要性不言而喻，尤其当行驶在陌生路段，导航提供的引导信息尤为重要。为了对现实世界尽可能完整准确地体现，图商收集和制作的地图数据往往是非常充实但又繁琐复杂的，而对于储存空间和处理能力有限的汽车车机来说，这些内容是无法直接照单全收的。同时，不同的图商提供的地图数据往往都基于不同的物理储存格式，有时候还需要加入来自于第三方的补充内容，而不同导航软件对其导航功能的设计也千差万别。所以，为了适配相应的导航软件，原始的地图数据需要经过地图编译这个环节才能最终被导航使用。在这个过程中，原始的地图数据和其他的补充内容会经过重新组织，去除冗余，并按照不同的需求压缩成各种储存格式，以适应不同平台不同客户的装载使用要求。
导航电子地图产品的编译，是为了满足不同搭载平台的格式需求，但同时也是对导航电子地图产品进行版权保护的必要过程。因此，在过去的市场上，各企业一般都自行定义存储格式，导致市场上的导航产品格式种类繁多。随着城市经济建设的迅猛发展，城市道路日新月异，为了能准确的反映快节奏的城市变化，装载在导航中的地图数据也必须定期更新。然而五花八门的地图格式导致本身就很复杂的地图更新工程变得更加庞大。同时，互不兼容的数据格式导致车厂的导航切换灵活度很低、成本很高。因此，综合以上几点原因，国内外专家启动了新一代可以支持增量更新的导航电子地图存储标准的研究，而其中比较有影响力的是创立于欧洲的NDS。
NDS的全称是Navigation Data Standard（导航数据标准），是一种导航数据标准格式，NDS的设计使其在数据更新、数据安全度、数据可靠性上拥有一定的优势，所以普遍应用于车规级导航产品，由位于德国的NDS协会制定和维护。该协会成立于2009年，其成员涵盖汽车制造商、系统集成商、地图提供商、服务提供商等。NDS协会希望打造一种标准化的导航数据化格式，从而使得导航数据可以和导航软件分离，导航数据可以兼容于不同导航系统。
第一个基于NDS的导航产品于2012年正式上市，并应用于宝马，戴姆勒奔驰和大众的车型中。截止目前，NDS协会已拥有来自北美、EMEA、APEC的超过40多个会员企业。而地图标注在协会成立之初，就已经加入NDS协会，并且一直是协会的技术合作伙伴，积极参与了各个user case的开发和研究。
一份NDS数据可以称为是一个Database（数据库），它是通过NDS协会发布的NDS数据规格所规范好的标准数据库。这意味着，只要按照这个标准规格去生产NDS数据，得到的数据格式将是一致的。一个NDS Database可由多个Product Database（产品数据库）组成，这些Product Database可以来自不同的数据供应商，并且可以进行独立的版本控制和版本更新。每一个Product Database都可以被进一步的划分成多个Update Region（更新区域），顾名思义，它代表数据库中进行数据更新的地理范围。
举例来说，Product Database “Europe Basic Navigation（欧洲基础导航）”中每个欧洲国家便可由一个单独的Update Region来代表，比如法国更新区域、德国更新区域等。这样的结构使得NDS的数据库变得灵活且支持版本迭代，同时支持不同格式的数据库转换成为统一的NDS数据格式，从而使得不同导航系统间数据可以兼容及任意交换。
在NDS数据库中，所有的导航数据都会按照不同的功能，被组织成一个个的Building Block（结构单元）。Building Block的Type（类型）定义了储存在其中的数据的功能，为了满足不同的使用场景，导航应用需要对不同Type的Building Block进行过滤和组合，比如，需要计算一条路径并显示在车机屏幕上，就需要同时调用Routing（算路）和Basic Map Display（地图显示）这两个Building Block。
下面的图片就非常直观地体现了我们在使用车机导航时都使用到了哪些Building Block：
图为：NDS数据库中的Building Block
在某些Building Block比如Basic Map Display（地图显示）、Routing（算路）、Trafficinformation(交通信息)等中，数据会被分割成不同的Level（层）。根据Type的不同，一个building block最多可以有16个level。Level越高，数据所包含的空间范围越大，其中所包含的数据复杂程度越低，数据量越小；而Level越低，数据的复杂程度越高，可以体现的细节也越多，数据量也相应地会更大。在实际的应用中，Level的概念可以理解为比例尺，随着比例尺的变化，地理要素会被综合，次重要的要素将被过滤掉。引入这种分层结构的优点在于，在地图显示和路径规划过程中，由于高Level的数据过滤掉了不必要的细节，从而提升了地图显示的效率，也加快了地图规划结果。
每个Level的数据被划分为相同大小且没有重叠的正方形网格，称之为Tile(网格），这些Tile通常用于数据访问，及根据其地理位置确定与其相关的数据内容。在现实情况中，这些数据的内容比如道路的形状、名称、拓扑连接关系、交通限制信息等发生变化的时候，就需要对地图数据进行更新。此时，NDS数据库可以根据该要素的地理位置，很快检索到相应的Tile，然后对该Tile进行替换。
NDS的编译流程大同小异，在这里我们以地图标注NDS编译团队的生产流程为例（如图所示）为大家做一个阐述。
首先，我们通常会把需要进行编译的原始数据分为两大类：核心数据（input data）和辅助数据（side data）。核心数据通常指的是变化概率比较大、需要经常更新的数据，如路网、POI等；辅助数据则指的是状态比较稳定、不需要经常更新的数据，比如卫星影像、数字地形模型、世界边界图、等高线图等。这部分数据经过预处理后保存起来，留作备用。而核心数据则会先经过前端编译转换成为dHives（地图标注自定义的一种中间数据库格式）。
然后，根据项目的需求，对dHives优化、纠正、去重和删减等不同程度的深加工。
随后，加工后的核心数据将会连同预处理之后的辅助数据一起经过后端编译器，并根据与客户和导航应用程序提供商事先达成的规范，将其编译到NDS数据库中。
最后，再根据客户的要求添加一些特定的数据和配置信息，比如OME经销商信息等，一份完整的NDS数据包便“整装待发”了。
对于地图来说，不管是最终在车机、手机或者其他任何平台使用，一旦出品都需要经过编译。只是针对车载格式的会更加严格，尤其是NDS因为是标准格式且都是车厂采用，所以复杂度较高。
而对于汽车来说，随着自动驾驶时代的走近，汽车功能也在发生着翻天覆地的变化，NDS技术也在随着技术的迭代而不断更新适应。本篇内容我们主要带大家了解了一下编译的重要性以及NDS编译的基本流程方法，下期，我们会针对NDS技术的发展趋势进行进一步解读，尽请期待吧！
