Changes between Initial Version and Version 1 of rfc10_ogropen


Ignore:
Timestamp:
Apr 28, 2007, 12:17:41 PM (17 years ago)
Author:
warmerdam
Comment:

Ported from doxygen.

Legend:

Unmodified
Added
Removed
Modified
  • rfc10_ogropen

    v1 v1  
     1= RFC 10: OGR Open Parameters =
     2
     3Author: Andrey Kiselev[[BR]]
     4Contact: dron@ak4719.spb.edu[[BR]]
     5Status: Development
     6
     7== Summary ==
     8
     9It is proposed that OGRSFDriver::Open() and OGRSFDriverRegistrar::Open() calls
     10should be changed to accept additional parameter containing arbitrary
     11additional parameters supplied by caller. OGROpenEx() function will be
     12introduced to map this new functionality into C interface. In addition
     13it is proposed to add an "update" flag to OGRSFDriverRegistrar::Open()
     14call to avoid using OGRSFDriverRegistrar::OpenShared() method.
     15
     16== Open parameters ==
     17
     18Sometimes it is needed to pass additional information to OGR driver along with
     19the name of the dataset to be opened. It can be, for example, the style table
     20name (some drivers allow to choose from the various style tables) or any other
     21additional data. The old method for doing this was to encode the extra info in
     22the dataset name string. It was inconvenient approach, so it proposed to use
     23separate parameter in OGRSFDriver::Open() and OGRSFDriverRegistrar::Open()
     24calls representing open options, just like it is implemented in
     25OGRDataSource::CreateLayer() call.
     26
     27It is supposed that open options will be supplied in form of NAME=VALUE pairs
     28forming the string list.
     29
     30In addition to options parameter the special "shared" flag will be added to
     31OGRSFDriverRegistrar::Open() call, so there will be no need in separate
     32OGRSFDriverRegistrar::OpenShared() method.
     33
     34== Implementation ==
     35
     36All Open() functions will be changed in the following way:
     37
     38{{{
     39static OGRDataSource *
     40OGRSFDriverRegistrar::Open( const char * pszName, int bUpdate,
     41                            OGRSFDriver ** ppoDriver,
     42                            int bShared = FALSE,
     43                            char **papszOptions = NULL );
     44
     45
     46}}}
     47
     48{{{
     49OGRDataSource *
     50OGRSFDriverRegistrar::OpenShared( const char * pszName, int bUpdate,
     51                                  OGRSFDriver ** ppoDriver )
     52        { return Open( pszName, bUpdate, ppoDriver, TRUE, NULL ); }
     53}}}
     54
     55{{{
     56virtual OGRDataSource
     57OGRSFDriver::*Open( const char *pszName, int bUpdate=FALSE,
     58                    char **papszOptions = NULL ) = 0;
     59}}}
     60
     61The last change needs to be propagated in all OGR drivers. The change itself
     62is pretty simple: one additional parameter should be added to function
     63definition. But it has impact on third-party OGR drivers: they are not
     64source compatible anymore and should be changed too.
     65
     66Also appropriate C functions will be added:
     67
     68{{{
     69OGRDataSourceH OGROpenEx( const char *pszName, int bUpdate,
     70                          OGRSFDriverH *pahDriverList,
     71                          int bShared, char **papszOptions );
     72}}}
     73
     74{{{
     75OGRDataSourceH OGR_Dr_OpenEx( OGRSFDriverH hDriver, const char *pszName,
     76                              int bUpdate, char **papszOptions );
     77}}} 
     78
     79== New Options for OGR Utilities ==
     80
     81Proposed functionality will be available in OGR utilities ogr2ogr and ogrinfo
     82via the '-doo NAME=VALUE' ("Datasource Open Option") format specific parameter.
     83
     84== Backward Compatibility ==
     85
     86Proposed additions will not have any impact on C binary compatibility.
     87C++ binary interface will be broken, source level compatibility will be
     88broken for third-party OGR drivers only. There will be no impact
     89for high-level applications on source level.
     90
     91== Responsibility and Timeline ==
     92
     93Andrey Kiselev is responsible to implement this proposal. New API will
     94be available in GDAL 1.5.0.