[Gdal-dev] RFC 10: OGR Open Parameters

Andrey Kiselev dron at ak4719.spb.edu
Wed Mar 14 08:44:38 EDT 2007


On Tue, Mar 13, 2007 at 10:03:44AM -0400, Daniel Morissette wrote:
> Do we have an idea of how many third party OGR drivers exist that
> would be impacted by that change? (i.e. not counting the drivers that
> are in the GDAL SVN repository).

This change is unavoidable, because OGRSFDriver::Open() is pure virtual
method. Fortunately it is pretty trivial to fix the driver, so I do not
see any serious problem for third-party drivers, if such exist.

> Actually, could we not avoid any backwards compatibility issue by 
> playing with the fact that the three Open() methods are virtual?
> The base classes could define a default implementation for the new 
> method that just maps the call to the old method without the 
> papszOptions, e.g.
> OGRDataSource *
> OGRSFDriverRegistrar::Open( const char * pszName, int bUpdate,
>                             OGRSFDriver ** ppoDriver,
> 			    char **papszOptions /*= NULL*/ )
> {
>     /* Map this call to the old/deprecated GDAL 1.4.0 Open() method
>      * for drivers that do not implement the new Open() method added
>      * in GDAL 1.5.0+
>      */
>     return Open( pszName, bUpdate, ppoDriver );
> }
> If I'm not mistaken, this way old drivers would continue to work even if 
> they do not define the new Open() method... and upgraded drivers that 
> override the new Open() method could take advantage of the new 
> papszOptions feature.

Sorry, but I do not understand the point here. OGRSFDriver::Open() is
the method that should be fixed in drivers because it is pure virtual.
How new OGRSFDriver::Open() should be declared? Should it be pure
virtual as the old method? Then drivers will need to implement both old
and new ones. If it will not be a pure virtual, then drivers still need
to implement the old Open() method, even if they want to go with new
style Open() call only. Please, correct me if I wrong.

Best regards,

Andrey V. Kiselev
ICQ# 26871517

More information about the Gdal-dev mailing list