Some drivers load incompletely as plugins

[kyngchaos@…]

Some GDAL drivers include multiple formats, with separate GDALRegister_* functions for each. When built into GDAL, they are properly loaded by GDALAllRegister(). As a plugin, only the format of the plugin name is loaded by AutoLoadDrivers(), and any secondary formats are not. This affects NetCDF (NetCDF + GMT), HDF4 (HDF4 + HDF4Image), HDF5 (HDF5 + HDF5Image), and ECW (ECW + JP2ECW). There is also one similar case in OGR: ILI.

I don't know how correct this is, but I was able to solve the problem by calling the secondary GDALRegister_ from the primary GDALRegister_. ie for HDF4, within GDALRegister_HDF4(), call GDALRegister_HDF4Image() after HDF4 is registered.

In case GDAL is built with the drivers within GDAL, the secondary driver calls should also be removed from GDALAllRegister(), to eliminate unnecessary redundant calls to those.

[warmerdam]

William, 

Basically GDAL isn't setup currently to build drivers as plugins.  So I'm 
reclassifying this report as an enhancement request, since it seems you are
mostly just adding for restructuring things for easier use of plugins.

It is possible to put multiple drivers into one .so or .dll and instead
implement the GDALRegisteMe() function for registration.  

I will look into merging the registration functions of some of the paired
drivers like HDF4/HDF4Image.  But for stuff like ECW and JP2ECW there are
legitimate reasons to what to only register one or the other and to want
control over the ordering. 

[kyngchaos@…]

> But for stuff like ECW and JP2ECW there are
> legitimate reasons to what to only register one or the other and to want
> control over the ordering. 
> 

Just wondering - could you clarify this?  If I do these as plugins, I would like to know about potential problems.

By ordering, do you mean relatively within the multiple formats (ECW, then JP2ECW, or visa-versa) or in the whole collection of formats (JP2KAK-JPEG2000-JP2ECW)?

For only registering one of multiple formats within a plugin, isn't there GDAL_SKIP to disable formats?  Seems to me that's the only way it can work - load all formats, then disable some (AutoSkipDrivers at the end of GDALAllRegister).

[warmerdam]

For ordering, I mostly mean things like the order of JP2ECW/JP2KAK/JPEG200/JP2MrSID.

One issue I hadn't really considered before is that there is no real
control for ordering of autoloaded drivers.

You are correct that GDAL_SKIP is the main way to disable some drivers,
though particular applications might want to control what drivers get
registered by order of calling the registration functions. 

[kyngchaos@…]

I didn't even notice the MrSID driver - it is already OK and registers both formats in the same GDALRegister call.

I just remembered something that's a case for doing formats as plugins (some at least).  I was building everything into GDAL, and for Postgres used a static libpq to reduce external lib usage.  After separating PG into a plugin, my QGIS build broke, because for some reason it was using the libpq functions from the GDAL static copy, not the dynamic libpq that was also linked directly to QGIS.

So, building formats that depend on common external libs (as opposed to obscure stuff like HDF and FITS) as plugins helps isolate lib dependecies.

> though particular applications might want to control what drivers get
> registered by order of calling the registration functions. 

So, an application using the GDAL library doesn't *have* to call GDALAllRegister(), or it's not automatic when initializing GDAL?  Can GDALRegisterDriver() register a driver from a plugin (this would be a problem, if it can't)?

[warmerdam]

Applications do not have to call GDALAllRegister(), though I think it is 
automatic with the swig buildings.

Applications can register a driver with GDALRegisterDriver(), but that 
is normally only used if they have previously unregistered it since all
the low level register calls (that create the GDALDriver handles) also
register their driver with the driver manager. 

[warmerdam]

William,

I'm closing this enhancement request. We are aware of a need for easier plugin building, but I don't think holding an enhancement request open indefinately will help get it done.