整体结构

介绍下Navigation Data Standard (so-called NDS databases)的架构，和其最重要的一些概念。,

1，NDS Database and its Interfaces

     NDS的数据可以称为是一个database，是被其标准文档所规范好的标准database。作为一个标准化的database，也就是你生产出来的NDS和别人生产出来的NDS，数据格式是一致的，具体而言，符合这个标准的application，完全可以在所有的NDS数据上面毫无压力的运行。

    NDS的数据还有个特点，就是可以在多个不同内容的数据上同时的运行。比如，在硬盘上有完整的路网数据，同时在flash card上有POI的数据，你的application可以在运行的时候，同时加载这2个数据，你的application会在逻辑上把这2个数据当成一个完整的逻辑database。（在以后的网格划分的时候可以看到NDS是如何实现这点的。它用一个全球统一的网格划分方法，来分隔数据，这样保证你很容易把不同的来源的NDS数据，通过网格重叠在一起。）

   NDS的数据文件存储于SQLite file format v3( http://www.sqlite.org/fileformat2.html), 字符编码为UTF-8。

2，NDS Database Structure

    一个NDS的database由多个product database组成，每个product database又可以进一步分出多个update region。这样做的好处就是，可以通过不同的数据供应商来提供不同的数据内容，然后你把他们都整合成一个逻辑上统一的NDS database。

   NDS数据再往下分，就是一个update region又由building blocks来组成，一个block就是某个level的某种类型的数据。

   2.1 Product Database

    一个product database就是由一个数据供应商发布的，有自己的版本控制。并且一个product database可以单独进行数据更新，和其他product databse无关。一个product database描述了一个地理上的区域，它可以进一步的划分成多个update region。

   举例来说：  一个欧洲的 NDS database数据包含2个product database：

                         ■ Europe basic navigation （包括 the Basic Map Display, Routing and Name building blocks，有Harman公司提供）.
                         ■ Europe POIs（由 Michelin公司提供）

    2.2 Update Region

     update region,看名字就知道，它是一个在地图数据在更新的时候单位。就是地图会按地理位置切分成一个个update region。数据增加和更新的时候就以此为基准。

     一个update region描述了一个地理上的区域。2个update region在地理上如果是相接壤，在边界上就会定义些重叠的点（后面会讲到就是gateways），但是update region的内容本身是独立描述的。也就是说update region只是描述自己范围的所有内容，不在其范围内的内容是不描述的。（但是在路径规划的时候如何做到跨region，就是通过gateways，一个region的边界上的点，会定义自己为一个gateways，并且仅此为止。application通过gateways id，到product date里面去找这个gateways id的相关信息，可以得到另一个region的边界点是同一个gateways id，从而跨region探索。）

   2.3  Building Block

   导航地图数据按不同的功能，被组织成一个个building block。每个building block存储了自己特定功能的内容，这个内容由 NDS标准所规定。比如 name building block里面存储的都是名字（城市名，道路名等等），routing building block包含了路网数据，poi building block包含了POI的数据。

    building block的组织更倾向于如何让数据更有效的被访问，而不是为了逻辑上继承。所以对一些应用，在数据看来上并不是很直接。应用程序在开发应用的时候需要自己创建一些逻辑视图，这些逻辑视图的内容来源于不同的building blocks，通过join和filter来达到目的。

      building block types and categories：

    categories上分为2个类别：core building blcok（核心） 和 supplementary building block（辅助）。通过名字我们也知道， 核心building block是必须的，辅助building block可有可无，并且辅助building block必须和核心building blcok一起发布，你不能独立发布一个辅助building block。一个NDS的produc database必须包含至少一个核心building block。

   type上按照功能来分，如名字，图标等等。下面的表列出出了各种type和其对应的category。

   Building Block Instances in Update Regions：

   一个update region包含了多个building block。在一个product database里面，又包含了多个update region，所以对某种type的building blcok会有好几个。我们会对每个building block赋予一个唯一的id。update region id+building block id能够表达唯一的building block。

   2.4 Levels

    某些building block，其包含的数据内容是分层组织的。level越高，数据的空间范围越大，size越小，内容也越疏。需要说明的是，数据分层是统一规划，用于显示的数据和用于路径规划的数据，它们是按照相同的网格定义来分层。同一个level的所有类型的building block，其表示的网格（NDS称为 tile）的面积是相同的。

       数据分层主要针对的是routing和basic map display。越是底层的数据，数据量越多，也越详细。通过过滤掉一些不重要的feature，减少数据量，把数据抽到高层。这个过程不断重复，得到更高的层。可以看出，高层的数据总是底层数据的冗余。这个过程有编译数据的时候完成。

       引入分层的目的，或者说好处：

      * 对于map display， 使用高层的数据，可以用很少量的数据就覆盖了大片的区域，地图的绘制会更快，虽然会减少很多细节，但是不会影响用户的使用。

      * 对长距离的route，使用高层数据，可以快速的得到规划的路径，当然，得到的路径主要有些重要道路组成，因为不重要的道路在分层的时候被过滤掉了。（所以在分层的时候，可以通过连通性的检查，把那些虽然不是很重要，但是连通性好的路也要保留在高层中。如何分层留给以后会再谈要如何做到这点。）

      在NDS中，我们把地图按比例分为16层（有16个level，具体分层细节以后会讲到，本人对NDS的分层定义极为认可。）。很多level都是给map display用的，并不是所有的level的数据都必须提供，比如 level 14和level 15在display building block很多时候就不提供，确实没有这么多地图细节要呈现给用户，但是留给以后扩展，NDS还是考虑的未来的需求。routing对应的level有特殊规定，即routing最多只能提供5种level， 分别是 L13，L10，L8，L6和L4。其中level 13为routing building block强制需要的，表示最详细的一层路网数据。（题外话，好像如果你提供其他level的routing数据，比如L11，好像engine逻辑上也不会有问题，一个level本身的定义是没有歧义的，但是NDS文档都声明了L13的上层路网数据就是L10。）

      在每个level，会按相同大小的网格分隔成tile，每个level的tile都能够完全覆盖整个地球（一个tile就是一个经度和纬度一样长的面积，当level固定的时候，这个level的tile的经纬度长度就是固定的）。tile用于方便的访问数据，根据一个地理坐标，我们就可以快速的定位到这个坐标点在那个tile。

      额外说明下，NDS的level和tile的概念非常值得大家学习，以后会专门介绍。

3 Database Content

       我们按类型把数据分成3个大类：

      ■Features: 与导航相关的，所以现实世界存在的对象，就叫feature。一句话，feature是具体的一个对象，看得见摸得着。
      ■Attributes: 属性就是附着在features上面，它一定是某个features的属性。
      ■Metadata: 这是个描述数据库的辅助信息，它是针对product data，building block或者整个datebase的描述。也就是说这块信息不会针对某个具体的feature来描述，针对feature的描述叫attribute，针对数据块来描述就是metadata。

    3.1 Features

      现实世界的一个对象会对应到一个或者多个feature。比如，一条道路就是一个存储于routing building blok里面的link feature，一座山的山顶就是Basic map display bulding block里的point feature，一个城市就是在name building block里面的administrative area name feature，一个旅店就是在poi building block里的 poi feature。

         Features class

      现实世界的对象都会在NDS database对应到一个或者多个feature实例。比如，一条道路有名字，有多个连接点，其中道路名表示为name feature，这条道路表示成link feature。

     NDS对feature也定义了些abstract class（抽象类别），这些abstract class是不可以被实例化或者具体化，往下细分就是些具体的class，这些class可以被实例化。（感觉这几话就是废话，就是对feature做了下归类。解释起来，看下面这个图，routing feature这排就是抽象类别，一个道理相关的对象的总称，往下的links，interesection这几个feature才是对应到现实世界具体的对象。理解下概念就行）

    想了解各个feature的具体含义，到各个building block章节里面具体细谈。

       Feature Structre

      一个feature的具体组成，包含：

       * attribute，feature对应的属性，描述了这个feature所具有的性质或特点。（attribute章节将详细说明）

       * Reference，对另一个feature的引用。reference就是feature与feature之间的依赖关系，reference可以存在于相同feature class之间，不同feature class之间，同一个building block之间，不同的building block之间，甚至不同的level之间也可以有reference。

      Idengtifying Features 唯一识别一个feature

       一个feature必须能够唯一的识别出来，就如用身份证来识别一个公民。它用于

       *-- 应用程序访问一个feature的时候

       *-- feature之间引用的时候

      在识别一个feature的时候，NDS定义了一个完整的ID来描述一个feature。但是考虑到数据大小，不同的building block在识别feature的时候有不同的方法，或者说用到了不同的压缩方法来存储 feature ID。一个完整的feature ID由下面3个部分组成：

          1， tileId: 用于定位feature存储在那个tile里面。一个tileId由level number和tile number组成。如果我们可用从上下文中明确这个feature的tileId，这样在当我们引用一个feature的时候，可用不用指明tileId。（关于tileId的详细内容，在数据分层和网格划分的时候具体谈及）

          2，ClassID：定义了feature所属于的类别，这个概念比较抽象，并且大部分在引用feature时也不指明这个feature的类别。因为feature的类别在引用的时候很多情况都是不言自明的。比如link会引用到它的2个intersection，在存储intersection的时候，我们是不会把intersection的类别显示的存储起来，我们也就存下intersection的localindex，至于它的类别，毫无疑问就是intersection，不会是其他。

          3，LocalIndex：在给定的tile下的，给定的class下的，一个唯一的标示号。一般而言，就是featurelist的下标。

 要识别一个完整的feature，上面3个就可以唯一的定位到一个feature。但是在实际的存储过程中，tileId和classId都不会存储，因为大部分情况下这2个id总是显而易见，不言自明，毫无歧义，所以在引用一个feature，很多情况就记录下localindex就可以，这样也可以达到减少数据size的目的。      

     Referencing Feature

    NDS定义了以下情况需要引用一个feature

    *在不同的building block间引用feature：比如，routing building block的link引用到name building block的name，为现实中的道路附上路名。

    *在相同的building block但是不同的level间引用feature：比如，routing building block的一条lower level link关联到一条upper level link，这个引用为路径规划的时候提供跳层提供依据。

    *在不同的tiles间引用feature：比如，link引用对应的geometry line来表示自己的形状。这时候geometry line有可能和link存储于不用的tile。

    *在相同的tiles间引用feature：比如，link所有连接的2个intersection，它们一般会存储在同一tile

3.2 Attribute

    attribute描述了不同feature的细节。对每个feature class，都提供了一系列的attribute type。NDS提供了2种attribute：fixed和flexible。对于fixed attribute，当feature实例化的时候，其fixed attribute的值必须提供。而对应flexible attribute，这种属性是可选的，它的组织方式为attribute group形式（以后会详细讲解attribute group model）。

3.3 Metadata

      metadata包含了一些变化的数据内容，这部分数据帮助应用程序适应不同的情况。NDS区分出2种类型的metadata：

       * Global metadata：通过名字我们就知道，global metadata类似于全局的数据信息，它关联到多个甚至所有的building blocks。通过使用global metadata的信息，应用程序能够使自己适用于特定的databa。global metadata的信息可以定义为 在一个product适用，或者一个 update region， 或者一个行政区域里面，甚至可以作为common metadata定义于几个building blocks里面适用。

       * metadata specific to a building block：对某一个特定的building block适合的metadata信息

3.4 Introduciton to NDS DataScript

       DataScript是一种描述二进制数据，bit流或者文件格式的形式语言。NDS的数据存储格式就是由DataScript来定义和描述。如果你用datascript描述好你定义的数据格式，它可以自动生成encoder和decoder（就是写数据的代码和读数据的代码，目前可以提供c++或者java代码）。这样开发人员就不需要考虑数据的序列化问题，人可以转而专注于应用程序的逻辑。

参考文档：

■http://people.cs.vt.edu/~gback/papers/gback-datascript-gpce2002.pdf
■http://datascript.berlios.de/DataScriptLanguageOverview.pdf
■http://datascript.berlios.de/
■http://datascript.sourceforge.net/
■http://en.wikipedia.org/wiki/Endianness
■http://en.wikipedia.org/wiki/Two%27s_complement