从GoogleMap的金字塔模型到无限级索引数据结构.docVIP

从GoogleMap的金字塔模型到无限级索引数据结构 作者：zcpzzy 文章来源：/zcpzzy 点击数：549 更新时间：2010-11-2 摘要：众所周知，现在很多网上的电子地图都使用矢量地图，用切图引擎切成栅格式的，存放与服务端，通过URL的方式访问，这对我们的GIS项目开发提供了一个非常好的地图来源，我们可以拥有自己的地图引擎，只要知道切好的栅格图排布规律，就可以在完美的展现。但是往往在做GIS项目的时候会遇到一个问题：有时候客户的机器并没有连接到互联网，或者有各种各样的问题，导致通过URL的方式访问地图速度会很慢，更有一个大的问题，有的地图供应商虽然开放免费的地图数据，但对访问次数上做了限制，比如说谷歌地图。由此就产生了众多的地图下载器下载地图。下载完的地图或者直接提供给客户，或者自架服务器来解除这种限制。但网上很多地图下载器虽然提供下载功能，但是却没有提供一个很好的数据结构来存储地图，由此我们引入这个话题。 众所周知，现在很多网上的电子地图都使用矢量地图，用切图引擎切成栅格式的，存放与服务端，通过URL的方式访问，这对我们的GIS项目开发提供了一个非常好的地图来源，我们可以拥有自己的地图引擎，只要知道切好的栅格图排布规律，就可以在完美的展现。但是往往在做GIS项目的时候会遇到一个问题：有时候客户的机器并没有连接到互联网，或者有各种各样的问题，导致通过URL的方式访问地图速度会很慢，更有一个大的问题，有的地图供应商虽然开放免费的地图数据，但对访问次数上做了限制，比如说谷歌地图。由此就产生了众多的地图下载器下载地图。下载完的地图或者直接提供给客户，或者自架服务器来解除这种限制。但网上很多地图下载器虽然提供下载功能，但是却没有提供一个很好的数据结构来存储地图，由此我们引入这个话题。 我毕业时就业于福州的一家GIS公司，有幸遇到一个很好的导师，我的部门经理，在那时我第一次接触到了Google地图的金字塔模型。这个数据模型就是目前我所使用的无限级索引数据结构的鼻祖，因为目前我已不再该公司工作，和朋友们一起出来创办了一家GPS行业的公司，所以在这里不对原公司所用的数据结构做太详细的分析。 所谓的金字塔模型，实际上是一个四叉树，每一个层级的节点个数是（2^n）^2个，层级索引从0开始计数，第0级为1个节点，通常可以视为根节点，第1级为(2^1)^2个节点即4个节点……以此类推。这刚好可以用来描述一个地图有规律的精细度区块划分。在第0级时，我们可以看到整个世界地图，在第1级的时候，每一张图片我们只能1/4的世界地图，在第2级的时候，就只能看到1/8了，如下图 显然，这种几何式增长的数据量用文件系统来存储的话是很不明智的。 既然有如此规律的排布，用一种带索引的数据文件来存储的话，是一个非常好的办法，我们只要知道每一张图片的唯一标识，就可以通过索引来找到它。从上图不难看出，层级编号和图片编号很自然地形成了一个唯一标识，在每一个层级中，图片的编号是唯一的，或者干脆说，在每一个层级中，这实际上就是一个行列式排布，由此我们的每一个层级中的图片就有了它们之间的大小关系，如此这般，我们就可以用二分查找的方式来找到我们所需要的那一张图片。 这就是初步金字塔模型，目前原有的公司可能还在沿用这这种模型，未经同意，我这里不做代码做分析。接下来会进一步讲到这个数据模型是如何进化成“无限级索引的数据结构”，届时将分享源代码，可能还有需要改进的地方，我们可以一起讨论。 最初的金字塔模型是分为两个文件进行存储，一个是索引文件，另外一个是纯粹的数据文件，索引文件存储了层级索引，以及图片单元索引，每一个索引的键值从小到大排序。层级索引存储了自身索引值以及图片单元索引在索引文件中的储位置（有点小绕口，那就再看一遍），数据单元索引存储了每个数据单元的索引值以及每一个数据单元在数据文件中的存储位置。 层级索引的元素格式是固定的，索引值从0到24，而图片单元索引的元素个数是不固定的，这种设计很有针对性。为GoogleMap的层级准备25个层级来存储已经是绰绰有余了，而每一个层级中的图片单元个数不固定的原因也很简单：并不是所有区域都有任意等级的图片单元。 如图所示： 这样的具有针对性的数据结构在按顺序写入和查询图片单元上性能得到了最大化，但在需要修改、插入、删除时就显得有些疲惫了。 1.没有一个文件空间的复用机制，导致在频繁的修改过程中，数据文件变得庞大。 2.双文件存储的特点导致在使用时需要打开2个文件句柄，查询到图片单元进行读取的时候增加了磁盘寻道时间，使用的时候也不是很方便。 3.使用文件流进行数据访问，导致在存储数据量大的时候，打开和关闭文件时速度变慢，同时两个程序在修改文件时，很难保证数据完整性。 在了解现有的