RFC46:GDAL/OGR统一
作者：连鲁奥
联系人：spatialys.com上的even dot rouault
状态：采用，在GDAL 2.0中实现
总结
在GDAL/OGR的1.X系列中，GDAL/raster和OGR/vector边在某些方面有很大的不同，即使它们没有明显的不同原因，特别是在驱动程序的结构上。此RFC旨在将OGR驱动程序结构与GDAL驱动程序结构统一起来。使用GDAL驱动程序结构的主要优点是：
元数据功能：驱动程序描述、扩展、创建选项、虚拟IO功能。。。
有效的驾驶员识别和打开。
类似地，OGR数据源和层类缺少相应的GDAL数据集和栅格带类提供的元数据机制。
另一个方面是，GDAL“数据集”和OGR“数据源”之间的分离有时是人为的。各种数据容器都可以接受这两种数据类型。具有GDAL端和OGR端的驱动程序列表是：SDTS、PDS、GRASS、KML、Spatialite/Rasterlite、GeoPackage（栅格端尚未实现）、PostGIS/PostGIS栅格、PDF、PCIDSK、FileGDB（栅格端尚未实现）。对于对两者都感兴趣的应用程序，这意味着当前要使用不同的API打开文件两次。对于更新模式，对于基于文件的驱动程序，必须按顺序进行更新，以避免在更新模式下同时打开文件两次并进行冲突的更改。
自我分配的发展约束
这些更改应该会对现有的GDAL/OGR代码库产生适度的影响，特别是对它的大部分代码（位于驱动程序中）的影响。如果不需要使用新提供的功能，GDAL/OGR API的现有用户也应该受到这些更改的适度影响。
核心更改：摘要
OGRSFDriver延伸到GDALDriver。
矢量驱动程序可以实现为GDALDriver。
ogrsfdriverregistrator是用于遗留OGRSFDriver的GDALDriverManager的兼容性包装器。
OGRDataSource扩展了GDALDataSource。
添加了gdalopenx（）API，以便能够打开“混合”数据集。
OGRLayer扩展了gdalmajoroject，从而添加了元数据功能。
与图层相关的OGRDataSource方法被移动到GDALDataset中，使其成为支持栅格和矢量的容器。
GDALOpenInfo（）机制的性能改进。
描述打开选项的新驱动程序元数据项（即不赞成使用配置选项）。
用于描述层创建选项的新驱动程序元数据项。
核心更改：详细信息
驾驶员和驾驶员登记
OGRSFDriver现在扩展了GDALDriver，是一种实现向量驱动程序的遗留方式。它之所以能够被维护，是因为在当前的实现中，并不是所有的驱动程序都迁移到了“纯”GDALDriver。CopyDataSource（）虚拟方法已被删除，因为没有树内驱动程序实现它。通过对GDAL driver的继承，可以通过GDALDriverManager管理向量驱动程序，并能够将元数据附加到它们、文档驱动程序长名称、文档链接、文件扩展名、使用现有GDAL-DMD创建数据源选项_ * 元数据项。
直接从GDALDriver继承的驱动程序（与从OGRSFDriver继承的驱动程序相反）应该：-声明SetMetadataItem（GDALu DCAPu VECTOR，“YES”）。-实现pfnOpen（）打开数据集-或者，实现pfnCreate（）创建数据集。对于向量驱动程序，Create（）的nBands参数应该传递给0。-（可选）实现pfnDelete（）以删除数据集
这个 C OGR驱动程序API仍然与已经被转换为“纯”GDALDrivers的驱动程序（这不是C++ OGR驱动程序API的真实性）。例如，OGR_Dr_GetName（）调用GDALDriver：：GetDescription（），OGR_Dr_CreateDatasource（）调用GDALDriver：：Create（），等等。。。
GDAdvor的C++定义扩展了以下函数指针，以便它可以与传统OGRSFFER一起工作。
/* For legacy OGR drivers */
GDALDataset *(*pfnOpenWithDriverArg)( GDALDriver*, GDALOpenInfo * );
GDALDataset *(*pfnCreateVectorOnly)( GDALDriver*,
const char * pszName,
char ** papszOptions );
CPLErr (*pfnDeleteDataSource)( GDALDriver*,
const char * pszName );
They are used by GDALOpenEx(), GDALDriver::Create() and GDALDriver::Delete()
if the pfnOpen, pfnCreate or pfnDelete pointers are NULL. The OGRSFDriverRegistrar
class has an implementation of those function pointers that calls the
legacy C++ OGRSFDriver::Open(), OGRSFDriver::CreateDataSource() and
OGRSFDriver::DeleteDataSource() virtual methods.
对于支持向量的驱动程序，GDALDriver：：Create（）可以接受nBands==0。
对于支持向量的驱动程序，GDALDriver：：DefaultCreateCopy（）可以接受带0的数据集，如果输出数据集具有层创建功能，而源数据集具有层，则它会将源数据集中的层复制到目标数据集中。
Identify（）现在遍历所有类型的驱动程序。它已被修改为对具有Identify（）实现的驱动程序执行第一次传递。如果找不到匹配项，它将对所有驱动程序执行第二次传递，并使用可能较慢的Open（）作为标识方法。
与上述要点相关，GDALDriver：：pfnIdentify函数指针的实现用于返回布尔值，以指示传递的GDALOpenInfo是否与驱动程序匹配。对于某些驱动程序，这限制太大，以至于它们能够实现Identify（）。例如，如果检测逻辑可以返回“是，我肯定能识别那个文件”、“不，这不适合我”或“我在GDALOpenInfo中没有足够的元素可以分辨”。最后一个状态现在可以用一个负的返回值进行广告。
ogrsfdriverregistrator被精简为GDALDriverManager的包装器。尤其是，它不再包含任何驱动程序列表。Open（）、OpenShared（）、ReleaseDataSource（）、DeregisterDriver（）和AutoLoadDrivers（）方法将从类中删除。这种改变可能会对C++代码产生影响。为了适应这些变化，OGR实用程序做了一些修改。RegisterDriver（）API已经为遗留的OGR驱动程序保留，它会自动设置SetMetadataItem（GDAL_DCAP_VECTOR，“YES”）。GetDriverCount（）、GetDriver（）和GetDriverByName（）方法委托给GDALDriverManager，并确保只考虑具有GDAL-DCAP-u向量功能的驱动程序。在驱动程序与GDAL和OGR驱动程序同名的情况下，OGR变量的内部前缀是 OGR_, GetDriverByName（）将首先尝试 OGR_ 变体。GetOpenDSCount（）和GetOpenDS（）现在有一个返回0/NULL的伪实现。作为参考，MapServer和QGIS都不使用这些功能。
OGRRegisterAll（）现在是GDALAllRegister（）的别名。过去的OGRRegisterAll（）现在重命名为OGRRegisterAllInternal（），并由GDALAllRegister（）调用。因此，GDALAllRegister（）和OGRRegisterAll（）现在是等价的，并注册所有驱动程序。
GDALDriverManager收到了一些更改：
使用从驱动程序名到驱动程序对象的映射来加速GetDriverByName（）
接受OGR_SKIP和OGR_DRIVER_PATH配置选项以实现向后兼容性。
GDALu SKIP中推荐的驱动程序名称分隔符现在是逗号而不是空格（类似于OGRu SKIP所做的）。这样就可以在GDALu SKIP中定义OGR驱动程序名，它们的名称中有空格，如“ESRI Shapefile”或“MapInfo File”。如果GDALu SKIP值中没有逗号，则假定使用空格分隔符（向后兼容）。
删除GetHome（）/SetHome（）方法，其目的似乎是为插件的搜索目录定义一个备用路径。这些方法仅存在于C++级别，且具有GDALL DRIVRIVE路径配置冗余。
支持栅格的驱动程序应该声明SetMetadataItem（GDALu DCAPu Raster，“YES”）。所有树内GDAL驱动程序都已修补以声明它。但是注册码检测驱动程序是否没有声明GDALu DCAPu RASTER或GDALu DCAPu VECTOR中的任何一个，在这种情况下，它会代表未修补的驱动程序声明GDALu DCAPu RASTER，并显示一条调试消息，邀请您显式设置它。
新元数据项：
GDAL_DCAP_RASTER=YES/GDAL_DCAP_VECTOR=YES（驾驶员级别）。声明驱动程序具有栅格/矢量功能。驱动程序可以同时声明这两者。
驾驶员级别的GDAL U DMD U扩展（带最终S）。这是GDAL-DMD-u扩展的一个小改进，可以在值字符串中指定多个扩展。分机是分开的。例如“shp dbf”、“tab mif mid”等。。。为了便于使用，GDALDriver：：SetMetadataItem（GDAL_DMD_EXTENSION）还将传递的值设置为GDAL_DMD_EXTENSIONS（如果尚未设置）。所以新代码总是可以使用GDAL-DMD-u扩展。
驾驶员级别的GDAL_DMD_OPENOPTIONLIST。此项的值是一个XML片段，其格式类似于创建选项。gdalopenx（）一旦用Identify（）标识了驱动程序接受该文件，将使用授权打开选项列表验证传递的打开选项列表。下面是S57驱动程序中授权打开选项列表的示例
<OpenOptionList>
<Option name="UPDATES" type="string-select"
description="Should update files be incorporated into the base data on the fly" default="APPLY">
<Value>APPLY</Value>
<Value>IGNORE</Value>
</Option>
<Option name="SPLIT_MULTIPOINT" type="boolean"
description="Should multipoint soundings be split into many single point "
"sounding features" default="NO" />
<Option name="ADD_SOUNDG_DEPTH" type="boolean"
description="Should a DEPTH attribute be added on SOUNDG features and "
"assign the depth of the sounding" default="NO" />
<Option name="RETURN_PRIMITIVES" type="boolean"
description="Should all the low level geometry primitives be returned as "
"special IsolatedNode, ConnectedNode, Edge and Face layers" default="NO" />
<Option name="PRESERVE_EMPTY_NUMBERS" type="boolean"
description="If enabled, numeric attributes assigned an empty string as a "
"value will be preserved as a special numeric value" default="NO" />
<Option name="LNAM_REFS" type="boolean"
description="Should LNAM and LNAM_REFS fields be attached to features "
"capturing the feature to feature relationships in the FFPT "
"group of the S-57 file" default="YES" />
<Option name="RETURN_LINKAGES" type="boolean"
description="Should additional attributes relating features to their underlying "
"geometric primtives be attached" default="NO" />
<Option name="RECODE_BY_DSSI" type="boolean"
description="Should attribute values be recoded to UTF-8 from the character "
"encoding specified in the S57 DSSI record." default="NO" />
</OpenOptionList>
- GDAL_DS_LAYER_CREATIONOPTIONLIST at dataset level. But can also be set at
driver level because, in practice, layer creation options do not depend on the
dataset instance.
The value of this item is an XML snippet with a format similar to dataset creation
options.
If specified, the passed creation options to CreateLayer() are validated
against that authorized creation option list.
Below an example of such an authorized open option list in the Shapefile driver.
<LayerCreationOptionList>
<Option name="SHPT" type="string-select" description="type of shape" default="automatically detected">
<Value>POINT</Value>
<Value>ARC</Value>
<Value>POLYGON</Value>
<Value>MULTIPOINT</Value>
<Value>POINTZ</Value>
<Value>ARCZ</Value>
<Value>POLYGONZ</Value>
<Value>MULTIPOINTZ</Value>
<Value>NONE</Value>
<Value>NULL</Value>
</Option>
<Option name="2GB_LIMIT" type="boolean" description="Restrict .shp and .dbf to 2GB" default="NO" />
<Option name="ENCODING" type="string" description="DBF encoding" default="LDID/87" />
<Option name="RESIZE" type="boolean" description="To resize fields to their optimal size." default="NO" />
</LayerCreationOptionList>
数据集/数据源
OGRDataSource中的主要方法已移动到GDALDataset：
virtual int GetLayerCount() { return 0; }
virtual OGRLayer *GetLayer(int) { return NULL; }
virtual OGRLayer *GetLayerByName(const char *);
virtual OGRErr DeleteLayer(int);
virtual int TestCapability( const char * ) { return FALSE; }
virtual OGRLayer *CreateLayer( const char *pszName,
OGRSpatialReference *poSpatialRef = NULL,
OGRwkbGeometryType eGType = wkbUnknown,
char ** papszOptions = NULL );
virtual OGRLayer *CopyLayer( OGRLayer *poSrcLayer,
const char *pszNewName,
char **papszOptions = NULL );
virtual OGRStyleTable *GetStyleTable();
virtual void SetStyleTableDirectly( OGRStyleTable *poStyleTable );
virtual void SetStyleTable(OGRStyleTable *poStyleTable);
virtual OGRLayer * ExecuteSQL( const char *pszStatement,
OGRGeometry *poSpatialFilter,
const char *pszDialect );
virtual void ReleaseResultSet( OGRLayer * poResultsSet );
int GetRefCount() const;
int GetSummaryRefCount() const;
OGRErr Release();
The following matching C API is available :
int CPL_DLL GDALDatasetGetLayerCount( GDALDatasetH );
OGRLayerH CPL_DLL GDALDatasetGetLayer( GDALDatasetH, int );
OGRLayerH CPL_DLL GDALDatasetGetLayerByName( GDALDatasetH, const char * );
OGRErr CPL_DLL GDALDatasetDeleteLayer( GDALDatasetH, int );
OGRLayerH CPL_DLL GDALDatasetCreateLayer( GDALDatasetH, const char *,
OGRSpatialReferenceH, OGRwkbGeometryType,
char ** );
OGRLayerH CPL_DLL GDALDatasetCopyLayer( GDALDatasetH, OGRLayerH, const char *,
char ** );
int CPL_DLL GDALDatasetTestCapability( GDALDatasetH, const char * );
OGRLayerH CPL_DLL GDALDatasetExecuteSQL( GDALDatasetH, const char *,
OGRGeometryH, const char * );
void CPL_DLL GDALDatasetReleaseResultSet( GDALDatasetH, OGRLayerH );
OGRStyleTableH CPL_DLL GDALDatasetGetStyleTable( GDALDatasetH );
void CPL_DLL GDALDatasetSetStyleTableDirectly( GDALDatasetH, OGRStyleTableH );
void CPL_DLL GDALDatasetSetStyleTable( GDALDatasetH, OGRStyleTableH );
OGRDataSource definition is now reduced to :
class CPL_DLL OGRDataSource : public GDALDataset
{
public:
OGRDataSource();
virtual const char *GetName() = 0;
static void DestroyDataSource( OGRDataSource * );
};
The existing OGR_DS_* API is preserved. The implementation of those functions
casts the OGRDataSourceH opaque pointer to GDALDataset*, so it is possible to
consider GDALDatasetH and OGRDataSourceH as equivalent from the C API point of
view. Note that it is not true at the C++ level !
OGRDataSource：：SyncToDisk（）已被删除。等效的功能应该在现有的FlushCache（）中实现。GDALDataset：：FlushCache（）nows执行OGRDataSource：：SyncToDisk（）以前的通用实现的工作，即遍历所有层并对它们调用SyncToDisk（）。
GDALDataset现在有一个受保护的ICreateLayer（）方法。
virtual OGRLayer *ICreateLayer( const char *pszName,
OGRSpatialReference *poSpatialRef = NULL,
OGRwkbGeometryType eGType = wkbUnknown,
char ** papszOptions = NULL );
This method is what used to be CreateLayer(), i.e. that drivers should
rename their specialized CreateLayer() implementations as ICreateLayer().
CreateLayer() is kept at GDALDataset level, but its implementation does a
prior validation of passed creation options against an optional authorized
creation option list (GDAL_DS_LAYER_CREATIONOPTIONLIST), before calling
ICreateLayer() (this is similar to RasterIO() / IRasterIO() )
A global pass on all in-tree OGR drivers has been made to rename CreateLayer()
as ICreateLayer().
添加了gdalopenx（），以便能够打开“仅栅格”、“仅矢量”或“栅格矢量”数据集。它接受只读/更新模式、共享/非共享模式。可能的候选驱动程序列表可以通过。如果为空，则探测所有驱动程序。可以传递打开选项的列表（名称=值语法）。如果已建立同级文件列表，则也可以传递该列表。否则GDALOpenInfo将建立它。
GDALDatasetH CPL_STDCALL GDALOpenEx( const char* pszFilename,
unsigned int nOpenFlags,
const char* const* papszAllowedDrivers,
const char* const* papszOpenOptions,
const char* const* papszSiblingFiles );
The nOpenFlags argument is a 'or-able' combination of the following values :
/* Note: we define GDAL_OF_READONLY and GDAL_OF_UPDATE to be on purpose */
/* equals to GA_ReadOnly and GA_Update */
/** Open in read-only mode. */
#define GDAL_OF_READONLY 0x00
/** Open in update mode. */
#define GDAL_OF_UPDATE 0x01
/** Allow raster and vector drivers. */
#define GDAL_OF_ALL 0x00
/** Allow raster drivers. */
#define GDAL_OF_RASTER 0x02
/** Allow vector drivers. */
#define GDAL_OF_VECTOR 0x04
/* Some space for GDAL 3.0 new types ;-) */
/*#define GDAL_OF_OTHER_KIND1 0x08 */
/*#define GDAL_OF_OTHER_KIND2 0x10 */
/** Open in shared mode. */
#define GDAL_OF_SHARED 0x20
/** Emit error message in case of failed open. */
#define GDAL_OF_VERBOSE_ERROR 0x40
The existing GDALOpen(), GDALOpenShared(), OGROpen(), OGROpenShared(),
OGR_Dr_Open() are just wrappers of GDALOpenEx() with appropriate open flags.
From the user point of view, their behavior is identical to the existing one,
i.e. GDALOpen() family will only returns datasets of drivers with declared raster
capabilities, and similarly with OGROpen() family with vector.
GDALOpenInfo类。完成以下更改：
构造函数的第二个参数现在是nOpenFlags，而不是GDALAccess，其语义与gdalopenx（）相同。GDALOpenInfo使用只读/更新位“计算”现有驱动程序中大量使用的eAccess标志。同时具有栅格和矢量功能的驱动程序可以使用栅格位的GDAL/GDAL来确定调用者的意图。例如，如果调用程序只使用GDAL_OF_RASTER打开，而数据集只包含矢量数据，则驱动程序可能决定不打开数据集（如果它是只读驱动程序）。如果它是具有更新功能的驱动程序，则只有在以只读模式打开时才应该这样做）。
传递给gdalopenx（）的打开选项存储在GDALOpenInfo的papszOpenOptions成员中，以便驱动程序可以使用它们。
“文件 * fp“成员转换为”VSILFILE * fpL”。这一变化的动机是大多数流行的驱动程序现在使用VSI虚拟文件API，因此它们现在可以直接使用fpL成员，而不是重新打开文件。已对使用fp的所有树内GDAL驱动程序进行全局传递。
VSIStatExL（）之前已完成，以确定传递的文件的性质。现在，我们乐观地从VSIFOpenL（）开始，假设在大多数用例中传递的文件名是一个文件。如果打开失败，则执行VSIStatExL（）以确定文件名的性质。
如果请求的访问模式是update，则使用“rb+”权限使用VSIFOpenL（）打开文件，以便直接使用。
papszSiblingFiles成员现在是私有的。它由GetSiblingFiles（）方法访问，该方法按需执行ReadDir（）操作。这可以加快Identify（）方法的速度，该方法通常不需要知道同级文件。
添加了一个新方法trytoIntest（），以读取文件的前1024个字节以上的内容。这对于一些向量驱动程序（如GML或NAS）很有用，它们必须获取更多的字节才能识别文件。
层
OGRLayer扩展GDALMajorObject。驱动程序现在可以定义层元数据项，这些元数据项可以用常用的GetMetadata（）/GetMetadateItem（）API检索。
GetInfo（）方法已被删除。它从未在任何树内驱动程序中实现过，并且已经被弃用了很长一段时间。
其他
已从gdal.h中删除了已弃用和未使用的GDALProjDefH和GDALOptionDefinition类型
GDALGeneralCmdLineProcessor（）现在将nOptions（栅格的GDAL_和栅格的GDAL_的组合）参数解释为应与--formats选项一起显示的驱动程序类型。如果设置为0，则假定为栅格的GDAL_。
GDAL实用程序的--formats选项输出驱动程序是否具有栅格和/或矢量功能
GDAL实用程序的--format选项输出GDAL-DMD-u扩展、GDAL-DMD-u OPENOPTIONLIST、GDAL-DS-u LAYER-u CREATIONOPTIONLIST。
OGRGeneralCmdLineProcessor（）使用gdalgenerallcmdlineprocessor（）实现，将格式限制为支持向量的驱动程序。
驱动因素的变化
OGR PCIDSK驱动程序已合并到GDAL PCIDSK驱动程序中。
OGR PDF驱动程序已合并到GDAL PDF驱动程序中。
已经对树内OGR驱动程序进行了全局传递，这些驱动程序必须打开一个文件以确定它们是否识别该文件。它们已转换为GDALDriver以接受GDALOpenInfo参数，现在它们使用其pabyHeader字段检查文件的第一个字节。为了确定一个文件不被任何OGR驱动程序识别，重新分配到文件访问（open/stat）的系统调用数量已经从GDAL 1.11中的46个减少到1个。转换后的驱动程序有：AeronavFAA、ArcGEN、AVCBin、AVCE00、BNA、CSV、DGN、Edigo、ESRI Shapefile、GeoJSON、Georgs、GML、GPKG、GPSBabel、GPX、GTM、HTF、ILI1、ILI2、KML、LIBKML、MapInfo文件、MySQL、NAS、NTF、OpenAIR、OSM、PDS、REC、S57、SDTS、Seguka、SEGY、SOSI、Slite、SUA、SVG、TIGER、VFK、VRT、WFS
Long driver description is set for most OGR drivers.
从OGRLayer派生的所有类都已修改为使用GetName（）/poFeatureDefn->GetName（）的值调用SetDescription（）。test_ogrsf测试它是否正确设置。
以下驱动程序保留为OGRSFDriver，但它们的Open（）方法会进行早期扩展/前缀测试，以避免实例化数据源对象：CartoDB、CouchDB、DXF、EDIGEO、GeoConcept、GFT、GME、IDRISI、OGDI、PCIDSK、PG、XPlane。
已为CSV、DGN、DXF、EDIGEO、GeoJSON、GML、KML、LIBKML、MapInfo文件、NAS、OpenFileGDB、OSM、S57、Shape、SQLite、VFK、VRT实现Identify（）。
GDAL-DMD-u扩展/GDAL-DMD-u扩展为以下驱动程序设置：AVCE00、BNA、CSV、DGN、DWG、DXF、EDIGEO、FileGDB、Geoconcept、GeoJSON、Geomedia、GML、GMT、GPKG、GPX、GPSTrackMaker、IDRISI Vector、Interlis 1、Interlis 2、KML、LIBKML、MDB、MapInfo File、NAS、ODS、OpenFileGDB、OSM、PGDump、PGeo、REC、S57、ESRI Shapefile、SQLite、SVG、WaSP、XLS，XLSX，X平面。
将BNA、DGN、FileGDB、geoconcept、GeoJSON、geoss、GML、GPKG、KML、LIBKML、PG、PGDump和ESRI Shapefile驱动程序的文档数据集和层创建选项设置为GDAL-DMD-CREATIONOPTIONLIST/GDAL-DS-layer-CREATIONOPTIONLIST。
添加打开选项AAIGRID、PDF、S57和ESRI Shapefile驱动程序。
在OpenFileGDB、Shapefile和OGR VRT驱动程序中实现的GetFileList（）。
将LIBKML、OCI、ODS、XLSX驱动程序的数据源SyncToDisk（）重命名为FlushCache（）。
在GTiff、PNG、JPEG、GIF、VRT、NITF、DTED中使用poOpenInfo->fpL避免无用的文件重新打开。
HTTP驱动程序：声明为GDAL-DCAP-RASTER和GDAL-DCAP-VECTOR驱动程序。
RIK:implement Identify（）
注意：以下OGR驱动程序（主要是专有的）的编译和良好工作无法测试：ArcObjects、DWG、DODS、SDE、FME、GRASS、IDB、OCI、mssqlspace（编译正常，但未经运行时测试）
公用设施的变化
gdalinfo接受-oo选项来定义打开的选项
ogrinfo接受-oo选项来定义打开的选项
ogr2ogr接受-oo选项来定义输入数据集打开选项，并接受-doo选项来定义目标数据集打开选项
SWIG绑定的更改
Python和Java绑定：
添加从OGRDataSource获取的新GDALDataset方法：CreateLayer（）、CopyLayer（）、DeleteLayer（）、GetLayerCount（）、GetLayerByIndex（）、GetLayerByName（）、TestCapability（）、ExecuteSQL（）、ReleaseResultSet（）、GetStyleTable（）和SetStyleTable（）。
使OGR驱动程序、数据源和层对象从MajorObject派生
Perl和CSharp：确保它仍然可以编译，但是一些工作必须由它们的维护者完成才能使用新的功能
潜在的变化 NOT 包含在本RFC中
当前RFC的“自然”演变：
统一GDAL MEM和OGR内存驱动程序。
统一GDAL VRT和OGR VRT驱动程序。
进一步的统一步骤：
源树更改以将OGR驱动程序从OGR/ogrsf_frmts/移动到frmts/，将OGR/ogrsf_frmts/移动到generic/ * 至gcore/ * 等。
文档统一（包含驱动程序列表的页面等）
重命名以删除OGR命名空间的痕迹：OGRLayer->GDALLayer等。。。
Kill——没有ogr编译选项？即使为了方便起见，它现在嵌入了ogr/ogrsf_frmts/generic和ogr/ogrsf_frmts/mitab，它仍然保持在工作状态。
一些实用程序的统一：“gdal info XXX”、“gdal convert XXX”，可以在所有类型的数据集上工作。
向后兼容性
GDALDriverManager：：GetDriverCount（），GetDriver（）现在返回OGR驱动程序以及GDAL驱动程序
GDAL数据集和gdal1.xogr数据源中的引用计数有点不同。GDAL数据集从1开始，OGR数据源从0开始。现在OGRDataSource基本上是一个GDALDataset，对于这两种情况，它都从1开始。希望OGRu DSu GetRefCount（）API的用户很少。如果认为有必要，我们可以恢复以前的行为在C API，但这将是不可能的，在C++级别。作为参考，MapServer和QGIS都不使用OGRu DSu GetRefCount（）。
文档
应通过文件检查所有新方法是否正确记录。OGR一般文档（特别是C++ API读/写教程、驱动实现教程和OGR体系结构）应该更新以反映变化。
测试
已经做了很少的更改，所以现有的自动测试套件仍然可以通过。已经添加了测试gdalopenx（）API和从OGRDataSource“导入”到GDALDataset的方法。
版本编号
虽然上面描述的更改应该对现有的应用程序C API有很小的影响，但是一些行为改变，C++级别的改变和概念的改变被认为应该是2版本号。
实施
甚至鲁奥也会实施。
建议的实施是在 https://github.com/rouault/gdal2/tree/unification 储存库。
投票历史
+来自朱卡尔、法兰克、丹尼尔姆、塔马斯和埃文的1人。