RFC 38:OGR快速打开（撤回）

作者：连鲁奥

联系人：spatialys.com上的even dot rouault

状态：撤回。

总结

提出OGR数据源开放机制依赖于GDAL驱动程序已经使用的GDALOpenInfo类来加速数据源的开放。加快速度的原因是传递给OGROpen（）的文件将只打开和统计一次，而当前，它的打开和关闭次数与OGR驱动程序的次数相同。这对于网络文件系统，或者当试图打开一个根本不是OGR数据源的文件时，应该特别有用。

E、例如，尝试打开当前不是OGR数据源的文件需要45个文件打开或stat操作：

$ strace ogrinfo -ro NEWS 2>&1 | grep NEWS | wc -l
45

预计如果/一旦所有驱动程序都迁移了，它只会减少到2个操作。

实施

与GDALDriver类似，OGRSFDriver类被扩展为具有pfnOpen成员，驱动程序将设置为指向自己的开放方法。

/* -------------------------------------------------------------------- */
/*      The following are semiprivate, not intended to be accessed      */
/*      by anyone but the formats instantiating and populating the      */
/*      drivers.                                                        */
/* -------------------------------------------------------------------- */
    OGRDataSource       *(*pfnOpen)( GDALOpenInfo * );

更新ogrsfdriverregistrator：：Open（）方法以在迭代驱动程序时调用pfnOpen。未设置pfnOpen时，它将尝试调用OGRSFDriver的Open（）方法（该方法支持驱动程序的渐进迁移）。

主要出于兼容性的原因，OGRSFDriver的virtual method Open（）目前是纯虚拟的，现在将是一个常规的虚拟方法，它将有一个默认的实现，它将尝试调用pfnOpen。

带有OGR core更改的修补程序附加到此页。

向后兼容性

建议的添加不会对C二进制兼容性产生任何影响。

C++二进制接口将被打破（由于在OGRSFFDRAMER类中添加了一个新成员，而Open-（）方法从纯虚拟变成了虚拟。

将为第三方OGR驱动程序保留源代码级兼容性。

对驾驶员的影响

现有的驱动程序是 not 需要迁移到RFC38，但强烈建议迁移。新的驱动程序应该使用RFC38机构来保持整体的快速打开。

本页附有几个驱动程序的迁移示例。

时间线

甚至鲁奥也有责任执行这项提议。新的API将在GDAL 2.0中提供。大多数树内OGR驱动程序将迁移到新机制。