OracleSpatialGeoRaster10g影像数据管理.docVIP

浅入浅出Oracle Spatial GeoRaster 10g影像数据管理(2)——物理存储 1.物理存储方式概要??? 在上个部分《浅入浅出Oracle Spatial GeoRaster 10g影像数据管理(1)——数据模型》中提到：GeoRaster数据由两部分组成，一是多维像素矩阵，二是GeoRaster元数据。绝大部分的元数据都采用Oracle XMLType类型，以XML文档的形式存储。元数据的格式由GeoRaster元数据XML schema决定。这里说“绝大部分”说明还有“逍遥法外”的元数据。不错，那就是每个GeoRaster对象的空间范围（或地理范围，spatial extent or footprint）。这个重要的属性并没有和其它元数据一起本分的呆在XML文档中，而是单独出来作为了GeoRaster对象的一部分，并且与剩下的其它元数据的集合（就是那个XML文档）相并列。??? 还是在上个部分，我们还提到对栅格数据这种海量数据集进行处理的基本策略就是“分而治之”，所以对原始数据集进行多分辨率分层——也就是著名的“金字塔”——和在各层上进行分块还是少不了的。看到金字塔和分块我就会条件反射似的兴奋，毕竟我硕士阶段的文章就是关于它的，希望已经10g了的Oracle能带给我一些区别于ArcSDE的惊喜。下面的第2节会有关于GeoRaster中金字塔和分块的详细介绍。??? GeoRaster把影像数据用两个基本的表（GeoRaster table和Raster data table，RDT）组织起来，并由GeoRaster object将这两个表连接起来。如果把GeoRaster table比作栅格数据（或影像数据，影像图幅）的目录，那么RDT就是目录所指的具体内容，也就是栅格数据的大本营。后面的第3节会对RDT的结构有所介绍。第4节介绍了GeoRaster引入的blank GeoRaster object和empty GeoRaster object这两个从中文上可能不太好区分的对象，其实它们的用途完全不同。最后会简单小结一下GeoRaster采用的物理存储方式。??? 下面马上进入金字塔和分块。2.成熟的策略？陈旧的策略？——“金字塔”＋“均匀分块，边缘补零”??? 对栅格数据这种海量数据集进行分治的策略在传统上一般采用多尺度组织和分块组织——这是那些八股式的学术文章中的提法，通俗的说，就是为原始影像构建分辨率递减的金字塔结构和在每一级金字塔上对栅格数据进行分块。像GeoRaster这种用来构建TB级影像数据库的技术，当然也要提供与传统相对应的策略。??? 说实话，看过文档之后，感觉挺失望的，但是为了保证这个系列文章前后风格的一致，我还是以原文的口吻把“金字塔”和“均匀分块，边缘补零”这两个基本策略分别介绍一下。2.1.金字塔（Pyramid）??? 所谓金字塔，是指这样一组栅格对象，它们具有不同的分辨率和尺寸（而且其分辨率和尺寸一般分别是一个等比数列），但是它们所表示的地理区域是完全一样的，（如果忽略采样时丢弃的像素所带来的误差的话，那么它们应该具有相同的地理范围）是同一块地理区域的不同分辨率的图像。??? 建立金字塔的顺序一定是“自底向上”的，将原始的，分辨率最高的图像，通过一次次的采样处理而得到一组尺寸越来越小，分辨率越来越低的图像，形成“金字塔”形的一个图像序列。如图1所示：??? 图1??? 那么为什么要构建金字塔呢？因为影像的尺寸代表了它的数据量，显然尺寸越小，分辨率越低的影像数据量也越小。而数据量的大小又和读取影像的时间息息相关。特别是在Web应用中，查询窗口大小是固定的，客户端对影像数据的查询请求在绝大多数情况下都不会对应于原始分辨率，而是低于原始分辨率的。那么在这种情况下，如果在影像数据库中没有建塔，那么在处理客户端请求的时候，就不得不每次都要访问原始分辨率的影像，也就是数据量最大的那幅影像，然后取出查询请求中地理范围对应的那部分后，再通过图像处理（比如用GDI+）将其缩小到查询窗口的大小，并传给客户端，这样的处理流程显然效率是很低的。而如果在影像数据库中建立了金字塔结构，那么就相当于在数据库中为前端应用“准备”好了各种不同分辨率的影像数据，这样一来，客户端就可以在这些不同分辨率的数据中“按需所取”了。??? 基于金字塔结构最典型的应用就是在Web上对地图进行放大（zoom in），开始的时候，显示全图，分辨率很低，此时可能只需读取金字塔塔顶的数据，而随着不断对地图进行放大，所读取的金字塔级别会越来越低，分辨率越来越高，图像中的细节也越来越丰富。而在整个过程中，数据传输量和效率都不会有大的起伏。??? GeoRaster文档认为金字塔可以分成两种：一种