RFC 25：快速打开（撤回）

作者：弗兰克·温特丹

联系方式：warmerdam@pobox.com

状态：撤销（支持#2957中的某些具体改进-rfc可能会在以后更新）

总结

本文档为应用程序提出了一种机制，以表示希望尽可能快地打开栅格文件，即使可能无法获得各种元数据和支持信息。它主要用于优化使用包含许多栅格文件的目录的应用程序。

实施

应用程序可以通过将“GDAL_fast_open”配置选项设置为“YES”来请求快速打开模式-默认设置为“no”。当此选项设置为“YES”时，所选驱动程序可以以不同的方式操作，以优化打开数据集的速度。加速选项包括：

  • 跳过建立坐标系-如果它避免了EPSG查找，则特别有用。

  • 跳过对支持.aux.xml、world文件和其他文件的探测。

预计fast open模式将主要用于数据集的快速栅格显示，其中所需的元数据已由某种类别的目录提供。因此，在快速开放模式下，数据集仍然能够准确地返回波段列表、它们的数据类型和它们的概述，这一点非常重要。

线程本地配置选项

在多线程应用程序中，使用进程全局配置选项（仅在调用GDALOpen（）时打开）可能不合适。特别是，很难确保此配置选项不会影响同一进程的其他线程中的GDALOpen（）。此问题还影响其他配置选项。要解决此问题，需要添加一个新函数来设置“线程本地”配置选项。

void CPLSetThreadLocalConfigOption( const char *pszKey, const char *pszValue );

此机制将使用普通线程本地数据处理（CPLGetTLS（）等）实现。

需要注意的是，CPLSetConfigOption（）将继续设置要应用于所有线程的配置选项。CPLGetConfigOption（）将首先搜索线程本地值，然后处理全局值，最后搜索环境。

工作计划

目前，将对驾驶员进行以下更改，以使其在快速打开模式下加速。

  • GDALOpenInfo将避免加载目录中所有文件的列表。

  • GTIFF驱动程序将避免收集坐标系。

这项工作将在Frank wartemdam发布GDAL 1.7.0时在trunk中完成。

利用

目前还没有计划立即这样做，但GDAL VRT驱动程序将是一个很好的候选人利用这一机制。

理论上，MapServer也希望将此模式用于tileindexed栅格-除了MapServer依赖于来自底层栅格文件的geotransform而不是来自栅格目录。MapServer还假设颜色表和nodata值可用。

预计ArcGIS也将利用这一特性。

向后兼容性问题

没有已知的向后兼容性问题。但是，如果我们在快速打开模式下允许省略哪些支持信息的版本之间不精确且不一致，则可能存在转发兼容性问题。

测试

  • 测试将被添加到相应的驱动程序测试脚本中，以测试快速打开模式—确认预期的信息被丢弃并保留。

问题

  • 像忽略.aux.xml文件这样可能需要的东西是不可能的，因为它们有时也是概述信息的来源。

  • 可能会丢弃包括颜色表、nodata值和geotransforms在内的所有元数据，这使得此模式对于像MapServer这样不将此类信息保存在其目录中的应用程序不太有用。

  • 此RFC不讨论通过跳过不必要的驱动程序来加速GDALOpen（）的方法，尽管这也可能有很大帮助。