CN106682110B

CN106682110B - 一种基于哈希格网索引的影像文件存储和管理***及方法

Info

Publication number: CN106682110B
Application number: CN201611108581.6A
Authority: CN
Inventors: 高福东; 赵齐兵
Original assignee: Beijing Aerospace Space View Information Technology Co Ltd
Current assignee: Beijing Aerospace Space View Information Technology Co Ltd
Priority date: 2016-12-06
Filing date: 2016-12-06
Publication date: 2020-03-17
Anticipated expiration: 2036-12-06
Also published as: CN106682110A

Abstract

本发明公开了一种基于哈希格网索引的影像文件存储和管理***，包括：文件头，用于RPF的文件信息的管理；分包存储模块，用于解决索引冗余；分区模块，用于将分包集中在一个数据文件；哈希格网索引模块，用于实现O(1)时间效率的瓦片增删改查，减少空间数据的碰撞。本发明的有益效果：通过静态哈希技术，克服了哈希索引的一般缺点，利用局部冗余的瓦片哈希索引，以有限的稀疏空间换取常数时间，即单瓦片的定位时间不随瓦片数据增加而增加，特别是对于效率要求很高的影像瓦片存取。有效的支持在哈希域上的范围查询、部分匹配查询操作，具有动态添加的能力，瓦片的大规模增加、删除，不会导致哈希表的重整。

Description

一种基于哈希格网索引的影像文件存储和管理***及方法

技术领域

本发明涉及海量影像数据文件高效存储和管理技术领域，具体来说涉及一种基于哈希格网索引的影像文件***及方法。

背景技术

全国、全世界范围内的高分辨率卫星遥感影像，已达到PB级的数据量，数据日益更新，分辨率不断增长。采用金字塔瓦片方式( 1)( 2)( 3)(4 )(5 )管理影像，对地图服务的快速加载显示具有必要性。在国内外互联网如Google、Bing、百度、搜狐等企业，普遍得到使用。如今卫星遥感影像早已达到0.5米更高分辨率，省市影像金字塔瓦片达到千万量级，全中国超过８亿张。

全球影像金字塔的瓦片数据，一般存储在外存，目前主要有以下存储形式：瓦片文件目录、瓦片包；通用数据库、空间数据库、分布式数据库建索引保存。在研究中，格网索引也是常见的方法。以B-tree为代表的树状索引，最佳效率为O(㏑(n))，对于解决如此规模的影像金字塔存取，通常要付出数十次比较和内存随机寻址代价，效率已不能很好满足要求。

1.瓦片文件目录

瓦片零碎文件用不同目录存放时，是依靠操作***文件***获取，定位到一张瓦片的时间效率是依赖于文件***目录(Directory)的实现，Windows NTFS、Linux ext3以下比较旧的实现往往是线性表结构，一般时间复杂度是O(n) (n = directory size)，比较新的实现是B-tree结构，一般时间复杂度是O(㏑(n))。

2.瓦片包

国内外的互联网地图厂商、GIS企业,如Google、ESRI、SuperMap通过量身定制的瓦片打包，并通过快速的索引方式，能避免瓦片文件目录的缺点，提供比操作***文件***高的效率，但还达不到常量级时间效率。

Google KFF (Keyhole Flat File) Database，采用四叉树索引数据包(QuadTreepacket)机制，不仅管理栅格，还有矢量。ArcGIS File Geodatabase按OGC标准的Feature数据集管理空间数据，每个数据集是一个独立的文件。SuperMap缓存包在文件***的瓦片行目录下打包，整个操作模式包括读写算法不算高效。

3.通用数据库

对影像瓦片使用hash索引，可将单个瓦片数据读写的时间复杂度优化到O(1)。然而使用现有通用数据库的哈希索引来存取影像，存在不可克服的困难：

动态哈希的缺点。通用数据库一般采用动态哈希算法实现，存放瓦片数据，会打乱瓦片的号码顺序和空间关系，不再能使用范围查询、部分匹配查询，如某区域内一系列影像是否存在等操作。当***删除系列瓦片时，动态哈希算法通常会重整少量瓦片位置，效率不稳定。

不够轻量级，无法给数据用户一个重量级的瓦片数据库，作为数据包提交，无法在手机平台将它作为离线数据包，无法在一个轻量级的项目中使用。

当存储影像元信息时，很难用表单来容纳，索引的冗余很难消除，灵活性远不如一般的定制数据包。

4.空间数据库

空间索引不仅是解决矢量问题的关键技术，而且也是解决海量影像存取的关键技术。现有的空间索引技术主要有基于二叉树、四叉树、B树、空间目标排序、哈希等方向。业界普遍认同的主流空间数据库一般采用树状索引结构，除扩展B-tree的R-tree外大体继承了通用的索引结构。

因此，用现有的空间数据库解决影像存储问题，问题与通用数据库相同。

5.分布式数据库

互联网分布式技术的发展，Google Earth研发流行的BigTable来做存储，一些互联网公司开发分布式文件***来存储图片等资源。主流实现仍然是B-tree，达不到Hash算法的效率；要么就是动态哈希算法，其算法实现无法解决范围查询、部分匹配查询等问题。

6. 基于动态哈希的格网索引

格网索引的机制是：将空间按一定的规则划分成格网，并记录每一格网内包含的空间对象。散列方式的选择，对格网索引的最终表现是至关重要的，甚至决定了格网索引作为一个整体走向实用的根基。格网索引在不使用哈希时，由于空间划分的灵活度较差，通常是一种相对于KDB-tree、Quad tree、R-tree、Cell-tree低效的算法。常用的哈希方法(25)包括静态哈希、可扩展哈希、线性哈希、螺旋哈希等。后三者属于动态哈希。

基于动态哈希格网法的空间索引技术，包括Grid File及其变体BANG File、TwinGrid File、Multilevel Grid File、Generalized Grid File、R-file、PLOP-Hashing、Excell、Buddy-Tree、改进A树的G树等。它们共同面对的客观现实是内存空间的有限性，需大力减少冗余，提升空间利用率。

Grid file为了解决此问题，放弃位图法，而引入动态的网格目录(Griddirectory)，采用矩形的区域存储多个两两不相交的网格单元，每一网格单元包含一外存页的地址，为数据页(Data page)，超出桶容量时***数据页。主要问题是空间维数较高或数据量较多时，网格目录将非常庞大，每一次***，都要增加很多。而且往往存储在外存，对其的存取操作耗时，区域查询效率较低。

BANG File引入平衡树来管理用均等二分法***的格网目录，使格网目录膨胀、存取操作减少，Twin Grid File通过静态、动态的孪生Grid File提升空间利用率,Multilevel Grid File通过多格网层级改善目录管理，R-file类似于BANG File,单元格重复二等分直至得到包围空间目标的最小单元，从而使目录紧凑,Buddy-Tree使网格单元尽量小,Generalized Grid File兼容单属性查询。PLOP-Hashing、Excell旨在通过线性哈希、可扩展哈希使索引空间的增长缓慢。G树在A树(改进R-tree，空间重叠度较高)基础上，类似于BANG File循环交替的平均分割空间，不同是更像影像金字塔。

在使用动态哈希时，算法繁复，若在内存存放空间索引，难以解决好索引冗余和占用空间过大的问题，若在外存存放索引，则在减少访问次数方面表现乏力，适用数据量小，很难解决海量数据的应用 (12)。因此，尽管格网索引在理论上很受重视，但在商业的通用数据库、空间数据库中几乎没有工程应用。

针对相关技术中的问题，目前尚未提出有效的解决方案。

发明内容

针对相关技术中的上述技术问题，本发明提出一种基于哈希格网索引的影像文件存储和管理***及方法，它一反流行的动态哈希格网索引技术路线，通过静态哈希技术，克服了哈希索引的一般缺点，能够有效支持在哈希域上的范围查询、部分匹配查询操作，具有动态添加的能力，瓦片的大规模增加、删除，不会导致哈希表的重整。

为实现上述技术目的，本发明的技术方案是这样实现的：

一种基于哈希格网索引的影像文件管理和存储方法，包括以下步骤：

S1：文件头管理，管理RPF的文件信息，将文件头的各字段按照RPF格式本身、影像信息像素级、影像信息影像级、原始元信息的顺序进行定义，实现对瓦片和图幅的管理；

S2：分包存储，有瓦片的区域按照固定范围的格块数目分包，单包内一次分配够索引空间，当且仅当在该包的块号区间至少包含一块数据时，才开始建新包，范围内没有任何瓦片的包不分配空间，没瓦片的区域不建索引；紧凑存储瓦片，以解决索引冗余问题；

S3：哈希格网索引，将哈希索引和格网索引相结合，按照金字塔划分格网，根据金字塔格块中的瓦片号码寻找对应包号码和包中偏移位置，建立瓦片索引到瓦片偏移的联系，实现(level, x, y)到物理存储位置的对应，以实现O(1)时间复杂度的瓦片定位，同时瓦片作为哈希桶，将哈希桶的粒度降低，减少数据的碰撞；

S4：分区处理，将分包集中在一个数据文件，每个包按照固定区段大小分配空间，不够时在数据文件末尾申请新区段。

进一步的，所述S3步骤包括：

金字塔格网索引，按照金字塔划分格网，确定最大层级，设定分包的容量，即可确定金字塔单包的哈希桶总数，每个哈希桶存放唯一号码瓦片的链接；

哈希索引，建立哈希函数，先对缩略图进行索引，然后依nLevel、nTileX、nTileY优先级，按从小到大顺序开辟索引表，将包号码和包中偏移位置进行对应，靠加减和位移操作实现（level，x，y）到物理存储位置的对应。

进一步的，根据S3步骤所述的稀疏索引为：

二级稀疏索引，独立出稀疏的Packet表，由Packet表建立Packet ID到Packet IDOffset的条目，或

一级稀疏索引，增加Packet ID Offset，由Packet ID Offset，进入包的区段，从瓦片索引表获取Tile Offset，由区段大小n Page Size，计算出包中区段号码n Page ID和瓦片在页内的偏移量n Page Tile Offset。

一种基于哈希格网索引的影像文件存储和管理***，包括：

文件头，用于RPF的文件信息的管理，将文件头层的各字段按照RPF格式本身、影像信息像素级、影像信息影像级、原始元信息的顺序进行定义，实现对瓦片和图幅的管理；

分包存储模块，用于解决索引冗余，有瓦片的区域按照固定范围的格块数目分包，单包内一次分配够索引空间，当且仅当在该包的块号区间至少包含一块数据时，才开始建新包，范围内没有任何瓦片的包不分配空间，没瓦片的区域不建索引；

哈希格网索引模块，用于实现O(1)时间效率的瓦片增删改查，减少数据的碰撞；将哈希索引和格网索引相结合，按照金字塔划分格网，根据金字塔格块中的瓦片号码寻找对应包号码和包中偏移位置，建立瓦片索引到瓦片偏移的联系，实现(level, x, y)到物理存储位置的对应，以减少数据的碰撞；

分区模块，用于将分包集中在一个数据文件，每个包按照固定区段大小分配空间，不够时在数据文件末尾申请新区段。

进一步的，所述文件头模块包括：

影像定长元信息模块：用于根据定长的元信息位置和长度数据进行文件的分类和管理；

影像变长元信息模块：用于根据变长的元信息位置和长度数据进行文件的分类和管理。

进一步的，所述哈希格网索引模块包括：

金字塔格网索引模块，用于建立格网索引，按照金字塔划分格网，确定最大层级，设定分包的容量，即可确定金字塔单包的哈希桶总数，每个哈希桶存放唯一号码瓦片的链接；

哈希索引模块，用于建立哈希函数，先对缩略图进行索引，然后依nLevel、nTileX、nTileY优先级，按从小到大顺序开辟索引表，将包号码和包中偏移位置进行对应，靠加减和位移操作实现（level，x，y）到物理存储位置的对应。

本发明的有益效果：通过静态哈希技术，克服了哈希索引的一般缺点，利用局部冗余的瓦片哈希索引，以有限的稀疏空间换取常数时间，即单瓦片的定位时间不随瓦片数据增加而增加，特别是对于效率要求很高的影像瓦片存取。有效的支持在哈希域上的范围查询、部分匹配查询操作，具有动态添加的能力，瓦片的大规模增加、删除，不会导致哈希表的重整。

附图说明

为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1是本发明实施例所述的一种基于哈希格网索引的影像文件存储和管理***单包结构示意图；

图2是本发明实施例所述的一种基于哈希格网索引的影像文件存储和管理***分包机制示意图；

图3是本发明实施例所述的一种基于哈希格网索引的影像文件存储和管理***的二级稀疏索引示意图。

具体实施方式

下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员所获得的所有其他实施例，都属于本发明保护的范围。

本发明实施例所述的一种基于哈希格网索引的影像文件存储和管理***，包括：

1.文件头，用于RPF的文件信息的管理，将文件头层的各字段按照RPF格式本身、影像信息像素级、影像信息影像级、原始元信息的顺序进行定义，实现对瓦片和图幅的管理；

1.1所述文件头模块包括：

单个瓦片索引的结构如表1所示，将瓦片偏移和长度同置于索引，避免过多的磁盘IO。

由于单格块索引占用16byte，金字塔最大层级nMaxLevel为20级时，合起来共有(4²¹-1)/3条索引，占用约16byte×2⁴²/3＝ 64/3TB，这是不可承受的空间开销，需要大幅度减少空间耗费。

2.分包存储模块，用于解决索引冗余，有瓦片的区域按照固定范围的格块数目分包，单包结构如图1所示，单包内一次分配够索引空间，当且仅当在该包的块号区间至少包含一块数据时，才开始建新包，范围内没有任何瓦片的包不分配空间，没瓦片的区域不建索引，若图2所示。

按照固定块数4的次幂分包。假设每包格块数为4^level，则首包容纳level级以下各层级的瓦片。除首包外，level级以上到nMaxLevel级所有格块，按方阵分配。每包的格块总数设定为4^level ( 0≤level≤nMaxLevel)，每个格块存放相同号码瓦片，依 nlevel、nTileX、nTileY优先级，从小到大顺序分包，首包存储0到level－1层级的瓦片，计(4^level －1)/3格。

例如，假设每包4⁹格块(首包为0～8级MODIS数据)。第1～８级小于4⁹块，存入ID为0的RPF包。第9级4⁹块，共计1个包。第10级共计4¹⁰/4⁹=4个包。第11级，4¹¹/4⁹=16个包。依此类推，如下表所示。

第一个包可容纳全部0～8级MODIS数据，满额共计(4⁹－1)/3格块，其余的为4⁹格块。

在我们的应用中，对于分辨率为0.5米/像素的影像，256×256的瓦片，覆盖面积约1/64km2，即64张瓦片达到约1 km2，设定数为4⁹格块的单包，覆盖面积达到约4096 km²，这个数目超过一般中等城市的面积。而单瓦片大小一般都在16KB～160KB，为瓦片索引16byte大小的千倍～万倍，如此面积的城市的瓦片数据，按不同瓦片数据格式一般超过4GB，它的索引空间仅为16byte×4⁹＝4MB。因此即使不考虑容纳的有效瓦片数据，这种冗余是可以接受的。而且，如果调低单包容量为4⁸甚至更少格块，冗余就更小了。

3.哈希格网索引模块，用于减少空间数据的碰撞，将哈希索引和格网索引相结合，按照金字塔划分格网，根据金字塔格块中的瓦片号码寻找对应包号码和包中偏移位置，建立瓦片索引到瓦片偏移的联系，实现(level, x, y)到物理存储位置的对应，以减少数据的碰撞。

3.1所述哈希格网索引模块包括：

哈希索引模块，用于建立哈希函数，将包号码和包中偏移位置进行对应，靠加减和位移操作实现(level, x, y)到物理存储位置的对应。

单包内索引内置时，索引区后是数据区，数据区中紧凑存储各个瓦片。索引区先是缩略图的索引，然后依nLevel、nTileX、nTileY优先级，按从小到大顺序开辟索引表。只有调整单包格块容量大小时，单包索引表大小才会改变。单包内索引表的条目与瓦片格块一一对应，通过偏移量就可以解决定位问题，因此各格块的索引位置可计算得到。

哈希函数可以是线性的，也可以是非线性的，目的就是减少碰撞。由于空间数据具有不均匀、集中分布的特征，而非随机性强的key值，有必要针对性的选择hash算法。当哈希函数h(k)，k1和k2能比较，且符合k1<k2时，h(k1)<h(k2)，则能支持在hash域上具有范围查询、部分匹配查询的数据操作。

在哈希格网索引中，金字塔格块就是哈希桶。确定最大层级nMaxLevel，设定分包的容量为4^m，则金字塔单包的Hash桶总数为4^m ( 0≤m≤nMaxLevel)，每个hash桶存放唯一号码瓦片的链接。格块号码到包ID和包内索引表号码的映射就是哈希函数。

层级nLevel/ nTileX／nTileY格块号+单包格数→包ID + Tile Index Offset→TileOffset→Tile，这里提炼出金字塔的哈希算法PyramidHash(level, x, y)，是最原始的简单Hash方法。对Tile(level, x, y)(“/”表示整除)：

若level＜m，则瓦片包号码nPacketID为0，包内桶号nBucket为(4^level－1)/3＋2^level ×y＋x。

若level≥m，则瓦片包号码nPacketID为(4^level-m－1)/3＋2^level-m ×(y/2^m)＋x/2^m，包内桶号nBucket为(y－y/2^m) × 2^m＋(x－x/2^m)。

PyramidHash(level, x, y) 是一种朴素的哈希函数，实现(level, x, y)到物理存储位置的对应。表达式虽然显得复杂，但其实就是在格块的m×m划分，根据号码找对应包号码和包中偏移位置，主要操作靠加减和移位操作就能实现，效率很高。

4.分区模块，用于将分包集中在一个数据文件，每个包按照固定区段大小分配空间，不够时在数据文件末尾申请新区段，相当于操作***内存管理中的段页式存储分配。

所述S3步骤包括：

哈希索引，建立哈希函数，先对缩略图进行索引，然后依nLevel、nTileX、nTileY优先级，按从小到大顺序开辟索引表，将包号码和包中偏移位置进行对应，靠加减和位移操作实现层级、位移到物理存储位置的对应。

根据S3步骤所述的稀疏索引为：

二级稀疏索引，独立出稀疏的Packet表，由Packet表建立Packet ID到Packet IDOffset的条目，缺点是在层级扩大到29级时，会较大幅度增加Packet索引段的冗余。

或者一级稀疏索引，增加PacketID Offset字段，指向数据文件中该包的首地址，这样就省去了Packet表的空间开销。

Tile (level,x,y)-> PacketID Offset|Tile Offset| Tile Length

获取瓦片索引时，首先由金字塔哈希算法计算出PacketID和该瓦片在包内索引表的偏移量。由PacketID Offset，进入包的区段，从瓦片索引表获取TileOffset，由区段大小nPageSize，可计算出包中区段号码nPageID和瓦片在页内的偏移量nPageTileOffset。

nPageID = nTileOffset/nPageSize (“/”表示整除)

nPageTileOffset = nTileOffset % nPageSize(“%”表示取余)

从而可定位到瓦片，缺点是定位到瓦片所在区段的过程，可能在数据文件中根据区段间链接进行多次探测。

由于遥感数据一般用最新数据，几乎不重叠，因此也就很少碰撞。只有在保存历史版本数据时，才会有碰撞。因此，目前阶段采用的外散列表，Hash碰撞简单的用拉链法处理。

具体的，在使用时：

1.session管理

Session是指一次读写的生命周期，***提供定期安全检查机制，发现某个Session长期无人使用，则会销毁它，释放资源占用。Session提供了类似事务管理的机制，确保了读写的数据完整性和正确性。

用户发起的读写请求，必须向***申请Session，这个Session就和当前用户当前读写瓦片唯一对应；最后一步是销毁Session，释放资源。在***中，每个Session都有唯一编号，它由下面几个要素组成：(1) 用户ID；(2)瓦片编号，包括层级Level，坐标TileX,TileY；(3)瓦片Tag信息，包括厂家、类型和时间版本，区分出不同版本。

读写瓦片时，Session可保证数据是正确的和完整的：

1）用前要申请Session，只有申请到了才能继续随后的读写操作，否则只能是等待或放弃本次操作。

写操作时，首先***会返回相同编号其他版本瓦片开始位置和大小。其次***会在包文件末尾追加40 字节瓦片描述符的占位，其内容要等到写结束时才能被填充完整。最后管理索引所需的开销，主要是用该瓦片编号在索引中产生占位，如果索引还没有建立起来，则首先要建立起完整的索引。

2）读写结束要销毁Session

销毁Session只是和包文件解除绑定，使包文件恢复到空闲状态，并不是要关闭包文件，何时关闭包文件请参见“VFD机制”；销毁Session在写操作中不但使瓦片数据完整，而且在索引中注册该瓦片，使其可查询。

在写操作结束后，首先将Session和包文件解除绑定，包文件恢复空闲状态，又可接收其他用户的请求了。其次反写瓦片描述符。再次在索引中注册这个瓦片，将其在包文件中开始位置和瓦片大小写入索引中。最后如果该瓦片编号有多个版本，按版本时间降序排列它们。

机制

虚拟文件***描述符（Virtual File Description），简称为VFD。***支持多进程并发读写，在服务端同时打开的文件数量将是不可预知的，所以必须管理文件资源。

1）用户每次发起大规模读写操作，比如切片或提取瓦片，任务结束后都要通知***，***根据用户ID去查询所有打开的包文件，如果其下用户列表有该用户，则从列表中删除，删除后列表为空，则关闭该包文件。

2）***还分别设置了读和写操作打开包文件最大数目，***会在需要打开包文件时去判断会不会超过这些值，如果有超出的，则要试图关闭一些包文件以释放操作***文件资源。只有那些处于空闲状态的包文件才可以被关闭。

并发读写

3.1并发写

全球影像的金字塔数据，分包统一进行管理，以文件形式存储，每个包都有既定的编号。至于包保存在哪里，包的编号是什么对用户来说都是透明的。当要写特定编号的瓦片数据时，***自动找到特定的数据包写入瓦片，同时在索引里注册这个瓦片。

1）首先在***管理的全部写文件链表中查找有没有这个包，如果没有，则按写的方式打开该包文件，同时在链表中注册这个打开的文件。

2）查看当前要写的包文件是否正忙，如果正忙，则不能接受这一次的写，并通知上层应用；如果不忙，则准备接收数据并写入包文件中。具体实现请看session管理。

3）每一个打开包文件，管理一个用户链表，因为它不专属于特定的用户，它可以同时为很多用户服务，只要空闲就可以接受任何用户写的请求。

3.2并发读

并发读的管理和并发写很相似，不同之处在于：并发读支持多个用户同时读取同个包文件，如果当前要读的包文件正忙，则立即第二次按读方式打开这个包文件，同时在链表中注册这个新打开的文件，准备好读数据了。

次数与数据多版本

海量影像数据的读写，影响哈希格网索引性能的关键因素是IO读写次数。

4.1写操作

4.1.1申请session过程

1）根据瓦片编号访问索引，如果瓦片所在的索引还没有创建，则要先创建索引，如何创建索引，稍后详细介绍。现假定索引已经创建，读取索引中该编号第一个版本在包文件中偏移和大小，并将它们保存下来作为即将写入瓦片的下一版本在包文件中偏移和大小。

2）开始访问包文件，在包文件末尾为瓦片描述符追加40 字节占位符。

3）创建索引，这一步不是每次都做的，参见1)。每个包文件可以容纳固定数目的瓦片数据，创建索引就是在索引中分配既定大小空间，供瓦片所在包文件使用。如果还有二级索引，必须在第一级索引中记录这个包文件在第二级索引中偏移位置。

4.1.2销毁session过程

1）将文件指针移到瓦片在包文件中偏移处，写入瓦片描述符。

2）在索引中注册当前瓦片，将其在包文件中开始位置和大小写入索引中。

3）如果该瓦片编号有多个版本，按版本时间降序排列它们。

4.2读操作

1）根据瓦片编号访问索引，如果没有则结束。

2）根据索引中记录的偏移量和大小，开始访问包文件。

3）比较瓦片各个版本中描述符的时间字段，如果没有找到，则结束。

4）读取实际瓦片数据。

可以看出多版本是影响性能的关键。我们的做法是在写入的过程中就将多版本数据按时间降序排列。

根据本发明所述的一种基于哈希格网索引的影像文件存储和管理***，它一反流行的动态哈希格网索引技术路线，通过静态哈希技术和分包技术，克服了哈希索引的一般缺点，通过局部冗余的瓦片哈希索引，以有限的稀疏空间换取常数时间，即单瓦片的定位时间不随瓦片数据增加而增加，特别是对于效率要求很高的影像瓦片存取。有效的支持在哈希域上的范围查询、部分匹配查询操作，具有动态添加的能力，瓦片的大规模增加、删除，不会导致哈希表的重整。

以上所述仅为本发明的较佳实施例而已，并不用以限制本发明，凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims

1.一种基于哈希格网索引的影像文件管理和存储方法，其特征在于，包括以下步骤：

S3:哈希格网索引，将哈希索引和格网索引相结合，按照金字塔划分格网，根据金字塔格块中的瓦片号码寻找对应包号码和包中偏移位置，建立瓦片索引到瓦片偏移的联系，实现(level,x,y)到物理存储位置的对应，以实现O(1)时间效率的瓦片增删改查，减少数据的碰撞；

所述S3步骤包括：

哈希索引，建立哈希函数，先对缩略图进行索引，然后依nLevel、nTileX、nTileY优先级，按从小到大顺序开辟索引表，将包号码和包中偏移位置进行对应，靠加减和位移操作实现(level,x,y)到物理存储位置的对应；

根据S3步骤所述的哈希索引为：

一级稀疏索引，增加Packet ID Offset，由Packet ID Offset，进入包的区段，从瓦片索引表获取Tile Offset，由区段大小n Page Size，计算出包中区段号码n Page ID和瓦片在页内的偏移量n Page Tile Offset；

2.一种基于哈希格网索引的影像文件存储和管理***，其特征在于，包括：

文件头模块包括：

影像变长元信息模块：用于根据变长的元信息位置和长度数据进行文件的分类和管理；

哈希格网索引模块，用于实现O(1)时间效率的瓦片增删改查，减少数据的碰撞；将哈希索引和格网索引相结合，按照金字塔划分格网，根据金字塔格块中的瓦片号码寻找对应包号码和包中偏移位置，建立瓦片索引到瓦片偏移的联系，实现(level,x,y)到物理存储位置的对应；分区模块，用于将分包集中在一个数据文件，每个包按照固定区段大小分配空间，不够时在数据文件末尾申请新区段；

所述哈希格网索引模块包括：

哈希索引模块，用于建立哈希函数，先对缩略图进行索引，然后依nLevel、nTileX、nTileY优先级，按从小到大顺序开辟索引表，将包号码和包中偏移位置进行对应，靠加减和位移操作实现层级、位移到物理存储位置的对应。